runtime.sgml

PostgreSQL 8.1.4的源码 适用于Linux下的开源数据库系统

set semsys:seminfo_semmsl=32
</programlisting>
        You need to reboot for the changes to take effect.
       </para>

       <para>
        See also <ulink
        url="http://sunsite.uakom.sk/sunworldonline/swol-09-1997/swol-09-insidesolaris.html"></>
        for information on shared memory under
        <productname>Solaris</>.
       </para>
      </listitem>
     </varlistentry>


     <varlistentry>
      <term><systemitem class="osname">UnixWare</></term>
      <indexterm><primary>UnixWare</><secondary>IPC configuration</></>
      <listitem>
       <para>
        On <productname>UnixWare</> 7, the maximum size for shared
        memory segments is only 512 kB in the default configuration.
        To display the current value of <varname>SHMMAX</>, run
<programlisting>
/etc/conf/bin/idtune -g SHMMAX
</programlisting>
        which displays the current, default, minimum, and maximum
        values. To set a new value for <varname>SHMMAX</>,
        run
<programlisting>
/etc/conf/bin/idtune SHMMAX <replaceable>value</>
</programlisting>
        where <replaceable>value</> is the new value you want to use
        (in bytes). After setting <varname>SHMMAX</>, rebuild the
        kernel:
<programlisting>
/etc/conf/bin/idbuild -B
</programlisting>
        and reboot.
       </para>
      </listitem>
     </varlistentry>

    </variablelist>


   <table id="shared-memory-parameters">
    <title>Configuration parameters affecting
    <productname>PostgreSQL</productname>'s shared memory usage</>

    <tgroup cols="2">
     <thead>
      <row>
       <entry>Name</>
       <entry>Approximate multiplier (bytes per increment)</>
      </row>
     </thead>

     <tbody>
      <row>
       <entry><xref linkend="guc-max-connections"></>
       <entry>400 + 220 * <xref linkend="guc-max-locks-per-transaction"></entry>
      </row>

      <row>
       <entry><xref linkend="guc-max-prepared-transactions"></>
       <entry>600 + 220 * <xref linkend="guc-max-locks-per-transaction"></entry>
      </row>

      <row>
       <entry><xref linkend="guc-shared-buffers"></>
       <entry>8300 (assuming 8K <symbol>BLCKSZ</>)</entry>
      </row>

      <row>
       <entry><xref linkend="guc-wal-buffers"></>
       <entry>8200 (assuming 8K <symbol>BLCKSZ</>)</entry>
      </row>

      <row>
       <entry><xref linkend="guc-max-fsm-relations"></>
       <entry>70</>
      </row>

      <row>
       <entry><xref linkend="guc-max-fsm-pages"></>
       <entry>6</>
      </row>
     </tbody>
    </tgroup>
   </table>
  </sect2>


  <sect2>
   <title>Resource Limits</title>

   <para>
    Unix-like operating systems enforce various kinds of resource limits
    that might interfere with the operation of your
    <productname>PostgreSQL</productname> server. Of particular
    importance are limits on the number of processes per user, the
    number of open files per process, and the amount of memory available
    to each process. Each of these have a <quote>hard</quote> and a
    <quote>soft</quote> limit. The soft limit is what actually counts
    but it can be changed by the user up to the hard limit. The hard
    limit can only be changed by the root user. The system call
    <function>setrlimit</function> is responsible for setting these
    parameters. The shell's built-in command <command>ulimit</command>
    (Bourne shells) or <command>limit</command> (<application>csh</>) is
    used to control the resource limits from the command line. On
    BSD-derived systems the file <filename>/etc/login.conf</filename>
    controls the various resource limits set during login. See the
    operating system documentation for details. The relevant
    parameters are <varname>maxproc</varname>,
    <varname>openfiles</varname>, and <varname>datasize</varname>. For
    example:
<programlisting>
default:\
...
        :datasize-cur=256M:\
        :maxproc-cur=256:\
        :openfiles-cur=256:\
...
</programlisting>
    (<literal>-cur</literal> is the soft limit.  Append
    <literal>-max</literal> to set the hard limit.)
   </para>

   <para>
    Kernels can also have system-wide limits on some resources.
    <itemizedlist>
     <listitem>
      <para>
      On <productname>Linux</productname>
      <filename>/proc/sys/fs/file-max</filename> determines the
      maximum number of open files that the kernel will support.  It can
      be changed by writing a different number into the file or by
      adding an assignment in <filename>/etc/sysctl.conf</filename>.
      The maximum limit of files per process is fixed at the time the
      kernel is compiled; see
      <filename>/usr/src/linux/Documentation/proc.txt</filename> for
      more information.
      </para>
     </listitem>
    </itemizedlist>
   </para>

   <para>
    The <productname>PostgreSQL</productname> server uses one process
    per connection so you should provide for at least as many processes
    as allowed connections, in addition to what you need for the rest
    of your system.  This is usually not a problem but if you run
    several servers on one machine things might get tight.
   </para>

   <para>
    The factory default limit on open files is often set to
    <quote>socially friendly</quote> values that allow many users to
    coexist on a machine without using an inappropriate fraction of
    the system resources.  If you run many servers on a machine this
    is perhaps what you want, but on dedicated servers you may want to
    raise this limit.
   </para>

   <para>
    On the other side of the coin, some systems allow individual
    processes to open large numbers of files; if more than a few
    processes do so then the system-wide limit can easily be exceeded.
    If you find this happening, and you do not want to alter the
    system-wide limit, you can set <productname>PostgreSQL</>'s <xref
    linkend="guc-max-files-per-process"> configuration parameter to
    limit the consumption of open files.
   </para>
  </sect2>

  <sect2>
   <title>Linux Memory Overcommit</title>

   <para>
    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 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.
    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.
   </para>

   <para>
    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
    run the machine out of memory.
   </para>

   <para>
    On Linux 2.6 and later, a better solution is to modify the kernel's
    behavior so that it will not <quote>overcommit</> memory.  This is
    done by selecting strict overcommit mode via <command>sysctl</command>:
<programlisting>
sysctl -w vm.overcommit_memory=2
</programlisting>
    or placing an equivalent entry in <filename>/etc/sysctl.conf</>.
    You may also wish to modify the related setting 
    <literal>vm.overcommit_ratio</>.  For details see the kernel documentation
    file <filename>Documentation/vm/overcommit-accounting</>.
   </para>

   <para>
    Some vendors' Linux 2.4 kernels are reported to have early versions
    of the 2.6 overcommit <command>sysctl</command> parameter.  However, setting
    <literal>vm.overcommit_memory</> to 2
    on a kernel that does not have the relevant code will make
    things worse not better.  It is recommended that you inspect
    the actual kernel source code (see the function
    <function>vm_enough_memory</> in the file <filename>mm/mmap.c</>)
    to verify what is supported in your copy before you try this in a 2.4
    installation.  The presence of the <filename>overcommit-accounting</>
    documentation file should <emphasis>not</> be taken as evidence that the
    feature is there.  If in any doubt, consult a kernel expert or your
    kernel vendor.
   </para>
  </sect2>
 </sect1>


 <sect1 id="postmaster-shutdown">
  <title>Shutting Down the Server</title>

  <indexterm zone="postmaster-shutdown">
   <primary>shutdown</>
  </indexterm>

  <para>
   There are several ways to shut down the database server. You control
   the type of shutdown by sending different signals to the
   <command>postmaster</command> process.

   <variablelist>
    <varlistentry>
     <term><systemitem>SIGTERM</systemitem><indexterm><primary>SIGTERM</></></term>
     <listitem>
      <para>
       After receiving <systemitem>SIGTERM</systemitem>, the server
       disallows new connections, but lets existing sessions end their
       work normally. It shuts down only after all of the sessions
       terminate normally. This is the <firstterm>Smart
       Shutdown</firstterm>.
      </para>
     </listitem>
    </varlistentry>

    <varlistentry>
     <term><systemitem>SIGINT</systemitem><indexterm><primary>SIGINT</></></term>
     <listitem>
      <para>
       The server disallows new connections and sends all existing
       server processes <systemitem>SIGTERM</systemitem>, which will cause them
       to abort their current transactions and exit promptly. It then
       waits for the server processes to exit and finally shuts down. This is the
       <firstterm>Fast Shutdown</firstterm>.
      </para>
     </listitem>
    </varlistentry>

    <varlistentry>
     <term><systemitem>SIGQUIT</systemitem><indexterm><primary>SIGQUIT</></></term>
     <listitem>
      <para>
      This is the <firstterm>Immediate Shutdown</firstterm>, which
      will cause the <command>postmaster</command> process to send a
      <systemitem>SIGQUIT</systemitem> to all child processes and exit
      immediately, without properly shutting itself down. The child processes
      likewise exit immediately upon receiving
      <systemitem>SIGQUIT</systemitem>. This will lead to recovery (by
      replaying the WAL log) upon next start-up. This is recommended
      only in emergencies.
      </para>
     </listitem>
    </varlistentry>
   </variablelist>
  </para>

  <para>
   The <xref linkend="app-pg-ctl"> program provides a convenient
   interface for sending these signals to shut down the server.
  </para>

  <para>
   Alternatively, you can send the signal directly using <command>kill</>.
   The <acronym>PID</> of the <command>postmaster</command> process can be
   found using the <command>ps</command> program, or from the file
   <filename>postmaster.pid</filename> in the data directory. For
   example, to do a fast shutdown:
<screen>
$ <userinput>kill -INT `head -1 /usr/local/pgsql/data/postmaster.pid`</userinput>
</screen>
  </para>

   <important>
    <para>
     It is best not to use <systemitem>SIGKILL</systemitem> to shut down
     the server.  Doing so will prevent the server from releasing
     shared memory and semaphores, which may then have to be done
     manually before a new server can be started.  Furthermore,
     <systemitem>SIGKILL</systemitem> kills the <command>postmaster</command>
     process without letting it relay the signal to its subprocesses,
     so it will be necessary to kill the individual subprocesses by hand as
     well.
    </para>
   </important>
 </sect1>

 <sect1 id="encryption-options">