Another try at fixing the Linux overcommit docs, per Andrew Dunstan.

This commit is contained in:
Tom Lane 2003-11-16 17:01:50 +00:00
parent 1f45555892
commit 02cd2b96ac

View File

@ -1,5 +1,5 @@
<!-- <!--
$Header: /cvsroot/pgsql/doc/src/sgml/runtime.sgml,v 1.220 2003/11/16 03:58:10 tgl Exp $ $Header: /cvsroot/pgsql/doc/src/sgml/runtime.sgml,v 1.221 2003/11/16 17:01:50 tgl Exp $
--> -->
<Chapter Id="runtime"> <Chapter Id="runtime">
@ -3269,7 +3269,7 @@ default:\
<title>Linux Memory Overcommit</title> <title>Linux Memory Overcommit</title>
<para> <para>
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 <productname>PostgreSQL</productname>. Because of the optimal for <productname>PostgreSQL</productname>. Because of the
way that the kernel implements memory overcommit, the kernel may way that the kernel implements memory overcommit, the kernel may
terminate the <productname>PostgreSQL</productname> server (the terminate the <productname>PostgreSQL</productname> server (the
@ -3285,51 +3285,45 @@ default:\
Out of Memory: Killed process 12345 (postmaster). Out of Memory: Killed process 12345 (postmaster).
</programlisting> </programlisting>
This indicates that the <filename>postmaster</filename> process This indicates that the <filename>postmaster</filename> 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,
<productname>PostgreSQL</productname> will need to be restarted. <productname>PostgreSQL</productname> will need to be restarted.
</para> </para>
<para> <para>
To avoid this situation, run <productname>PostgreSQL</productname> One way to avoid this problem is to run
<productname>PostgreSQL</productname>
on a machine where you can be sure that other processes will not 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 run the machine out of memory.
and/or paranoid modes of overcommit handling, you can also relieve this </para>
problem by altering the system's default behaviour. This can be
determined by examining the function <function>vm_enough_memory</> <para>
in the file <filename>mm/mmap.c</> in the kernel source. If this On Linux 2.6 and later, a better solution is to modify the kernel's
file reveals that the strict or paranoid modes are supported by behavior so that it will not <quote>overcommit</> memory. This is
your kernel, turn one of these modes on by using done by selecting strict overcommit mode via sysctl:
<programlisting> <programlisting>
sysctl -w vm.overcommit_memory=2 sysctl -w vm.overcommit_memory=2
</programlisting> </programlisting>
for strict mode, or or placing an equivalent entry in <filename>/etc/sysctl.conf</>.
<programlisting> You may also wish to modify the related setting
sysctl -w vm.overcommit_memory=3 <literal>vm.overcommit_ratio</>. For details see the kernel documentation
</programlisting> file <filename>Documentation/vm/overcommit-accounting</>.
for paranoid mode, or placing an equivalent entry in
<filename>/etc/sysctl.conf</>. For more information on memory
overcommit handling and the meaning of these kernel settings,
consult the file
<filename>Documentation/vm/overcommit-accounting</filename> in a
recent version of the source code for the Linux kernel.
</para> </para>
<caution>
<para> <para>
Using these settings with a kernel which does not support these Some vendors' Linux 2.4 kernels are reported to have early versions
modes will almost certainly increase the danger of the kernel of the 2.6 overcommit sysctl. However, setting
killing the database server, rather than reducing it. If in any <literal>vm.overcommit_memory</> to 2
doubt, consult a kernel expert or your kernel vendor. on a kernel that does not have the relevant code will make
</para> things worse not better. It is recommended that you inspect
</caution> the actual kernel source code (see the function
<function>vm_enough_memory</> in the file <filename>mm/mmap.c</>)
<para> to verify what is supported in your copy before you try this in a 2.4
The method described above for changing the kernel's overcommit installation. The presence of the <filename>overcommit-accounting</>
behavior should work with Linux kernel versions 2.6 and later. In addition, documentation file should <emphasis>not</> be taken as evidence that the
some versions of the 2.4 kernel distributed by some vendors may feature is there. If in any doubt, consult a kernel expert or your
also support this functionality. However, it is known that some kernel vendor.
vendor documents suggest that they support them while examination
of the kernel source reveals that they do not.
</para> </para>
</sect2> </sect2>
</sect1> </sect1>