-
+
Operating System Environment
relevant for
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 Windows>
- port,
PostgreSQL> provides its own replacement
- implementation of these facilities.)
+ with BSD heritage. (On Windows>,
+
PostgreSQL> provides its own replacement
+ implementation of these facilities, and so most of this section
+ can be disregarded.)
|
SEMMNI>>
Maximum number of semaphore identifiers (i.e., sets)>
- at least ceil(max_connections / 16)>
+ at least ceil((max_connections + autovacuum_max_workers) / 16)>
|
SEMMNS>>
Maximum number of semaphores system-wide>
- ceil(max_connections / 16) * 17 plus room for other applications>
+ ceil((max_connections + autovacuum_max_workers) / 16) * 17 plus room for other applications>
|
shared memory parameter is SHMMAX>, the maximum size, in
bytes, of a shared memory segment. If you get an error message from
shmget> like 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
PostgreSQL> configuration parameters, as shown in
- .
+ . (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
PostgreSQL> to run with SHMMAX> as small as
- 1 MB, you need at least 4 MB for acceptable performance, and desirable
- settings are in the tens of megabytes.
+ 2 MB, you need considerably more for acceptable performance. Desirable
+ settings are in the tens to hundreds of megabytes.
PostgreSQL> uses one semaphore per allowed connection
- (), in sets of 16. Each such set will
+ () and allowed autovacuum worker
+ process (), in sets of 16.
+ Each such set will
also contain a 17th semaphore which contains a magic
number, to detect collision with semaphore sets used by
other applications. The maximum number of semaphores in the system
is set by SEMMNS>, which consequently must be at least
- as high as max_connections> plus one extra for each 16
- allowed connections (see the formula in
+ as high as max_connections> plus
+ autovacuum_max_workers>, plus one extra for each 16
+ allowed connections plus workers (see the formula in
linkend="sysvipc-parameters">). The parameter 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 ceil(max_connections / 16)>. Lowering the number
+ least ceil((max_connections + autovacuum_max_workers) / 16)>.
+ Lowering the number
of allowed connections is a temporary workaround for failures,
which are usually confusingly worded No space
left on device>, from the function semget>.
sort of configuration commonly used for other databases such
-
It might , however, be necessary to modify the global
+
It might, however, be necessary to modify the global
ulimit information in
/etc/security/limits, as the default hard
limits for file sizes (fsize) and numbers of
Linux>IPC configuration>>
- 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
PostgreSQL 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
sysctl interface. For example, to allow 128 MB,
At least in version 2.6, the default maximum size of a shared
- memory segment
s is too low for
PostgreSQL>. The
+ memory segment is too low for
PostgreSQL>. The
relevant settings can be changed in /etc/system>,
for example:
|
Name>
- Approximate multiplier (bytes per increment)>
+ Approximate multiplier (bytes per increment) as of 8.3>
|
>
- 400 + 270 *
+ 1800 + 270 *
+
+
+ |
+ >
+ 1800 + 270 *
|
>
- 600 + 270 *
+ 770 + 270 *
|
>
- 8300 (assuming 8 kB BLCKSZ>)
+ 8400 (assuming 8 kB BLCKSZ>)
|
>
6>
+
+ |
+ Fixed space requirements>
+ 770 kB
+