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
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
