client connections is the maximum socket connection queue
    length.  If more than that many connection requests arrive within a very
    short period, some may get rejected before the <productname>PostgreSQL</productname> server can service
    the requests, with those clients receiving unhelpful connection failure
    errors such as <quote>Resource temporarily unavailable</quote> or
    <quote>Connection refused</quote>.  The default queue length limit is 128
    on many platforms.  To raise it, adjust the appropriate kernel parameter
    via <application>sysctl</application>, then restart the <productname>PostgreSQL</productname> server.
    The parameter is variously named <varname>net.core.somaxconn</varname>
    on Linux, <varname>kern.ipc.soacceptqueue</varname> on newer FreeBSD,
    and <varname>kern.ipc.somaxconn</varname> on macOS and other BSD
    variants.
   </para>
  </sect2>

  <sect2 id="linux-memory-overcommit">
   <title>Linux Memory Overcommit</title>

   <indexterm>
    <primary>memory overcommit</primary>
   </indexterm>

   <indexterm>
    <primary>OOM</primary>
   </indexterm>

   <indexterm>
    <primary>overcommit</primary>
   </indexterm>

   <para>
    The default virtual memory behavior on Linux is not
    optimal for <productname>PostgreSQL</productname>. Because of the
    way that the kernel implements memory overcommit, the kernel might
    terminate the <productname>PostgreSQL</productname> postmaster (the
    supervisor server process) if the memory demands of either
    <productname>PostgreSQL</productname> or 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 (postgres).
</programlisting>
    This indicates that the <filename>postgres</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.  If memory is tight, increasing the swap space of the
    operating system can help avoid the problem, because the
    out-of-memory (OOM) killer is invoked only when physical memory and
    swap space are exhausted.
   </para>

   <para>
    If <productname>PostgreSQL</productname> itself is the cause of the
    system running out of memory, you can avoid the problem by changing
    your configuration.  In some cases, it may help to lower memory-related
    configuration parameters, particularly
    <link linkend="guc-shared-buffers"><varname>shared_buffers</varname></link>,
    <link linkend="guc-work-mem"><varname>work_mem</varname></link>, and
    <link linkend="guc-hash-mem-multiplier"><varname>hash_mem_multiplier</varname></link>.
    In other cases, the problem may be caused by allowing too many
    connections to the database server itself.  In many cases, it may
    be better to reduce
    <link linkend="guc-max-connections"><varname>max_connections</varname></link>
    and instead make use of external connection-pooling software.
   </para>

   <para>
    It is possible to modify the
    kernel's behavior so that it will not <quote>overcommit</quote> memory.
    Although this setting will not prevent the <ulink
    url="https://lwn.net/Articles/104179/">OOM killer</ulink> from being invoked
    altogether, it will lower the chances significantly and will therefore
    lead to more robust system behavior.  This is done by selecting strict
    overcommit mode via <command>sysctl</command>:
<programlisting>
sysctl -w vm.overcommit_memory=2