Skip site navigation (1) Skip section navigation (2)

Re: Dangerous hint in the PostgreSQL manual

From: Listaccount <lst_hoe01(at)kwsoft(dot)de>
To: pgsql-admin(at)postgresql(dot)org
Subject: Re: Dangerous hint in the PostgreSQL manual
Date: 2007-12-11 08:23:38
Message-ID: 20071211092338.3vsx57ymsswsckw0@webmail.kwsoft.de (view raw or flat)
Thread:
Lists: pgsql-adminpgsql-docs
Zitat von Andrew Sullivan <ajs(at)crankycanuck(dot)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=2" 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 kernel
> 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=2 (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 yours.
> You should _for sure_ set overcommit_memory=2 in that case.  And this is
> why:

I don't want to start the discussion what is the rigth thing todo,  
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  
check if you get i trouble with this setting so one can prepare.
A simple "see if your "CommitLimit - Commited_AS" from /proc/meminfo  
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: the
> chances that the OS will recover enough memory in any given round start out
> 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  
(for example  
http://developers.sun.com/solaris/articles/subprocess/subprocess.html). I only  
like to see a hint how to check *before* you get in trouble.

Regards

Andreas



In response to

Responses

pgsql-docs by date

Next:From: Florian WeimerDate: 2007-12-11 10:26:05
Subject: Re: Dangerous hint in the PostgreSQL manual
Previous:From: Andrew SullivanDate: 2007-12-10 20:47:50
Subject: Re: Dangerous hint in the PostgreSQL manual

pgsql-admin by date

Next:From: Bansal, Gaurav (Gaurav)Date: 2007-12-11 09:16:23
Subject: Postgres Start
Previous:From: Tom LaneDate: 2007-12-11 03:59:06
Subject: Re: Legacy foreign keys

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group