|The PostgreSQL 9.0 Reference Manual - Volume 3 - Server Administration Guide
by The PostgreSQL Global Development Group
Paperback (6"x9"), 274 pages
RRP £9.95 ($14.95)
Sales of this book support the PostgreSQL project! Get a printed copy>>>
3.4.3 Linux Memory Overcommit
In Linux 2.4 and later, the default virtual memory behavior is not optimal for PostgreSQL. Because of the way that the kernel implements memory overcommit, the kernel might terminate the PostgreSQL server (the master server process) if the memory demands of another process cause the system to run out of virtual memory.
If this happens, you will see a kernel message that looks like this (consult your system documentation and configuration on where to look for such a message):
Out of Memory: Killed process 12345 (postgres).
This indicates that the ‘postgres’ process has been terminated due to memory pressure. Although existing database connections will continue to function normally, no new connections will be accepted. To recover, PostgreSQL will need to be restarted.
One way to avoid this problem is to run PostgreSQL on a machine where you can be sure that other processes will not run the machine out of memory. If memory is tight, increasing the swap space of the operating system can help avoid the problem, because the out-of-memory (OOM) killer is invoked only when physical memory and swap space are exhausted.
On Linux 2.6 and later, it is possible to modify the
kernel's behavior so that it will not “overcommit” memory.
Although this setting will not prevent the OOM killer from being invoked
altogether, it will lower the chances significantly and will therefore
lead to more robust system behavior. This is done by selecting strict
overcommit mode via
sysctl -w vm.overcommit_memory=2
or placing an equivalent entry in ‘/etc/sysctl.conf’.
You might also wish to modify the related setting
vm.overcommit_ratio. For details see the kernel documentation
Another approach, which can be used with or without altering
vm.overcommit_memory, is to set the process-specific
oom_adj value for the postmaster process to
thereby guaranteeing it will not be targeted by the OOM killer. The
simplest way to do this is to execute
echo -17 > /proc/self/oom_adj
in the postmaster's startup script just before invoking the postmaster.
Note that this action must be done as root, or it will have no effect;
so a root-owned startup script is the easiest place to do it. If you
do this, you may also wish to build PostgreSQL
-DLINUX_OOM_ADJ=0 added to
That will cause postmaster child processes to run with the normal
oom_adj value of zero, so that the OOM killer can still
target them at need.
Note: Some vendors' Linux 2.4 kernels are reported to have early versions of the 2.6 overcommit
sysctlparameter. However, setting
vm.overcommit_memoryto 2 on a 2.4 kernel that does not have the relevant code will make things worse, not better. It is recommended that you inspect the actual kernel source code (see the function
vm_enough_memoryin the file ‘mm/mmap.c’) to verify what is supported in your kernel before you try this in a 2.4 installation. The presence of the ‘overcommit-accounting’ documentation file should not be taken as evidence that the feature is there. If in any doubt, consult a kernel expert or your kernel vendor.
|ISBN 9781906966072||The PostgreSQL 9.0 Reference Manual - Volume 3 - Server Administration Guide||See the print edition|