<!-- $PostgreSQL: pgsql/doc/src/sgml/runtime.sgml,v 1.381 2007/03/30 03:19:02 momjian Exp $ -->

<!-- $PostgreSQL: pgsql/doc/src/sgml/runtime.sgml,v 1.382 2007/11/0119:06:01 tgl Exp $ -->

<chapter Id="runtime">

<title>Operating System Environment</title>

relevant for <productname>PostgreSQL</>). Almost all modern

operating systems provide these features, but not all of them have

them turned on or sufficiently sized by default, especially systems

with BSD heritage. (For the <systemitem class="osname">Windows</>

port, <productname>PostgreSQL</> provides its own replacement

implementation of these facilities.)

with BSD heritage. (On <systemitem class="osname">Windows</>,

<productname>PostgreSQL</> provides its own replacement

implementation of these facilities, and so most of this section

can be disregarded.)

</para>

<para>

<row>

<entry><varname>SEMMNI</></>

<entry>Maximum number of semaphore identifiers (i.e., sets)</>

<entry>at least <literal>ceil(max_connections / 16)</literal></>

<entry>at least <literal>ceil((max_connections + autovacuum_max_workers) / 16)</literal></>

</row>

<row>

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

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

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

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

</row>

<row>

shared memory parameter is <varname>SHMMAX</>, the maximum size, in

bytes, of a shared memory segment. If you get an error message from

<function>shmget</> like <errorname>Invalid argument</>, it is

likely that this limit has been exceeded. The size of the required

likely that this limit has been exceeded.The size of the required

shared memory segment varies depending on several

<productname>PostgreSQL</> configuration parameters, as shown in

<xref linkend="shared-memory-parameters">.

<xref linkend="shared-memory-parameters">. (Any error message you might

get will include the exact size of the failed allocation request.)

You can, as a temporary solution, lower some of those settings to

avoid the failure. As a rough approximation, you can estimate the

required segment size as 500 kB plus the variable amounts shown in

the table. (Any error message you might get will include the exact

size of the failed allocation request.) While it is possible to get

avoid the failure. While it is possible to get

<productname>PostgreSQL</> to run with <varname>SHMMAX</> as small as

1 MB, you needat least 4 MBfor acceptable performance, and desirable

settings are in the tens of megabytes.

2 MB, you needconsiderably morefor acceptable performance. Desirable

settings are in the tensto hundredsof megabytes.

</para>

<para>

<para>

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

(<xref linkend="guc-max-connections">), in sets of 16. Each such set will

(<xref linkend="guc-max-connections">) and allowed autovacuum worker

process (<xref linkend="guc-autovacuum-max-workers">), in sets of 16.

Each such set will

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

number</quote>, to detect 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 <varname>max_connections</> plus one extra for each 16

allowed connections (see the formula in <xref

as high as <varname>max_connections</> plus

<varname>autovacuum_max_workers</>, plus one extra for each 16

allowed connections plus workers (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

least <literal>ceil((max_connections + autovacuum_max_workers) / 16)</>.

Lowering the number

of allowed connections is a temporary workaround for failures,

which are usually confusingly worded <errorname>No space

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

sort of configuration commonly used for other databases such

as <application>DB/2</application>.</para>

<para> It might, however, be necessary to modify the global

<para> It might, however, be necessary to modify the global

<command>ulimit</command> information in

<filename>/etc/security/limits</filename>, as the default hard

limits for file sizes (<varname>fsize</varname>) and numbers of

<indexterm><primary>Linux</><secondary>IPC configuration</></>

<listitem>

<para>

The default settings are only suitable for small installations

(the default maximum segment size is 32 MB). However, the remaining

The default maximum segment size is 32 MB, which is only adequate

for small <productname>PostgreSQL</productname> installations.

However, the remaining

defaults are quite generously sized, and usually do not require

changes. The maximum shared memory segment size can be changed via the

<command>sysctl</command> interface. For example, to allow 128 MB,

<listitem>

<para>

At least in version 2.6, the default maximum size of a shared

memorysegments is too low for <productname>PostgreSQL</>. The

memorysegment is too low for <productname>PostgreSQL</>. The

relevant settings can be changed in <filename>/etc/system</>,

for example:

<programlisting>

<thead>

<row>

<entry>Name</>

<entry>Approximate multiplier (bytes per increment)</>

<entry>Approximate multiplier (bytes per increment) as of 8.3</>

</row>

</thead>

<tbody>

<row>

<entry><xref linkend="guc-max-connections"></>

<entry>400 + 270 * <xref linkend="guc-max-locks-per-transaction"></entry>

<entry>1800 + 270 * <xref linkend="guc-max-locks-per-transaction"></entry>

</row>

<row>

<entry><xref linkend="guc-autovacuum-max-workers"></>

<entry>1800 + 270 * <xref linkend="guc-max-locks-per-transaction"></entry>

</row>

<row>

<entry><xref linkend="guc-max-prepared-transactions"></>

<entry>600 + 270 * <xref linkend="guc-max-locks-per-transaction"></entry>

<entry>770 + 270 * <xref linkend="guc-max-locks-per-transaction"></entry>

</row>

<row>

<entry><xref linkend="guc-shared-buffers"></>

<entry>8300 (assuming 8 kB <symbol>BLCKSZ</>)</entry>

<entry>8400 (assuming 8 kB <symbol>BLCKSZ</>)</entry>

</row>

<row>

<entry><xref linkend="guc-max-fsm-pages"></>

<entry>6</>

</row>

<row>

<entry>Fixed space requirements</>

<entry>770 kB</entry>

</row>

</tbody>

</tgroup>

</table>