From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
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>, 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:16:01 |
Message-ID: | 47A5BE91.5080902@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Martijn van Oosterhout wrote:
> 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 and that what overcommit was
> designed for: banking on the fact that 99% of the time, that space
> isn't written to. Overcommit is precisely what makes forking as cheap
> as threads.
>
>
>
1. Isn't most of that space program text in segments marked read-only?
2. I always turn on strict memory accounting on Linux. I haven't noticed
that it has had any performance effect. But it does pretty much do away
with the likelihood of having postgres killed from under me, AFAIK.
cheers
andrew
From | Date | Subject | |
---|---|---|---|
Next Message | Gregory Stark | 2008-02-03 13:25:45 | Re: configurability of OOM killer |
Previous Message | Martijn van Oosterhout | 2008-02-03 11:55:31 | Re: configurability of OOM killer |