Re: high shared buffer and swap

From: Martijn van Oosterhout
Subject: Re: high shared buffer and swap
Date: ,
(view: Whole thread, Raw)
In response to: Re: high shared buffer and swap  (Greg Stark)
List: pgsql-hackers

Tree view

high shared buffer and swap  (Laurent Laborde, )
 Re: high shared buffer and swap  (Greg Stark, )
  Re: high shared buffer and swap  (Martijn van Oosterhout, )
 Re: [PERFORM] high shared buffer and swap  (Scott Marlowe, )

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

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   <>
> Please line up in a tree and maintain the heap invariant while
> boarding. Thank you for flying nlogn airlines.

pgsql-hackers by date:

From: "K, Niranjan (NSN - IN/Bangalore)"
Subject: Synchronous replication: Promotion of Standby to Primary
From: Tom Lane
Subject: Re: windows shared memory error