Re: configurability of OOM killer - Mailing list pgsql-hackers

From Martijn van Oosterhout
Subject Re: configurability of OOM killer
Date
Msg-id 20080203115531.GA11431@svana.org
Whole thread Raw
In response to Re: configurability of OOM killer  ("Florian G. Pflug" <fgp@phlo.org>)
Responses Re: configurability of OOM killer  (Andrew Dunstan <andrew@dunslane.net>)
Re: configurability of OOM killer  (Gregory Stark <stark@enterprisedb.com>)
Re: configurability of OOM killer  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
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.

Have a nice day,
--
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> Those who make peaceful revolution impossible will make violent revolution inevitable.
>  -- John F Kennedy

pgsql-hackers by date:

Previous
From: "Heikki Linnakangas"
Date:
Subject: Re: FW: bitemporal functionality for PostgreSQL
Next
From: Andrew Dunstan
Date:
Subject: Re: configurability of OOM killer