Re: [HACKERS] high shared buffer and swap

From: Martijn van Oosterhout <kleptog(at)svana(dot)org>
To: Greg Stark <greg(dot)stark(at)enterprisedb(dot)com>
Cc: Laurent Laborde <kerdezixe(at)gmail(dot)com>, pgsql-performance(at)postgresql(dot)org, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [HACKERS] high shared buffer and swap
Date: 2009-05-04 10:15:09
Message-ID: 20090504101509.GA26374@svana.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-performance

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(at)svana(dot)org> http://svana.org/kleptog/
> Please line up in a tree and maintain the heap invariant while
> boarding. Thank you for flying nlogn airlines.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2009-05-04 12:24:09 Re: Documentation: GiST extension implementation
Previous Message Magnus Hagander 2009-05-04 09:21:57 Re: Why isn't stats_temp_directory automatically created?

Browse pgsql-performance by date

  From Date Subject
Next Message Scott Marlowe 2009-05-04 15:07:45 Re: high shared buffer and swap
Previous Message Greg Stark 2009-05-04 08:57:47 Re: high shared buffer and swap