Message-ID: <20071212171924.uir6apjasoog00c4@webmail.kwsoft.de>
Date: Wed, 12 Dec 2007 17:19:24 +0100
From: Listaccount <lst_hoe01@kwsoft.de>
To: pgsql-admin@postgresql.org
Subject: Re: Dangerous hint in the PostgreSQL manual
References: <20071210162612.a9y113hzjkookooc@webmail.kwsoft.de>
	<20071210204750.GA22340@crankycanuck.ca>
	<20071211092338.3vsx57ymsswsckw0@webmail.kwsoft.de>
	<20071211134231.GL26741@crankycanuck.ca>
	<20071211150836.00ql03638kok48s0@webmail.kwsoft.de>
	<20071211162229.GD27409@crankycanuck.ca>
In-Reply-To: <20071211162229.GD27409@crankycanuck.ca>
MIME-Version: 1.0
Content-Type: text/plain;
	charset=ISO-8859-1;
	DelSp="Yes";
	format="flowed"
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
User-Agent: Internet Messaging Program (IMP) H3 (4.1.5)

Zitat von Andrew Sullivan <ajs@crankycanuck.ca>:

> On Tue, Dec 11, 2007 at 03:08:36PM +0100, Listaccount wrote:
>> I would have not been surprised if the OOM-Killer would go around in
>> case of short memory but i was surprised to see fork failed with a
>> system having 1GB Memory available.
>
> You don't understand: the system _did not_ have 1G of memory available.  I=
t
> was all committed to applications that had asked for it.  Just because the=
y
> asked for it even though they were never going to use it doesn't mean that
> it isn't gone.  It's used, as far as the kernel is concerned.  The
> overcommit trick some OSes have implemented is a filthy hack to get around
> poor memory allocation discipline in applications.


For sure i understand the problem. The key is how you define =20
"available". But i agree with you that overcommit obfuscate careless =20
application design.


> The point of the PostgreSQL documentation is to tell you how best to run
> Postgres, safely and reliably.  The only safe and reliable way to run on
> Linux is not to use overcommit.  Turning it off ensures that the system
> can't run out of memory in this way.

Yes, but the documentation should at least warn if some setting =20
*could* lead to trouble you would not have otherwise.

> What I _would_ support in the docs is the following addition in 17.4.3,
> where this is discussed:
>
>     . . .it will lower the chances significantly and will therefore
>     lead to more robust system behavior.  It may also cause fork() to fail
>     when the machine appears to have available memory.  This is done by
>     selecting. . .
>
> Or something like that.  This would warn potential users that they really =
do
> need to read their kernel docs.

On this one we can agree. Maybe we should mention the root-cause.

"It may also cause fork() to fail when the machine appears to have =20
available memory because of other applications doing careless memory =20
allocation"

Would be nice to save others from learning about this the hard way.

Regards

Andreas