Re: VACUUM ANALYZE out of memory - Mailing list pgsql-hackers

From Martijn van Oosterhout
Subject Re: VACUUM ANALYZE out of memory
Date
Msg-id 20071211143353.GC27613@svana.org
Whole thread Raw
In response to Re: VACUUM ANALYZE out of memory  (Michael Akinde <michael.akinde@met.no>)
Responses Re: VACUUM ANALYZE out of memory  (Michael Akinde <michael.akinde@met.no>)
List pgsql-hackers
On Tue, Dec 11, 2007 at 03:18:54PM +0100, Michael Akinde wrote:
> The server has 4 GB RAM available, so even if it was trying to use 1.2
> GB shared memory + 1 GB for maintenance_mem all at once, it still seems
> odd that the process would fail. As far as I can tell (running ulimit -a
> ),  the limits look pretty OK to me.

IIRC you said you're on a 32-bit architecture? Which means any single
process only has 4GB address space. Take off 1GB for the kernel, 1GB
shared memory, 1 GB maintainence workmem and a collection of libraries,
stack space and general memory fragmentation and I can absolutly
beleive you've run into the limit of *address* space.

On a 64-bit machine it doesn't matter so much but on a 32-bit machine
using 1GB for shared memory severely cuts the amount of auxilliary
memory the server can use. Unless you've shown a measuable difference
between 256MB and 1G shared memory, I'd say you're better off using the
smaller amount so you can have higher maintainence work mem.

VACUUM doesn't benefit much from lots of shared buffers, but it does
benefit from maint workmem.

Have a nice day,
--
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> Those who make peaceful revolution impossible will make violent revolution inevitable.
>  -- John F Kennedy

pgsql-hackers by date:

Previous
From: Gregory Stark
Date:
Subject: Re: There's random access and then there's random access
Next
From: Magnus Hagander
Date:
Subject: Re: Problem with ControlFileData structure being ABI depe ndent