Re: Pre-allocation of shared memory ... - Mailing list pgsql-hackers
From | Bruce Momjian |
---|---|
Subject | Re: Pre-allocation of shared memory ... |
Date | |
Msg-id | 200306121531.h5CFVSU03219@candle.pha.pa.us Whole thread Raw |
In response to | Re: Pre-allocation of shared memory ... (Tom Lane <tgl@sss.pgh.pa.us>) |
Responses |
Re: Pre-allocation of shared memory ...
Re: Pre-allocation of shared memory ... |
List | pgsql-hackers |
OK, doc patch attached and applied. Improvements? --------------------------------------------------------------------------- Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > What really kills [:-)] me is that they allocate memory assuming I will > > not be using it all, then terminate the executable in an unrecoverable > > way when I go to use the memory. > > To be fair, I'm probably misstating things by referring to malloc(). > The big problem probably comes from fork() with copy-on-write --- the > kernel has no good way to estimate how much of the shared address space > will eventually become private modified copies, but it can be forgiven > for wanting to make less than the worst-case assumption. > > Still, if you are wanting to run a reliable server, I think worst-case > assumption is exactly what you want. Swap space is cheap, and there's > no reason you shouldn't have enough swap to support the worst-case > situation. If the swap area goes largely unused, that's fine. > > The policy they're calling "paranoid overcommit" (don't allocate more > virtual memory than you have swap) is as far as I know the standard on > all Unixen other than Linux; certainly it's the traditional behavior. > > regards, tom lane > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 Index: doc/src/sgml/runtime.sgml =================================================================== RCS file: /cvsroot/pgsql-server/doc/src/sgml/runtime.sgml,v retrieving revision 1.184 diff -c -c -r1.184 runtime.sgml *** doc/src/sgml/runtime.sgml 11 Jun 2003 22:13:21 -0000 1.184 --- doc/src/sgml/runtime.sgml 12 Jun 2003 15:29:45 -0000 *************** *** 2780,2785 **** --- 2780,2795 ---- <filename>/usr/src/linux/include/asm-<replaceable>xxx</>/shmpara m.h</> and <filename>/usr/src/linux/include/linux/sem.h</>. </para> + + <para> + Linux has poor default memory overcommit behavior. Rather than + failing if it can not reserve enough memory, it returns success, + but later fails when the memory can't be mapped and terminates + the application. To prevent unpredictable process termination, use: + <programlisting> + sysctl -w vm.overcommit_memory=3 + </programlisting> + </para> </listitem> </varlistentry>
pgsql-hackers by date: