"Martijn van Oosterhout" <[EMAIL PROTECTED]> writes: > On Sat, Feb 02, 2008 at 09:49:05PM +0100, Florian G. Pflug wrote: >> AFAICS, memory overcommit helps if a program creates 50mb of mosty >> read-only data, and than forks 10 times, or if it maps a large amount of >> memory but writes to that block only sparsely. Since postgres does >> neither, a dedicated postgres server won't see any benefits from >> overcommitting memory I'd think. > > While this was probably intented to be funny, postgres does in fact > load 10mb of mostly read-only data (the > binary/libc/ssl/locales/kerberos add up to about 10mb on my machine) it > subsequently forks a dozen times, one for each connection. So postgres > is *exactly* such a program. If you start preloading > plperl/plpython/etc it grows even faster. > > Now, postgres almost certainly will never change much of it so it's not > a big deal, but it could if it wanted to
Actually no, at least on Linux the shared library linker maps shared libraries read-only, so it really can't. Not without changing the mapping at which point the kernel could adjust its memory counts. However the reference to plperl and plpython is more apt. At least with perl on Apache it's quite common to arrange to load as many modules as possible before forking. That way the worker processes have shared copies of those modules which, even though they're most certainly in writable memory are mostly kept shared. The real screw case that overcommit is intended for is actually large programs -- like postgres -- which call fork/exec small programs often. So for example if you have postgres calling system() it should be allowed to do the fork even if there aren't many megabytes free because it's only going to exec some small program like pg_standby. This is especially nasty when you realize that bash itself is one such large program... -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's PostGIS support! ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org
