Re: high shared buffer and swap - Mailing list pgsql-hackers

From Martijn van Oosterhout
Subject Re: high shared buffer and swap
Date
Msg-id 20090504101509.GA26374@svana.org
Whole thread Raw
In response to Re: high shared buffer and swap  (Greg Stark <greg.stark@enterprisedb.com>)
List pgsql-hackers
On Mon, May 04, 2009 at 10:57:47AM +0200, Greg Stark wrote:
> I think what's happening is that the sytem is seeing that some pages of
> shared memory haven't been used recently and because there's more shared
> memory than filesystem cache less recently than the filesystem cache
> pages. So it pages out the shared memory. This is really awful because we
> use a kind of lru algorithm for shared memory so the pages that it's
> paging out are precisely the pges likely to be used soon.
>
> I wonder if we should try to mlock shared buffers.

You can try, but it probably won't work. You often need to be root to
lock pages, and even on Linux 2.6.9+ where you don't need to be root
there's a limit of 32KB (that's only my machine anyway). Sure, that can
be changed, if you're root.

Actually locking the shared buffers seems to me like a footgun. People
occasionally give postgresql masses of memory leaving not enough to run
the rest of the system. Locking the memory would make the situation
worse.

Personally I've never seen a benefit of setting shared buffer above the
expected working set size. I generally let the kernel share the
remaining memory between postgresql disk cache and other processes I
might be running. On a NUMA machine you want to be keeping your memory
on the local node and letting the kernel copy that data from elsewhere
to your local memory when you need it.

Have a nice day,
--
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> Please line up in a tree and maintain the heap invariant while
> boarding. Thank you for flying nlogn airlines.

pgsql-hackers by date:

Previous
From: Magnus Hagander
Date:
Subject: Re: Why isn't stats_temp_directory automatically created?
Next
From: Peter Eisentraut
Date:
Subject: Re: Documentation: GiST extension implementation