From: | Gregory Stark <stark(at)enterprisedb(dot)com> |
---|---|
To: | "Martijn van Oosterhout" <kleptog(at)svana(dot)org> |
Cc: | "Florian G(dot) Pflug" <fgp(at)phlo(dot)org>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Andrew Dunstan" <andrew(at)dunslane(dot)net>, "Florian Weimer" <fweimer(at)bfk(dot)de>, "Alvaro Herrera" <alvherre(at)commandprompt(dot)com>, "Pg Hackers" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: configurability of OOM killer |
Date: | 2008-02-03 13:25:45 |
Message-ID: | 873asa9nom.fsf@oxford.xeocode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Martijn van Oosterhout" <kleptog(at)svana(dot)org> 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!
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2008-02-03 13:49:56 | Re: Truncate Triggers |
Previous Message | Andrew Dunstan | 2008-02-03 13:16:01 | Re: configurability of OOM killer |