Re: [HACKERS] high shared buffer and swap

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

Attachment: signature.asc
Description: Digital signature


[Postgresql General]     [Postgresql PHP]     [PHP Users]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Yosemite]

  Powered by Linux