<!--

$Header: /cvsroot/pgsql/doc/src/sgml/runtime.sgml,v 1.41 2000/12/03 14:36:45 petere Exp $

$Header: /cvsroot/pgsql/doc/src/sgml/runtime.sgml,v 1.42 2000/12/17 11:22:00 petere Exp $

-->

<Chapter Id="runtime">

limits of the IPC resources then the postmaster will refuse to

start up and should leave a marginally instructive error message

about which problem was encountered and what needs to be done

about it. The relevant kernel parameters are named

about it. (See also <xref linkend="postmaster-start-failures">.)

The relevant kernel parameters are named

consistently across different systems; <xref

linkend="sysvipc-parameters"> gives an overview. The methods to

set them, however, vary; suggestions for some platforms are given

below. Be aware that you will have to reboot your

below. Be aware that you willprobablyhave to reboot your

machine at least, possibly even recompile the kernel, to change these

settings.

</para>

<row>

<entry><varname>SHMMIN</></>

<entry>Minimum size of shared memory segment (bytes)</>

<entry>1 (at most144)</>

<entry>1 (at mostabout 256 kB)</>

</row>

<row>

<entry><varname>SHMSEG</></>

<entry>Maximum number of shared memory segments per process</>

<entry>must be at least 3, but the default is much higher</>

<entry>only 1 segment is needed, but the default is much higher</>

</row>

<row>

<row>

<entry><varname>SEMMNS</></>

<entry>Maximum number of semaphores system-wide</>

<entry>max_connectionsrounded up to multiple of 16, + room for other applications</>

<entry>ceil(max_connections/ 16) * 17 + room for other applications</>

</row>

<row>

<entry><varname>SEMMSL</></>

<entry>Maximum number of semaphores per set</>

<entry>&gt;=16</>

<entry>&gt;=17</>

</row>

<row>

estimate the required segment size as the number of buffers times

the block size (8192 kB by default) plus ample overhead (at least

half a megabyte). Any error message you might get will contain the

size of the failed allocation. (<productname>Postgres</> will

actually use three shared memory segments, but the size of the

other two is negligible for this consideration.)

size of the failed allocation.

</para>

<para>

Less likely to cause problems is the minimum size for shared

memory segments (<varname>SHMMIN</>), whichmust be atleast 144

for <productname>Postgres</> (it's usually just 1), and the

maximum number of segments system-wide (<varname>SHMMNI</>, as

mentioned, 3 are needed) or per-process (<varname>SHMSEG</>,

shared memory in the system; see theplatform-specific

instructions below.

memory segments (<varname>SHMMIN</>), whichshould be atmost

somewhere around 256 kBfor <productname>Postgres</> (it is

usually just 1). Themaximum number of segments system-wide

(<varname>SHMMNI</>) or per-process (<varname>SHMSEG</>) should

systems also have a limit on thetotal amount of shared memory in

the system; see the platform-specificinstructions below.

</para>

<para>

<productname>Postgres</> uses one semaphore per allowed connection

(<option>-N</> option), in sets of 16. The maximum number of

semaphores in the system is set by <varname>SEMMNS</>, which

consequently must be at least as high as the connection setting.

The parameter <varname>SEMMNI</> determines the limit on the

number of semaphore sets that can exist on the system at one time.

Hence this parameter must be at least

<literal>ceil(max_connections / 16)</>. Lowering the number of

allowed connections is a temporary workaround for failures, which

are usually confusingly worded <quote><errorname>No space left on

device</></>, from the function <function>semget()</>.

(<option>-N</> option), in sets of 16. Each such set will also

contain a 17th semaphore which contains a <quote>magic

number</quote>, to avoid collision with semaphore sets used by

other applications. The maximum number of semaphores in the system

is set by <varname>SEMMNS</>, which consequently must be at least

as high as the connection setting plus one extra for each 16

allowed connections (see the formula in <xref

linkend="sysvipc-parameters">. The parameter <varname>SEMMNI</>

determines the limit on the number of semaphore sets that can

exist on the system at one time. Hence this parameter must be at

least <literal>ceil(max_connections / 16)</>. Lowering the number

of allowed connections is a temporary workaround for failures,

which are usually confusingly worded <quote><errorname>No space

left on device</></>, from the function <function>semget()</>.

</para>

<para>

<para>

The <varname>SEMMSL</> parameter, which determines how many

semaphores can be in a set, must be at least16 for

semaphores can be in a set, must be at least17 for

<productname>Postgres</>.

</para>

<varlistentry>

<term>HPUX</>

<term>HP-UX</>

<listitem>

<para>

The default settings tend to suffice for normal installations.

On <productname>HPUX</> 10, the factory default for

On <productname>HP-UX</> 10, the factory default for

<varname>SEMMNS</> is 128, which might be too low for larger

database sites.

</para>

<term>Linux</>

<listitem>

<para>

System V IPC is enabled by default and sufficiently sized for

most uses. The relevant parameters are in

The default shared memory limit (both

<varname>SHMMAX</varname> and <varname>SHMALL</varname>) is 32

MB in 2.2 kernels, but it can be changed in the

<filename>proc</filename> file system (without reboot). For

example, to allow 128 MB:

<screen>

<prompt>$</prompt> <userinput>echo 134217728 >/proc/sys/kernel/shmall</userinput>

<prompt>$</prompt> <userinput>echo 134217728 >/proc/sys/kernel/shmmax</userinput>

</screen>

You could put these commands into a script run at boot-time.

</para>

<para>

Other parameters are sufficiently sized for any application.

If you want to see for yourself look into

<filename>/usr/src/linux/include/asm-<replaceable>xxx</>/shmparam.h</>

and <filename>/usr/src/linux/include/linux/sem.h</>. Be sure

to do <command>make dep</> before rebuilding the kernel.

and <filename>/usr/src/linux/include/linux/sem.h</>.

</para>

</listitem>

</varlistentry>