1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
|
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>16.4.Managing Kernel Resources</title>
<link rel="stylesheet" href="stylesheet.css" type="text/css">
<link rev="made" href="pgsql-docs@postgresql.org">
<meta name="generator" content="DocBook XSL Stylesheets V1.70.0">
<link rel="start" href="index.html" title="PostgreSQL 8.1.4 Documentation">
<link rel="up" href="runtime.html" title="Chapter16.Operating System Environment">
<link rel="prev" href="postmaster-start.html" title="16.3.Starting the Database Server">
<link rel="next" href="postmaster-shutdown.html" title="16.5.Shutting Down the Server">
<link rel="copyright" href="ln-legalnotice.html" title="Legal Notice">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="sect1" lang="en">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
<a name="kernel-resources"></a>16.4.Managing Kernel Resources</h2></div></div></div>
<p> A large <span class="productname">PostgreSQL</span> installation can quickly exhaust
various operating system resource limits. (On some systems, the
factory defaults are so low that you don't even need a really
“<span class="quote">large</span>” installation.) If you have encountered this kind of
problem, keep reading.
</p>
<div class="sect2" lang="en">
<div class="titlepage"><div><div><h3 class="title">
<a name="sysvipc"></a>16.4.1.Shared Memory and Semaphores</h3></div></div></div>
<a name="id641895"></a><a name="id641905"></a><p> Shared memory and semaphores are collectively referred to as
“<span class="quote"><span class="systemitem">System V</span>
<acronym class="acronym">IPC</acronym></span>” (together with message queues, which are not
relevant for <span class="productname">PostgreSQL</span>). 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 <span class="systemitem">Windows</span>,
<span class="systemitem">QNX</span> and <span class="systemitem">BeOS</span>
ports, <span class="productname">PostgreSQL</span> provides its own replacement
implementation of these facilities.)
</p>
<p> The complete lack of these facilities is usually manifested by an
<span class="errorname">Illegal system call</span> error upon server start. In
that case there's nothing left to do but to reconfigure your
kernel. <span class="productname">PostgreSQL</span> won't work without them.
</p>
<p> When <span class="productname">PostgreSQL</span> exceeds one of the various hard
<acronym class="acronym">IPC</acronym> limits, the server will refuse to start and
should leave an instructive error message describing the problem
encountered and what to do about it. (See also <a href="postmaster-start.html#postmaster-start-failures" title="16.3.1.Server Start-up Failures">Section16.3.1, “Server Start-up Failures”</a>.) The relevant kernel
parameters are named consistently across different systems; <a href="kernel-resources.html#sysvipc-parameters" title="Table16.1.System V IPC parameters">Table16.1, “<span class="systemitem">System V</span> <acronym class="acronym">IPC</acronym> parameters”</a> gives an overview. The methods to set
them, however, vary. Suggestions for some platforms are given below.
Be warned that it is often necessary to reboot your machine, and
possibly even recompile the kernel, to change these settings.
</p>
<div class="table">
<a name="sysvipc-parameters"></a><p class="title"><b>Table16.1.<span class="systemitem">System V</span> <acronym class="acronym">IPC</acronym> parameters</b></p>
<div class="table-contents"><table summary="System V IPC parameters" border="1">
<colgroup>
<col>
<col>
<col>
</colgroup>
<thead><tr>
<th>Name</th>
<th>Description</th>
<th>Reasonable values</th>
</tr></thead>
<tbody>
<tr>
<td><code class="varname">SHMMAX</code></td>
<td>Maximum size of shared memory segment (bytes)</td>
<td>at least several megabytes (see text)</td>
</tr>
<tr>
<td><code class="varname">SHMMIN</code></td>
<td>Minimum size of shared memory segment (bytes)</td>
<td>1</td>
</tr>
<tr>
<td><code class="varname">SHMALL</code></td>
<td>Total amount of shared memory available (bytes or pages)</td>
<td>if bytes, same as <code class="varname">SHMMAX</code>; if pages, <code class="literal">ceil(SHMMAX/PAGE_SIZE)</code>
</td>
</tr>
<tr>
<td><code class="varname">SHMSEG</code></td>
<td>Maximum number of shared memory segments per process</td>
<td>only 1 segment is needed, but the default is much higher</td>
</tr>
<tr>
<td><code class="varname">SHMMNI</code></td>
<td>Maximum number of shared memory segments system-wide</td>
<td>like <code class="varname">SHMSEG</code> plus room for other applications</td>
</tr>
<tr>
<td><code class="varname">SEMMNI</code></td>
<td>Maximum number of semaphore identifiers (i.e., sets)</td>
<td>at least <code class="literal">ceil(max_connections / 16)</code>
</td>
</tr>
<tr>
<td><code class="varname">SEMMNS</code></td>
<td>Maximum number of semaphores system-wide</td>
<td>
<code class="literal">ceil(max_connections / 16) * 17</code> plus room for other applications</td>
</tr>
<tr>
<td><code class="varname">SEMMSL</code></td>
<td>Maximum number of semaphores per set</td>
<td>at least 17</td>
</tr>
<tr>
<td><code class="varname">SEMMAP</code></td>
<td>Number of entries in semaphore map</td>
<td>see text</td>
</tr>
<tr>
<td><code class="varname">SEMVMX</code></td>
<td>Maximum value of semaphore</td>
<td>at least 1000 (The default is often 32767, don't change unless forced to)</td>
</tr>
</tbody>
</table></div>
</div>
<br class="table-break"><p> <a name="id642210"></a> The most important
shared memory parameter is <code class="varname">SHMMAX</code>, the maximum size, in
bytes, of a shared memory segment. If you get an error message from
<code class="function">shmget</code> like <span class="errorname">Invalid argument</span>, it is
likely that this limit has been exceeded. The size of the required
shared memory segment varies depending on several
<span class="productname">PostgreSQL</span> configuration parameters, as shown in
<a href="kernel-resources.html#shared-memory-parameters" title="Table16.2.Configuration parameters affecting
PostgreSQL's shared memory usage">Table16.2, “Configuration parameters affecting
<span class="productname">PostgreSQL</span>'s shared memory usage”</a>.
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
<span class="productname">PostgreSQL</span> to run with <code class="varname">SHMMAX</code> as small as
1 MB, you need at least 4 MB for acceptable performance, and desirable
settings are in the tens of megabytes.
</p>
<p> Some systems also have a limit on the total amount of shared memory in
the system (<code class="varname">SHMALL</code>). Make sure this is large enough
for <span class="productname">PostgreSQL</span> plus any other applications that
are using shared memory segments. (Caution: <code class="varname">SHMALL</code>
is measured in pages rather than bytes on many systems.)
</p>
<p> Less likely to cause problems is the minimum size for shared
memory segments (<code class="varname">SHMMIN</code>), which should be at most
approximately 500 kB for <span class="productname">PostgreSQL</span> (it is
usually just 1). The maximum number of segments system-wide
(<code class="varname">SHMMNI</code>) or per-process (<code class="varname">SHMSEG</code>) are unlikely
to cause a problem unless your system has them set to zero.
</p>
<p> <span class="productname">PostgreSQL</span> uses one semaphore per allowed connection
(<a href="runtime-config-connection.html#guc-max-connections">max_connections</a>), in sets of 16. Each such set will
also contain a 17th semaphore which contains a “<span class="quote">magic
number</span>”, to detect collision with semaphore sets used by
other applications. The maximum number of semaphores in the system
is set by <code class="varname">SEMMNS</code>, which consequently must be at least
as high as <code class="varname">max_connections</code> plus one extra for each 16
allowed connections (see the formula in <a href="kernel-resources.html#sysvipc-parameters" title="Table16.1.System V IPC parameters">Table16.1, “<span class="systemitem">System V</span> <acronym class="acronym">IPC</acronym> parameters”</a>). The parameter <code class="varname">SEMMNI</code>
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 <code class="literal">ceil(max_connections / 16)</code>. Lowering the number
of allowed connections is a temporary workaround for failures,
which are usually confusingly worded <span class="errorname">No space
left on device</span>, from the function <code class="function">semget</code>.
</p>
<p> In some cases it might also be necessary to increase
<code class="varname">SEMMAP</code> to be at least on the order of
<code class="varname">SEMMNS</code>. This parameter defines the size of the semaphore
resource map, in which each contiguous block of available semaphores
needs an entry. When a semaphore set is freed it is either added to
an existing entry that is adjacent to the freed block or it is
registered under a new map entry. If the map is full, the freed
semaphores get lost (until reboot). Fragmentation of the semaphore
space could over time lead to fewer available semaphores than there
should be.
</p>
<p> The <code class="varname">SEMMSL</code> parameter, which determines how many
semaphores can be in a set, must be at least 17 for
<span class="productname">PostgreSQL</span>.
</p>
<p> Various other settings related to “<span class="quote">semaphore undo</span>”, such as
<code class="varname">SEMMNU</code> and <code class="varname">SEMUME</code>, are not of concern
for <span class="productname">PostgreSQL</span>.
</p>
<div class="variablelist"><dl>
<dt><span class="term"><span class="systemitem">BSD/OS</span></span></dt>
<dd>
<p><b>Shared Memory.</b> By default, only 4 MB of shared memory is supported. Keep in
mind that shared memory is not pageable; it is locked in RAM.
To increase the amount of shared memory supported by your
system, add something like the following to your kernel configuration
file:
</p>
<pre class="programlisting">options "SHMALL=8192"
options "SHMMAX=\(SHMALL*PAGE_SIZE\)"</pre>
<p>
<code class="varname">SHMALL</code> is measured in 4KB pages, so a value of
1024 represents 4 MB of shared memory. Therefore the above increases
the maximum shared memory area to 32 MB.
For those running 4.3 or later, you will probably also need to increase
<code class="varname">KERNEL_VIRTUAL_MB</code> above the default <code class="literal">248</code>.
Once all changes have been made, recompile the kernel, and reboot.
</p>
<p> For those running 4.0 and earlier releases, use <code class="command">bpatch</code>
to find the <code class="varname">sysptsize</code> value in the current
kernel. This is computed dynamically at boot time.
</p>
<pre class="screen">$ <strong class="userinput"><code>bpatch -r sysptsize</code></strong>
<code class="computeroutput">0x9 = 9</code></pre>
<p>
Next, add <code class="varname">SYSPTSIZE</code> as a hard-coded value in the
kernel configuration file. Increase the value you found using
<code class="command">bpatch</code>. Add 1 for every additional 4 MB of
shared memory you desire.
</p>
<pre class="programlisting">options "SYSPTSIZE=16"</pre>
<p>
<code class="varname">sysptsize</code> cannot be changed by <code class="command">sysctl</code>.
</p>
<p><b>Semaphores.</b> You will probably want to increase the number of semaphores
as well; the default system total of 60 will only allow about
50 <span class="productname">PostgreSQL</span> connections. Set the
values you want in your kernel configuration file, e.g.:
</p>
<pre class="programlisting">options "SEMMNI=40"
options "SEMMNS=240"</pre>
<p>
</p>
</dd>
<dt><span class="term"><span class="systemitem">FreeBSD</span></span></dt>
<dd>
<p> The default settings are only suitable for small installations
(for example, default <code class="varname">SHMMAX</code> is 32
MB). Changes can be made via the <code class="command">sysctl</code> or
<code class="command">loader</code> interfaces. The following
parameters can be set using <code class="command">sysctl</code>:
</p>
<pre class="screen"><code class="prompt">$</code> <strong class="userinput"><code>sysctl -w kern.ipc.shmall=32768</code></strong>
<code class="prompt">$</code> <strong class="userinput"><code>sysctl -w kern.ipc.shmmax=134217728</code></strong>
<code class="prompt">$</code> <strong class="userinput"><code>sysctl -w kern.ipc.semmap=256</code></strong></pre>
<p>
To have these settings persist over reboots, modify
<code class="filename">/etc/sysctl.conf</code>.
</p>
<p> The remaining semaphore settings are read-only as far as
<code class="command">sysctl</code> is concerned, but can be changed
before boot using the <code class="command">loader</code> prompt:
</p>
<pre class="screen"><code class="prompt">(loader)</code> <strong class="userinput"><code>set kern.ipc.semmni=256</code></strong>
<code class="prompt">(loader)</code> <strong class="userinput"><code>set kern.ipc.semmns=512</code></strong>
<code class="prompt">(loader)</code> <strong class="userinput"><code>set kern.ipc.semmnu=256</code></strong></pre>
<p>
Similarly these can be saved between reboots in
<code class="filename">/boot/loader.conf</code>.
</p>
<p> You might also want to configure your kernel to lock shared
memory into RAM and prevent it from being paged out to swap.
This can be accomplished using the <code class="command">sysctl</code>
setting <code class="literal">kern.ipc.shm_use_phys</code>.
</p>
<p> If running in FreeBSD jails by enabling <span class="application">sysctl</span>'s
<code class="literal">security.jail.sysvipc_allowed</code>, <span class="application">postmaster</span>s
running in different jails should be run by different operating system
users. This improves security because it prevents non-root users
from interfering with shared memory or semaphores in a different jail,
and it allows the PostgreSQL IPC cleanup code to function properly.
(In FreeBSD 6.0 and later the IPC cleanup code doesn't properly detect
processes in other jails, preventing the running of postmasters on the
same port in different jails.)
</p>
<p> <span class="systemitem">FreeBSD</span> versions before 4.0 work like
<span class="systemitem">NetBSD</span> and <span class="systemitem"> OpenBSD</span> (see below).
</p>
</dd>
<dt>
<span xmlns="http://www.w3.org/TR/xhtml1/transitional" class="term"><span xmlns="" class="systemitem">NetBSD</span></span><br xmlns="http://www.w3.org/TR/xhtml1/transitional"></br><span class="term"><span class="systemitem">OpenBSD</span></span>
</dt>
<dd>
<p> The options <code class="varname">SYSVSHM</code> and <code class="varname">SYSVSEM</code> need
to be enabled when the kernel is compiled. (They are by
default.) The maximum size of shared memory is determined by
the option <code class="varname">SHMMAXPGS</code> (in pages). The following
shows an example of how to set the various parameters
(<span class="systemitem">OpenBSD</span> uses <code class="literal">option</code> instead):
</p>
<pre class="programlisting">options SYSVSHM
options SHMMAXPGS=4096
options SHMSEG=256
options SYSVSEM
options SEMMNI=256
options SEMMNS=512
options SEMMNU=256
options SEMMAP=256</pre>
<p>
</p>
<p> You might also want to configure your kernel to lock shared
memory into RAM and prevent it from being paged out to swap.
This can be accomplished using the <code class="command">sysctl</code>
setting <code class="literal">kern.ipc.shm_use_phys</code>.
</p>
</dd>
<dt><span class="term"><span class="systemitem">HP-UX</span></span></dt>
<dd>
<p> The default settings tend to suffice for normal installations.
On <span class="productname">HP-UX</span> 10, the factory default for
<code class="varname">SEMMNS</code> is 128, which might be too low for larger
database sites.
</p>
<p> <acronym class="acronym">IPC</acronym> parameters can be set in the <span class="application">System
Administration Manager</span> (<acronym class="acronym">SAM</acronym>) under
<span class="guimenu">Kernel
Configuration</span> → <span class="guimenuitem">Configurable Parameters</span>. Hit
<span class="guibutton">Create A New Kernel</span> when you're done.
</p>
</dd>
<dt><span class="term"><span class="systemitem">Linux</span></span></dt>
<dd>
<p> The default settings are only suitable for small installations
(the default max segment size is 32 MB). However the remaining
defaults are quite generously sized, and usually do not require
changes. The max segment size can be changed via the
<code class="command">sysctl</code> interface. For example, to allow 128 MB,
and explicitly set the maximum total shared memory size to 2097152
pages (the default):
</p>
<pre class="screen"><code class="prompt">$</code> <strong class="userinput"><code>sysctl -w kernel.shmmax=134217728</code></strong>
<code class="prompt">$</code> <strong class="userinput"><code>sysctl -w kernel.shmall=2097152</code></strong></pre>
<p>
In addition these settings can be saved between reboots in
<code class="filename">/etc/sysctl.conf</code>.
</p>
<p> Older distributions may not have the <code class="command">sysctl</code> program,
but equivalent changes can be made by manipulating the
<code class="filename">/proc</code> file system:
</p>
<pre class="screen"><code class="prompt">$</code> <strong class="userinput"><code>echo 134217728 >/proc/sys/kernel/shmmax</code></strong>
<code class="prompt">$</code> <strong class="userinput"><code>echo 2097152 >/proc/sys/kernel/shmall</code></strong></pre>
<p>
</p>
</dd>
<dt><span class="term"><span class="systemitem">MacOS X</span></span></dt>
<dd>
<p> In OS X 10.2 and earlier, edit the file
<code class="filename">/System/Library/StartupItems/SystemTuning/SystemTuning</code>
and change the values in the following commands:
</p>
<pre class="programlisting">sysctl -w kern.sysv.shmmax
sysctl -w kern.sysv.shmmin
sysctl -w kern.sysv.shmmni
sysctl -w kern.sysv.shmseg
sysctl -w kern.sysv.shmall</pre>
<p>
In OS X 10.3 and later, these commands have been moved to
<code class="filename">/etc/rc</code> and must be edited there. Note that
<code class="filename">/etc/rc</code> is usually overwritten by OS X updates (such as
10.3.6 to 10.3.7) so you should expect to have to redo your editing
after each update. In all versions, you'll need to reboot to make
changes take effect.
</p>
<p> In OS X 10.3.9 and later, the file <code class="filename">/etc/sysctl.conf</code>
allows shared memory setting to be saved across operating system
upgrades, and is the recommended method for setting these
parameters. When using this file, all five shared memory values
must be set or the changes will be ignored.
</p>
<p> <code class="varname">SHMALL</code> is measured in 4KB pages on this platform,
and recent releases of OS X reject attempts to set
<code class="varname">SHMALL</code> and <code class="varname">SHMMAX</code> to a value
that isn't an exact multiple of 4096.
</p>
</dd>
<dt><span class="term"><span class="systemitem">SCO OpenServer</span></span></dt>
<dd>
<p> In the default configuration, only 512 kB of shared memory per
segment is allowed. To increase the setting, first change to the
directory <code class="filename">/etc/conf/cf.d</code>. To display the current value of
<code class="varname">SHMMAX</code>, run
</p>
<pre class="programlisting">./configure -y SHMMAX</pre>
<p>
To set a new value for <code class="varname">SHMMAX</code>, run
</p>
<pre class="programlisting">./configure SHMMAX=<em class="replaceable"><code>value</code></em></pre>
<p>
where <em class="replaceable"><code>value</code></em> is the new value you want to use
(in bytes). After setting <code class="varname">SHMMAX</code>, rebuild the kernel:
</p>
<pre class="programlisting">./link_unix</pre>
<p>
and reboot.
</p>
</dd>
<dt><span class="term"><span class="systemitem">AIX</span></span></dt>
<dd>
<p> At least as of version 5.1, it should not be necessary to do
any special configuration for such parameters as
<code class="varname">SHMMAX</code>, as it appears this is configured to
allow all memory to be used as shared memory. That is the
sort of configuration commonly used for other databases such
as <span class="application">DB/2</span>.</p>
<p> It may, however, be necessary to modify the global
<code class="command">ulimit</code> information in
<code class="filename">/etc/security/limits</code>, as the default hard
limits for file sizes (<code class="varname">fsize</code>) and numbers of
files (<code class="varname">nofiles</code>) may be too low.
</p>
</dd>
<dt><span class="term"><span class="systemitem">Solaris</span></span></dt>
<dd>
<p> At least in version 2.6, the default maximum size of a shared
memory segments is too low for <span class="productname">PostgreSQL</span>. The
relevant settings can be changed in <code class="filename">/etc/system</code>,
for example:
</p>
<pre class="programlisting">set shmsys:shminfo_shmmax=0x2000000
set shmsys:shminfo_shmmin=1
set shmsys:shminfo_shmmni=256
set shmsys:shminfo_shmseg=256
set semsys:seminfo_semmap=256
set semsys:seminfo_semmni=512
set semsys:seminfo_semmns=512
set semsys:seminfo_semmsl=32</pre>
<p>
You need to reboot for the changes to take effect.
</p>
<p> See also <a href="http://sunsite.uakom.sk/sunworldonline/swol-09-1997/swol-09-insidesolaris.html" target="_top">http://sunsite.uakom.sk/sunworldonline/swol-09-1997/swol-09-insidesolaris.html</a>
for information on shared memory under
<span class="productname">Solaris</span>.
</p>
</dd>
<dt><span class="term"><span class="systemitem">UnixWare</span></span></dt>
<dd>
<p> On <span class="productname">UnixWare</span> 7, the maximum size for shared
memory segments is only 512 kB in the default configuration.
To display the current value of <code class="varname">SHMMAX</code>, run
</p>
<pre class="programlisting">/etc/conf/bin/idtune -g SHMMAX</pre>
<p>
which displays the current, default, minimum, and maximum
values. To set a new value for <code class="varname">SHMMAX</code>,
run
</p>
<pre class="programlisting">/etc/conf/bin/idtune SHMMAX <em class="replaceable"><code>value</code></em></pre>
<p>
where <em class="replaceable"><code>value</code></em> is the new value you want to use
(in bytes). After setting <code class="varname">SHMMAX</code>, rebuild the
kernel:
</p>
<pre class="programlisting">/etc/conf/bin/idbuild -B</pre>
<p>
and reboot.
</p>
</dd>
</dl></div>
<div class="table">
<a name="shared-memory-parameters"></a><p class="title"><b>Table16.2.Configuration parameters affecting
<span class="productname">PostgreSQL</span>'s shared memory usage</b></p>
<div class="table-contents"><table summary="Configuration parameters affecting
PostgreSQL's shared memory usage" border="1">
<colgroup>
<col>
<col>
</colgroup>
<thead><tr>
<th>Name</th>
<th>Approximate multiplier (bytes per increment)</th>
</tr></thead>
<tbody>
<tr>
<td><a href="runtime-config-connection.html#guc-max-connections">max_connections</a></td>
<td>400 + 220 * <a href="runtime-config-locks.html#guc-max-locks-per-transaction">max_locks_per_transaction</a>
</td>
</tr>
<tr>
<td><a href="runtime-config-resource.html#guc-max-prepared-transactions">max_prepared_transactions</a></td>
<td>600 + 220 * <a href="runtime-config-locks.html#guc-max-locks-per-transaction">max_locks_per_transaction</a>
</td>
</tr>
<tr>
<td><a href="runtime-config-resource.html#guc-shared-buffers">shared_buffers</a></td>
<td>8300 (assuming 8K <code class="symbol">BLCKSZ</code>)</td>
</tr>
<tr>
<td><a href="runtime-config-wal.html#guc-wal-buffers">wal_buffers</a></td>
<td>8200 (assuming 8K <code class="symbol">BLCKSZ</code>)</td>
</tr>
<tr>
<td><a href="runtime-config-resource.html#guc-max-fsm-relations">max_fsm_relations</a></td>
<td>70</td>
</tr>
<tr>
<td><a href="runtime-config-resource.html#guc-max-fsm-pages">max_fsm_pages</a></td>
<td>6</td>
</tr>
</tbody>
</table></div>
</div>
<br class="table-break">
</div>
<div class="sect2" lang="en">
<div class="titlepage"><div><div><h3 class="title">
<a name="id643652"></a>16.4.2.Resource Limits</h3></div></div></div>
<p> Unix-like operating systems enforce various kinds of resource limits
that might interfere with the operation of your
<span class="productname">PostgreSQL</span> server. Of particular
importance are limits on the number of processes per user, the
number of open files per process, and the amount of memory available
to each process. Each of these have a “<span class="quote">hard</span>” and a
“<span class="quote">soft</span>” limit. The soft limit is what actually counts
but it can be changed by the user up to the hard limit. The hard
limit can only be changed by the root user. The system call
<code class="function">setrlimit</code> is responsible for setting these
parameters. The shell's built-in command <code class="command">ulimit</code>
(Bourne shells) or <code class="command">limit</code> (<span class="application">csh</span>) is
used to control the resource limits from the command line. On
BSD-derived systems the file <code class="filename">/etc/login.conf</code>
controls the various resource limits set during login. See the
operating system documentation for details. The relevant
parameters are <code class="varname">maxproc</code>,
<code class="varname">openfiles</code>, and <code class="varname">datasize</code>. For
example:
</p>
<pre class="programlisting">default:\
...
:datasize-cur=256M:\
:maxproc-cur=256:\
:openfiles-cur=256:\
...</pre>
<p>
(<code class="literal">-cur</code> is the soft limit. Append
<code class="literal">-max</code> to set the hard limit.)
</p>
<p> Kernels can also have system-wide limits on some resources.
</p>
<div class="itemizedlist"><ul type="disc"><li><p> On <span class="productname">Linux</span>
<code class="filename">/proc/sys/fs/file-max</code> determines the
maximum number of open files that the kernel will support. It can
be changed by writing a different number into the file or by
adding an assignment in <code class="filename">/etc/sysctl.conf</code>.
The maximum limit of files per process is fixed at the time the
kernel is compiled; see
<code class="filename">/usr/src/linux/Documentation/proc.txt</code> for
more information.
</p></li></ul></div>
<p>
</p>
<p> The <span class="productname">PostgreSQL</span> server uses one process
per connection so you should provide for at least as many processes
as allowed connections, in addition to what you need for the rest
of your system. This is usually not a problem but if you run
several servers on one machine things might get tight.
</p>
<p> The factory default limit on open files is often set to
“<span class="quote">socially friendly</span>” values that allow many users to
coexist on a machine without using an inappropriate fraction of
the system resources. If you run many servers on a machine this
is perhaps what you want, but on dedicated servers you may want to
raise this limit.
</p>
<p> On the other side of the coin, some systems allow individual
processes to open large numbers of files; if more than a few
processes do so then the system-wide limit can easily be exceeded.
If you find this happening, and you do not want to alter the
system-wide limit, you can set <span class="productname">PostgreSQL</span>'s <a href="runtime-config-resource.html#guc-max-files-per-process">max_files_per_process</a> configuration parameter to
limit the consumption of open files.
</p>
</div>
<div class="sect2" lang="en">
<div class="titlepage"><div><div><h3 class="title">
<a name="id643848"></a>16.4.3.Linux Memory Overcommit</h3></div></div></div>
<p> In Linux 2.4 and later, the default virtual memory behavior is not
optimal for <span class="productname">PostgreSQL</span>. Because of the
way that the kernel implements memory overcommit, the kernel may
terminate the <span class="productname">PostgreSQL</span> server (the
<code class="filename">postmaster</code> process) if the memory demands of
another process cause the system to run out of virtual memory.
</p>
<p> 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):
</p>
<pre class="programlisting">Out of Memory: Killed process 12345 (postmaster). </pre>
<p>
This indicates that the <code class="filename">postmaster</code> 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,
<span class="productname">PostgreSQL</span> will need to be restarted.
</p>
<p> One way to avoid this problem is to run
<span class="productname">PostgreSQL</span>
on a machine where you can be sure that other processes will not
run the machine out of memory.
</p>
<p> On Linux 2.6 and later, a better solution is to modify the kernel's
behavior so that it will not “<span class="quote">overcommit</span>” memory. This is
done by selecting strict overcommit mode via <code class="command">sysctl</code>:
</p>
<pre class="programlisting">sysctl -w vm.overcommit_memory=2</pre>
<p>
or placing an equivalent entry in <code class="filename">/etc/sysctl.conf</code>.
You may also wish to modify the related setting
<code class="literal">vm.overcommit_ratio</code>. For details see the kernel documentation
file <code class="filename">Documentation/vm/overcommit-accounting</code>.
</p>
<p> Some vendors' Linux 2.4 kernels are reported to have early versions
of the 2.6 overcommit <code class="command">sysctl</code> parameter. However, setting
<code class="literal">vm.overcommit_memory</code> to 2
on a kernel that does not have the relevant code will make
things worse not better. It is recommended that you inspect
the actual kernel source code (see the function
<code class="function">vm_enough_memory</code> in the file <code class="filename">mm/mmap.c</code>)
to verify what is supported in your copy before you try this in a 2.4
installation. The presence of the <code class="filename">overcommit-accounting</code>
documentation file should <span class="emphasis"><em>not</em></span> be taken as evidence that the
feature is there. If in any doubt, consult a kernel expert or your
kernel vendor.
</p>
</div>
</div></body>
</html>
|
