From: Andrew Dunstan <andrew@dunslane.net>
To: pgsql-hackers@postgresql.org
Subject: Re: Can't find thread on Linux memory overcommit
Date: Thu, 21 Aug 2003 09:19:24 -0400
Message-ID: <3F44C6DC.4060105@dunslane.net> (raw)
In-Reply-To: <3F43BD9F.3050205@dunslane.net>
References: <200308201102.37559.josh@agliodbs.com>
<3F43BD9F.3050205@dunslane.net>
I see btw that no change has been made to the docs. That's bad IMNSHO.
The situation with RH is unchanged with today's kernel errata patch,
too. I propose to submit a doc patch with the following wording, unless
someone objects or improves it:
-----------------------
Linux kernel version 2.4.* has poor default memory overcommit behavior,
which can result in the postmaster being killed by the kernel due to
memory demands by another process if the system runs out of memory. To
avoid this situation, run postgres on a machine where you can be sure
that other processes will not run the machine out of memory. If your
kernel supports strict and/or parnoid modes of overcommit handling, you
can also relieve this problem by altering the system's default
behaviour. This can be determined by examining the function
vm_enough_memory in the file mm/mmap.c in the kernel source. If this
file reveals that strict and/or paranoid modes are supported by your
kernel, turn one of these modes on by using
sysctl -w vm.overcommit_memory=2
for strict mode or
sysctl -w vm.overcommit_memory=3
for paranoid mode.
Warning: using these settings in a kernel which does not support these
modes will almost certainly increase the danger of the kernel killing
the postmaster, rather than reducing it. If in any doubt, consult a
kernel expert or your kernel vendor.
These modes are expected to be supported in all 2.6 and later kernels.
Some vendor 2.4 kernels may also support these modes. However, it is
known that some vendor documents suggest that they support them while
examination of the kernel source reveals that they do not.
-----------------
The kernel docs on these modes state this:
Gotchas
-------
The C language stack growth does an implicit mremap. If you want absolute
guarantees and run close to the edge you MUST mmap your stack for the
largest size you think you will need. For typical stack usage is does
not matter much but its a corner case if you really really care
Does this affect Pg?
andrew
Andrew Dunstan wrote:
>
> http://archives.postgresql.org/pgsql-hackers/2003-07/msg00608.php
>
> Subject is "reprise on Linux overcommit handling" - is that too
> deceptive? :-)
>
> andrew
>
> Josh Berkus wrote:
>
>> Hackers,
>>
>> I've been searching the archives, but I can't find the thread from
>> last month where we discussed the problem with Linux memory
>> overcommits in kernel 2.4.x.
>>
>> Can someone point me to the right thread? I think maybe the subject
>> line was something deceptive ....
>>
>>
>>
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 7: don't forget to increase your free space map settings
>
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: andrew@dunslane.net, pgsql-hackers@postgresql.org
Subject: Re: Can't find thread on Linux memory overcommit
In-Reply-To: <3F44C6DC.4060105@dunslane.net>
* 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