Zitat von Andrew Sullivan <ajs@xxxxxxxxxxxxxxx>:
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
---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
