diff options
author | Tom Lane | 2012-06-13 19:34:57 +0000 |
---|---|---|
committer | Tom Lane | 2012-06-13 19:35:52 +0000 |
commit | 93f4d7f806613d28842f956a84f31cc41d825503 (patch) | |
tree | 493db7fa8fc449a9cac2a75ac2a44b197e9f2271 /doc/src | |
parent | b9212e379c55564c8b6cdc8585b74606e90ec1ea (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.sgml | 23 |
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 |