Guillaume Lelarge wrote:
> Le 09/02/2010 09:35, David Kerr a écrit :
>> Guillaume Lelarge wrote:
>>> Le 09/02/2010 05:49, John R Pierce a écrit :
>>>> David Kerr wrote:
>>>>>>> maintenance_work_mem = 1GB
>>>>>> So evidently, when it tries to actually allocate 1GB, it can't do it.
>>>>>> Ergo, that setting is too high for your machine.
>>>>>> ...
>>>>> seems like i've got 2GB free.
>>>> is this a 64bit postgres build?
>>>>
>>>> if not, you're probably running out of virtual address space in the 32
>>>> bit user space, which is limited to like 2gb.
>>>>
>>> IIRC, the virtual address space in 32bit platforms is 4GB.
>> it is a 32bit box.
>>
>>>> the other possibility, and here I'm not sure, is that
>>>> maintenance_work_mem is coming out of shared memory, and if so, you've
>>>> exceeeded your SHMMAX kernel limit.
>>>>
>>> work_mem and maintenance_work_mem are not shared memory. AFAICT, David
>>> need to check if the VACUUM works with a lower setting for
>>> maintenance_work_mem. For example, 512MB could work.
>>>
>>>
>> Yes, vacuum -z works with 512MB. so any idea what was causing it not to
>> work with 1GB?
>>
>
> Tom already explained that. The process couldn't get the 1GB it was
> allowed to use with this setting of maintenance_work_mem.
>
>
Well, that made sense until I freed up a lot of memory on the box. I had
tried it again with 2GB of free memory available to me to use. My
ulimits are all unlimited. So i'm wondering if there's a kernel setting
I need, or something similar.
oh, hmm, my swap is 517Megs, that probably isn't helping. Usually swap
is 1.5/2x available memory, isn't it? (it is for most unix's and oracle,
but i'm not sure about PG and linux)
Thanks
Dave