At the time I wrote the original 2.6 was not out even in prerelease, which is why I was deliberately somewhat vague about it. It is still in prerelease, and it will in fact work slightly differently from what was in some 2.4 kernels - there are 2 settings that govern this instead of 1. Here is the 2.6 description straight from linux-2.6.0-test9/Documentation/vm/overcommit-accounting:


-------------------------------------------
The Linux kernel supports three overcommit handling modes

0       -       Heuristic overcommit handling. Obvious overcommits of
               address space are refused. Used for a typical system. It
               ensures a seriously wild allocation fails while allowing
               overcommit to reduce swap usage.  root is allowed to
               allocate slighly more memory in this mode. This is the
               default.

1       -       No overcommit handling. Appropriate for some scientific
               applications.

2       -       (NEW) strict overcommit. The total address space commit
               for the system is not permitted to exceed swap + a
               configurable percentage (default is 50) of physical RAM.
               Depending on the percentage you use, in most situations
               this means a process will not be killed while accessing
               pages but will receive errors on memory allocation as
               appropriate.

The overcommit policy is set via the sysctl `vm.overcommit_memory'.

The overcommit percentage is set via `vm.overcommit_ratio'.
-----------------------------------------------------



Also note that this is wrong for 2.4:

     run the machine out of memory. If your kernel supports the strict
!     paranoid modes of overcommit handling, you can also relieve this

There are 2 modes: strict (allow commit up to sizeof(swap plus 1/2 RAM) ) and paranoid (allow commit up to sizeof(swap) ).


Wordsmith it however you like


cheers

andrew


Neil Conway wrote:


This patch makes some improvements to the section of the documentation
that describes the Linux 2.4 memory overcommit behavior.

I removed the almost content-free assertion that "You will need enough
swap space to cover your memory needs." If this is intended to
communicate anything meaningful, can someone rephrase it, please?

This patch also includes a fix for a typo noticed by Robert Treat.

Is this suitable for 7.4 (either the whole patch, or just the typo
fix)?

-Neil


------------------------------------------------------------------------

Index: doc/src/sgml/runtime.sgml
===================================================================
RCS file: /var/lib/cvs/pgsql-server/doc/src/sgml/runtime.sgml,v
retrieving revision 1.218
diff -c -r1.218 runtime.sgml
*** doc/src/sgml/runtime.sgml 14 Nov 2003 15:43:22 -0000 1.218
--- doc/src/sgml/runtime.sgml 16 Nov 2003 02:07:42 -0000
***************
*** 1294,1300 ****
<para>
Unfortunately, there is no well-defined method for determining
ideal values for the family of <quote>cost</quote> variables that
! below. You are encouraged to experiment and share
your findings.
</para>
</note>
--- 1294,1300 ----
<para>
Unfortunately, there is no well-defined method for determining
ideal values for the family of <quote>cost</quote> variables that
! appear below. You are encouraged to experiment and share
your findings.
</para>
</note>
***************
*** 3267,3301 ****
<title>Linux Memory Overcommit</title>
<para>
! Linux kernels of version 2.4.* have a poor default memory
! overcommit behavior, which can result in the PostgreSQL server
! (<filename>postmaster</filename> process) being killed by the
! kernel if the memory demands of another process cause the system
! to run out of memory.
</para>
<para>
! If this happens, you will see a kernel message looking like this
! (consult your system documentation and configuration on where to
! look for such a message):
<programlisting>
Out of Memory: Killed process 12345 (postmaster). </programlisting>
! And, of course, you will find that your database server has
! disappeared.
</para>
<para>
To avoid this situation, run <productname>PostgreSQL</productname>
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
! <function>vm_enough_memory</> in the file <filename>mm/mmap.c</>
! in the kernel source. If this file reveals that the strict and/or
! paranoid modes are supported by your kernel, turn one of these
! modes on by using
<programlisting>
sysctl -w vm.overcommit_memory=2
</programlisting>
--- 3267,3302 ----
<title>Linux Memory Overcommit</title>
<para>
! In Linux 2.4, the default virtual memory configuration is not
! optimal for <productname>PostgreSQL</productname>. Because of the
! way that the kernel implements memory overcommit, the kernel may
! terminate the <productname>PostgreSQL</productname> server (the
! <filename>postmaster</filename> process) if the memory demands of
! another process cause the system to run out of virtual memory.
</para>
<para>
! 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):
<programlisting>
Out of Memory: Killed process 12345 (postmaster). </programlisting>
! This indicates that the <filename>postmaster</filename> process
! has been terminated due to memory pressure;
! <productname>PostgreSQL</productname> will need to be restarted.
</para>
<para>
To avoid this situation, run <productname>PostgreSQL</productname>
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
! 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 <function>vm_enough_memory</>
! in the file <filename>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
<programlisting>
sysctl -w vm.overcommit_memory=2
</programlisting>
***************
*** 3304,3315 ****
sysctl -w vm.overcommit_memory=3
</programlisting>
for paranoid mode, or placing an equivalent entry in
! <filename>/etc/sysctl.conf</>.
</para>
<caution>
<para>
! Using these settings in 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.
--- 3305,3320 ----
sysctl -w vm.overcommit_memory=3
</programlisting>
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>
<caution>
<para>
! 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.
***************
*** 3317,3331 ****
</caution>
<para>
! These modes are expected to be supported in all 2.6 and later
! kernels. Some vendor 2.4 kernels may also support these modes. It
! is, however, known that some vendor documents suggest that they
! support them while examination of the kernel source reveals that
! they do not.
! </para>
! ! <para>
! Note, you will need enough swap space to cover all your memory needs.
</para>
</sect2>
</sect1>
--- 3322,3333 ----
</caution>
<para>
! The method described above for changing the kernel's overcommit
! behavior should work with Linux kernel 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.
</para>
</sect2>
</sect1>


------------------------------------------------------------------------


---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])




---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Reply via email to