that the postmaster has a preferential setting.
   </para>

  </sect2>

  <sect2 id="linux-huge-pages">
   <title>Linux Huge Pages</title>

   <para>
    Using huge pages reduces overhead when using large contiguous chunks of
    memory, as <productname>PostgreSQL</productname> does, particularly when
    using large values of <xref linkend="guc-shared-buffers"/>.  To use this
    feature in <productname>PostgreSQL</productname> you need a kernel
    with <varname>CONFIG_HUGETLBFS=y</varname> and
    <varname>CONFIG_HUGETLB_PAGE=y</varname>. You will also have to configure
    the operating system to provide enough huge pages of the desired size.
    The runtime-computed parameter
    <xref linkend="guc-shared-memory-size-in-huge-pages"/> reports the number
    of huge pages required.  This parameter can be viewed before starting the
    server with a <command>postgres</command> command like:
<programlisting>
$ <userinput>postgres -D $PGDATA -C shared_memory_size_in_huge_pages</userinput>
3170
$ <userinput>grep ^Hugepagesize /proc/meminfo</userinput>
Hugepagesize:       2048 kB
$ <userinput>ls /sys/kernel/mm/hugepages</userinput>
hugepages-1048576kB  hugepages-2048kB
</programlisting>

     In this example the default is 2MB, but you can also explicitly request
     either 2MB or 1GB with <xref linkend="guc-huge-page-size"/> to adapt
     the number of pages calculated by
     <varname>shared_memory_size_in_huge_pages</varname>.

     While we need at least <literal>3170</literal> huge pages in this example,
     a larger setting would be appropriate if other programs on the machine
     also need huge pages.
     We can set this with:
<programlisting>
# <userinput>sysctl -w vm.nr_hugepages=3170</userinput>
</programlisting>
     Don't forget to add this setting to <filename>/etc/sysctl.conf</filename>
     so that it is reapplied after reboots.  For non-default huge page sizes,
     we can instead use:
<programlisting>
# <userinput>echo 3170 > /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages</userinput>
</programlisting>
    It is also possible to provide these settings at boot time using
    kernel parameters such as <literal>hugepagesz=2M hugepages=3170</literal>.
   </para>

   <para>
    Sometimes the kernel is not able to allocate the desired number of huge
    pages immediately due to fragmentation, so it might be necessary
    to repeat the command or to reboot.  (Immediately after a reboot, most of
    the machine's memory should be available to convert into huge pages.)
    To verify the huge page allocation situation for a given size, use:
<programlisting>
$ <userinput>cat /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages</userinput>
</programlisting>
   </para>

   <para>
    It may also be necessary to give the database server's operating system
    user permission to use huge pages by setting
    <varname>vm.hugetlb_shm_group</varname> via <application>sysctl</application>, and/or
    give permission to lock memory with <command>ulimit -l</command>.
   </para>

   <para>
    The default behavior for huge pages in
    <productname>PostgreSQL</productname> is to use them when possible, with
    the system's default huge page size, and
    to fall back to normal pages on failure. To enforce the use of huge
    pages, you can set <xref linkend="guc-huge-pages"/>
    to <literal>on</literal> in <filename>postgresql.conf</filename>.
    Note that with this setting <productname>PostgreSQL</productname> will fail to
    start if not enough huge pages are available.
   </para>

   <para>
    For a detailed description of the <productname>Linux</productname> huge
    pages feature have a look
    at <ulink url="https://www.kernel.org/doc/Documentation/vm/hugetlbpage.txt"></ulink>.
   </para>

  </sect2>
 </sect1>


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

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

  <para>
   There are several ways to shut