From: Listaccount <lst_hoe01@kwsoft.de>
To: pgsql-admin@postgresql.org
Subject: Re: Dangerous hint in the PostgreSQL manual
Date: Tue, 11 Dec 2007 09:23:38 +0100
Message-ID: <20071211092338.3vsx57ymsswsckw0@webmail.kwsoft.de> (raw)
In-Reply-To: <20071210204750.GA22340@crankycanuck.ca>
References: <20071210162612.a9y113hzjkookooc@webmail.kwsoft.de>
<20071210204750.GA22340@crankycanuck.ca>
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=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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-docs@postgresql.org
Cc: lst_hoe01@kwsoft.de, pgsql-admin@postgresql.org
Subject: Re: Dangerous hint in the PostgreSQL manual
In-Reply-To: <20071211092338.3vsx57ymsswsckw0@webmail.kwsoft.de>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox