Message-ID: <20071211092338.3vsx57ymsswsckw0@webmail.kwsoft.de>
Date: Tue, 11 Dec 2007 09:23:38 +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>
In-Reply-To: <20071210204750.GA22340@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 Mon, Dec 10, 2007 at 04:26:12PM +0100, Listaccount wrote:
>> Hello
>>
>> I have been trapped by the advice from the manual to use "sysctl -w
>> vm.overcommit_memory=3D2" when using Linux (see 16.4.3. Linux Memory
>> Overcommit). This value should only be used when PostgreSQL is the
>
> I think you need to read the documentation more carefully, because it
> clearly suggests you (1) look at the kernel source and (2) consult a kerne=
l
> expert as part of your evaluation.
>
> In any case,

Consult the kernel source is a little bit overkill for setup a database.

>> /proc/meminfo on a longer running system. If "Committed_AS" reaches or
>> come close to "CommitLimit" one should not set overcommit_memory=3D2 (see
>> http://www.redhat.com/archives/rhl-devel-list/2005-February/msg00738.html=
).
>
> my own reading of that message leads me to the opposite conclusion as your=
s.
> You should _for sure_ set overcommit_memory=3D2 in that case.  And this is
> why:

I don't want to start the discussion what is the rigth thing todo, =20
both settings the default "0" and "2" have advantages and drawbacks.
What i would like to see in the documentation is the easy hint to =20
check if you get i trouble with this setting so one can prepare.
A simple "see if your "CommitLimit - Commited_AS" from /proc/meminfo =20
come close to 0 after some uptime and if so don't use it.

>> this setting the machine in question may get trouble with "fork
>> failed" even if the standard system tools report a lot of free memory
>> causing confusion to the admins.
>
> You _want_ the fork to fail when the kernel can't (over)commit the memory,
> because otherwise the stupid genius kernel will come along and maybe blip
> your postmaster on the head, causing it to die by surprise.  Don't like
> that?  Use more memory.  Or get an operating system that doesn't do stupid
> things like promise more memory than it has.
>
> Except, of course, those are getting rarer and rarer all the time.
>
> Please note that memory overcommit is sort of like a high-risk mortgage: t=
he
> chances that the OS will recover enough memory in any given round start ou=
t
> as high.  Eventually, however, the [technical|financial] economy is such
> that only high-risk commitments are available, and at that point, _someone=
_
> isn't going to pay back enough [memory|money] to the thing demanding it.  =
At
> that point, it's anyone's guess what will happen next.

As said the discussion about pro- and -con have happend many times =20
(for example =20
http://developers.sun.com/solaris/articles/subprocess/subprocess.html). I on=
ly =20
like to see a hint how to check *before* you get in trouble.

Regards

Andreas