summaryrefslogtreecommitdiff
path: root/doc/src
diff options
context:
space:
mode:
authorTom Lane2012-06-13 19:34:57 +0000
committerTom Lane2012-06-13 19:35:52 +0000
commit93f4d7f806613d28842f956a84f31cc41d825503 (patch)
tree493db7fa8fc449a9cac2a75ac2a44b197e9f2271 /doc/src
parentb9212e379c55564c8b6cdc8585b74606e90ec1ea (diff)
Support Linux's oom_score_adj API as well as the older oom_adj API.
The simplest way to handle this is just to copy-and-paste the relevant code block in fork_process.c, so that's what I did. (It's possible that something more complicated would be useful to packagers who want to work with either the old or the new API; but at this point the number of such people is rapidly approaching zero, so let's just get the minimal thing done.) Update relevant documentation as well.
Diffstat (limited to 'doc/src')
-rw-r--r--doc/src/sgml/runtime.sgml23
1 files changed, 16 insertions, 7 deletions
diff --git a/doc/src/sgml/runtime.sgml b/doc/src/sgml/runtime.sgml
index 05da7235089..7ba18f03197 100644
--- a/doc/src/sgml/runtime.sgml
+++ b/doc/src/sgml/runtime.sgml
@@ -1268,7 +1268,7 @@ default:\
In Linux 2.4 and later, the default virtual memory behavior is not
optimal for <productname>PostgreSQL</productname>. Because of the
way that the kernel implements memory overcommit, the kernel might
- terminate the <productname>PostgreSQL</productname> server (the
+ terminate the <productname>PostgreSQL</productname> postmaster (the
master server process) if the memory demands of
another process cause the system to run out of virtual memory.
</para>
@@ -1317,22 +1317,31 @@ sysctl -w vm.overcommit_memory=2
<para>
Another approach, which can be used with or without altering
<varname>vm.overcommit_memory</>, is to set the process-specific
- <varname>oom_adj</> value for the postmaster process to <literal>-17</>,
- thereby guaranteeing it will not be targeted by the OOM killer. The
- simplest way to do this is to execute
+ <varname>oom_score_adj</> value for the postmaster process to
+ <literal>-1000</>, thereby guaranteeing it will not be targeted by the OOM
+ killer. The simplest way to do this is to execute
<programlisting>
-echo -17 > /proc/self/oom_adj
+echo -1000 > /proc/self/oom_score_adj
</programlisting>
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 <productname>PostgreSQL</>
- with <literal>-DLINUX_OOM_ADJ=0</> added to <varname>CPPFLAGS</>.
+ with <literal>-DLINUX_OOM_SCORE_ADJ=0</> added to <varname>CPPFLAGS</>.
That will cause postmaster child processes to run with the normal
- <varname>oom_adj</> value of zero, so that the OOM killer can still
+ <varname>oom_score_adj</> value of zero, so that the OOM killer can still
target them at need.
</para>
+ <para>
+ Older Linux kernels do not offer <filename>/proc/self/oom_score_adj</>,
+ but may have a previous version of the same functionality called
+ <filename>/proc/self/oom_adj</>. This works the same except the disable
+ value is <literal>-17</> not <literal>-1000</>. The corresponding
+ build flag for <productname>PostgreSQL</> is
+ <literal>-DLINUX_OOM_ADJ=0</>.
+ </para>
+
<note>
<para>
Some vendors' Linux 2.4 kernels are reported to have early versions