From 02cd2b96acdb1de766f9a947e6f8de401454907b Mon Sep 17 00:00:00 2001 From: Tom Lane Date: Sun, 16 Nov 2003 17:01:50 +0000 Subject: [PATCH] Another try at fixing the Linux overcommit docs, per Andrew Dunstan. --- doc/src/sgml/runtime.sgml | 66 ++++++++++++++++++--------------------- 1 file changed, 30 insertions(+), 36 deletions(-) diff --git a/doc/src/sgml/runtime.sgml b/doc/src/sgml/runtime.sgml index 20ae294ccd..346b7cd0c6 100644 --- a/doc/src/sgml/runtime.sgml +++ b/doc/src/sgml/runtime.sgml @@ -1,5 +1,5 @@ @@ -3269,7 +3269,7 @@ default:\ Linux Memory Overcommit - In Linux 2.4, the default virtual memory behavior is not + 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 may terminate the PostgreSQL server (the @@ -3285,51 +3285,45 @@ default:\ Out of Memory: Killed process 12345 (postmaster). This indicates that the postmaster process - has been terminated due to memory pressure; + 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. - To avoid this situation, run PostgreSQL + 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 your kernel supports the strict - and/or paranoid 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 the strict or paranoid modes are supported by - your kernel, turn one of these modes on by using + run the machine out of memory. + + + + On Linux 2.6 and later, a better solution is to modify the kernel's + behavior so that it will not overcommit memory. This is + done by selecting strict overcommit mode via sysctl: sysctl -w vm.overcommit_memory=2 - for strict mode, or - -sysctl -w vm.overcommit_memory=3 - - for paranoid mode, or placing an equivalent entry in - /etc/sysctl.conf. For more information on memory - overcommit handling and the meaning of these kernel settings, - consult the file - Documentation/vm/overcommit-accounting in a - recent version of the source code for the Linux kernel. + or placing an equivalent entry in /etc/sysctl.conf. + You may also wish to modify the related setting + vm.overcommit_ratio. For details see the kernel documentation + file Documentation/vm/overcommit-accounting. - - - Using these settings with a kernel which does not support these - modes will almost certainly increase the danger of the kernel - killing the database server, rather than reducing it. If in any - doubt, consult a kernel expert or your kernel vendor. - - - - The method described above for changing the kernel's overcommit - behavior should work with Linux kernel versions 2.6 and later. In addition, - some versions of the 2.4 kernel distributed by some vendors may - also support this functionality. However, it is known that some - vendor documents suggest that they support them while examination - of the kernel source reveals that they do not. + Some vendors' Linux 2.4 kernels are reported to have early versions + of the 2.6 overcommit sysctl. However, setting + vm.overcommit_memory to 2 + on a 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_memory in the file mm/mmap.c) + to verify what is supported in your copy 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. -- 2.40.0