Re: Pre-allocation of shared memory ...

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: Pre-allocation of shared memory ...
Дата
Msg-id 200306121531.h5CFVSU03219@candle.pha.pa.us
обсуждение исходный текст
Ответ на Re: Pre-allocation of shared memory ...  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Pre-allocation of shared memory ...  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Pre-allocation of shared memory ...  ("Shridhar Daithankar" <shridhar_daithankar@persistent.co.in>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Pre-allocation of shared memory ...
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Pre-allocation of shared memory ...