codekingpro/portable-devtools
115k
1<?xml version="1.0" encoding="UTF-8" standalone="no"?>2<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>19.4. Managing Kernel Resources</title><link rel="stylesheet" type="text/css" href="stylesheet.css" /><link rev="made" href="pgsql-docs@lists.postgresql.org" /><meta name="generator" content="DocBook XSL Stylesheets Vsnapshot" /><link rel="prev" href="server-start.html" title="19.3. Starting the Database Server" /><link rel="next" href="server-shutdown.html" title="19.5. Shutting Down the Server" /></head><body id="docContent" class="container-fluid col-10"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="5" align="center">19.4. Managing Kernel Resources</th></tr><tr><td width="10%" align="left"><a accesskey="p" href="server-start.html" title="19.3. Starting the Database Server">Prev</a> </td><td width="10%" align="left"><a accesskey="u" href="runtime.html" title="Chapter 19. Server Setup and Operation">Up</a></td><th width="60%" align="center">Chapter 19. Server Setup and Operation</th><td width="10%" align="right"><a accesskey="h" href="index.html" title="PostgreSQL 16.3 Documentation">Home</a></td><td width="10%" align="right"> <a accesskey="n" href="server-shutdown.html" title="19.5. Shutting Down the Server">Next</a></td></tr></table><hr /></div><div class="sect1" id="KERNEL-RESOURCES"><div class="titlepage"><div><div><h2 class="title" style="clear: both">19.4. Managing Kernel Resources <a href="#KERNEL-RESOURCES" class="id_link">#</a></h2></div></div></div><div class="toc"><dl class="toc"><dt><span class="sect2"><a href="kernel-resources.html#SYSVIPC">19.4.1. Shared Memory and Semaphores</a></span></dt><dt><span class="sect2"><a href="kernel-resources.html#SYSTEMD-REMOVEIPC">19.4.2. systemd RemoveIPC</a></span></dt><dt><span class="sect2"><a href="kernel-resources.html#KERNEL-RESOURCES-LIMITS">19.4.3. Resource Limits</a></span></dt><dt><span class="sect2"><a href="kernel-resources.html#LINUX-MEMORY-OVERCOMMIT">19.4.4. Linux Memory Overcommit</a></span></dt><dt><span class="sect2"><a href="kernel-resources.html#LINUX-HUGE-PAGES">19.4.5. Linux Huge Pages</a></span></dt></dl></div><p>3 <span class="productname">PostgreSQL</span> can sometimes exhaust various operating system4 resource limits, especially when multiple copies of the server are running5 on the same system, or in very large installations. This section explains6 the kernel resources used by <span class="productname">PostgreSQL</span> and the steps you7 can take to resolve problems related to kernel resource consumption.8 </p><div class="sect2" id="SYSVIPC"><div class="titlepage"><div><div><h3 class="title">19.4.1. Shared Memory and Semaphores <a href="#SYSVIPC" class="id_link">#</a></h3></div></div></div><a id="id-1.6.6.7.3.2" class="indexterm"></a><a id="id-1.6.6.7.3.3" class="indexterm"></a><p>9 <span class="productname">PostgreSQL</span> requires the operating system to provide10 inter-process communication (<acronym class="acronym">IPC</acronym>) features, specifically11 shared memory and semaphores. Unix-derived systems typically provide12 <span class="quote">“<span class="quote"><span class="systemitem">System V</span></span>”</span> <acronym class="acronym">IPC</acronym>,13 <span class="quote">“<span class="quote"><span class="systemitem">POSIX</span></span>”</span> <acronym class="acronym">IPC</acronym>, or both.14 <span class="systemitem">Windows</span> has its own implementation of15 these features and is not discussed here.16 </p><p>17 By default, <span class="productname">PostgreSQL</span> allocates18 a very small amount of System V shared memory, as well as a much larger19 amount of anonymous <code class="function">mmap</code> shared memory.20 Alternatively, a single large System V shared memory region can be used21 (see <a class="xref" href="runtime-config-resource.html#GUC-SHARED-MEMORY-TYPE">shared_memory_type</a>).22 23 In addition a significant number of semaphores, which can be either24 System V or POSIX style, are created at server startup. Currently,25 POSIX semaphores are used on Linux and FreeBSD systems while other26 platforms use System V semaphores.27 </p><p>28 System V <acronym class="acronym">IPC</acronym> features are typically constrained by29 system-wide allocation limits.30 When <span class="productname">PostgreSQL</span> exceeds one of these limits,31 the server will refuse to start and32 should leave an instructive error message describing the problem33 and what to do about it. (See also <a class="xref" href="server-start.html#SERVER-START-FAILURES" title="19.3.1. Server Start-up Failures">Section 19.3.1</a>.) The relevant kernel34 parameters are named consistently across different systems; <a class="xref" href="kernel-resources.html#SYSVIPC-PARAMETERS" title="Table 19.1. System V IPC Parameters">Table 19.1</a> gives an overview. The methods to set35 them, however, vary. Suggestions for some platforms are given below.36 </p><div class="table" id="SYSVIPC-PARAMETERS"><p class="title"><strong>Table 19.1. <span class="systemitem">System V</span> <acronym class="acronym">IPC</acronym> Parameters</strong></p><div class="table-contents"><table class="table" summary="System V IPC Parameters" border="1"><colgroup><col class="col1" /><col class="col2" /><col class="col3" /></colgroup><thead><tr><th>Name</th><th>Description</th><th>Values needed to run one <span class="productname">PostgreSQL</span> instance</th></tr></thead><tbody><tr><td><code class="varname">SHMMAX</code></td><td>Maximum size of shared memory segment (bytes)</td><td>at least 1kB, but the default is usually much higher</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>same as <code class="varname">SHMMAX</code> if bytes,37 or <code class="literal">ceil(SHMMAX/PAGE_SIZE)</code> if pages,38 plus room for other applications</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 + autovacuum_max_workers + max_wal_senders + max_worker_processes + 5) / 16)</code> plus room for other applications</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 + autovacuum_max_workers + max_wal_senders + max_worker_processes + 5) / 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; do not change unless necessary)</td></tr></tbody></table></div></div><br class="table-break" /><p>39 <span class="productname">PostgreSQL</span> requires a few bytes of System V shared memory40 (typically 48 bytes, on 64-bit platforms) for each copy of the server.41 On most modern operating systems, this amount can easily be allocated.42 However, if you are running many copies of the server or you explicitly43 configure the server to use large amounts of System V shared memory (see44 <a class="xref" href="runtime-config-resource.html#GUC-SHARED-MEMORY-TYPE">shared_memory_type</a> and <a class="xref" href="runtime-config-resource.html#GUC-DYNAMIC-SHARED-MEMORY-TYPE">dynamic_shared_memory_type</a>), it may be necessary to45 increase <code class="varname">SHMALL</code>, which is the total amount of System V shared46 memory system-wide. Note that <code class="varname">SHMALL</code> is measured in pages47 rather than bytes on many systems.48 </p><p>49 Less likely to cause problems is the minimum size for shared50 memory segments (<code class="varname">SHMMIN</code>), which should be at most51 approximately 32 bytes for <span class="productname">PostgreSQL</span> (it is52 usually just 1). The maximum number of segments system-wide53 (<code class="varname">SHMMNI</code>) or per-process (<code class="varname">SHMSEG</code>) are unlikely54 to cause a problem unless your system has them set to zero.55 </p><p>56 When using System V semaphores,57 <span class="productname">PostgreSQL</span> uses one semaphore per allowed connection58 (<a class="xref" href="runtime-config-connection.html#GUC-MAX-CONNECTIONS">max_connections</a>), allowed autovacuum worker process59 (<a class="xref" href="runtime-config-autovacuum.html#GUC-AUTOVACUUM-MAX-WORKERS">autovacuum_max_workers</a>) and allowed background60 process (<a class="xref" href="runtime-config-resource.html#GUC-MAX-WORKER-PROCESSES">max_worker_processes</a>), in sets of 16.61 Each such set will62 also contain a 17th semaphore which contains a <span class="quote">“<span class="quote">magic63 number</span>”</span>, to detect collision with semaphore sets used by64 other applications. The maximum number of semaphores in the system65 is set by <code class="varname">SEMMNS</code>, which consequently must be at least66 as high as <code class="varname">max_connections</code> plus67 <code class="varname">autovacuum_max_workers</code> plus <code class="varname">max_wal_senders</code>,68 plus <code class="varname">max_worker_processes</code>, plus one extra for each 1669 allowed connections plus workers (see the formula in <a class="xref" href="kernel-resources.html#SYSVIPC-PARAMETERS" title="Table 19.1. System V IPC Parameters">Table 19.1</a>). The parameter <code class="varname">SEMMNI</code>70 determines the limit on the number of semaphore sets that can71 exist on the system at one time. Hence this parameter must be at72 least <code class="literal">ceil((max_connections + autovacuum_max_workers + max_wal_senders + max_worker_processes + 5) / 16)</code>.73 Lowering the number74 of allowed connections is a temporary workaround for failures,75 which are usually confusingly worded <span class="quote">“<span class="quote">No space76 left on device</span>”</span>, from the function <code class="function">semget</code>.77 </p><p>78 In some cases it might also be necessary to increase79 <code class="varname">SEMMAP</code> to be at least on the order of80 <code class="varname">SEMMNS</code>. If the system has this parameter81 (many do not), it defines the size of the semaphore82 resource map, in which each contiguous block of available semaphores83 needs an entry. When a semaphore set is freed it is either added to84 an existing entry that is adjacent to the freed block or it is85 registered under a new map entry. If the map is full, the freed86 semaphores get lost (until reboot). Fragmentation of the semaphore87 space could over time lead to fewer available semaphores than there88 should be.89 </p><p>90 Various other settings related to <span class="quote">“<span class="quote">semaphore undo</span>”</span>, such as91 <code class="varname">SEMMNU</code> and <code class="varname">SEMUME</code>, do not affect92 <span class="productname">PostgreSQL</span>.93 </p><p>94 When using POSIX semaphores, the number of semaphores needed is the95 same as for System V, that is one semaphore per allowed connection96 (<a class="xref" href="runtime-config-connection.html#GUC-MAX-CONNECTIONS">max_connections</a>), allowed autovacuum worker process97 (<a class="xref" href="runtime-config-autovacuum.html#GUC-AUTOVACUUM-MAX-WORKERS">autovacuum_max_workers</a>) and allowed background98 process (<a class="xref" href="runtime-config-resource.html#GUC-MAX-WORKER-PROCESSES">max_worker_processes</a>).99 On the platforms where this option is preferred, there is no specific100 kernel limit on the number of POSIX semaphores.101 </p><div class="variablelist"><dl class="variablelist"><dt><span class="term"><span class="systemitem">AIX</span>102 <a id="id-1.6.6.7.3.14.1.1.2" class="indexterm"></a>103 </span></dt><dd><p>104 It should not be necessary to do105 any special configuration for such parameters as106 <code class="varname">SHMMAX</code>, as it appears this is configured to107 allow all memory to be used as shared memory. That is the108 sort of configuration commonly used for other databases such109 as <span class="application">DB/2</span>.</p><p> It might, however, be necessary to modify the global110 <code class="command">ulimit</code> information in111 <code class="filename">/etc/security/limits</code>, as the default hard112 limits for file sizes (<code class="varname">fsize</code>) and numbers of113 files (<code class="varname">nofiles</code>) might be too low.114 </p></dd><dt><span class="term"><span class="systemitem">FreeBSD</span>115 <a id="id-1.6.6.7.3.14.2.1.2" class="indexterm"></a>116 </span></dt><dd><p>117 The default shared memory settings are usually good enough, unless118 you have set <code class="literal">shared_memory_type</code> to <code class="literal">sysv</code>.119 System V semaphores are not used on this platform.120 </p><p>121 The default IPC settings can be changed using122 the <code class="command">sysctl</code> or123 <code class="command">loader</code> interfaces. The following124 parameters can be set using <code class="command">sysctl</code>:125</p><pre class="screen">126<code class="prompt">#</code> <strong class="userinput"><code>sysctl kern.ipc.shmall=32768</code></strong>127<code class="prompt">#</code> <strong class="userinput"><code>sysctl kern.ipc.shmmax=134217728</code></strong>128</pre><p>129 To make these settings persist over reboots, modify130 <code class="filename">/etc/sysctl.conf</code>.131 </p><p>132 If you have set <code class="literal">shared_memory_type</code> to133 <code class="literal">sysv</code>, you might also want to configure your kernel134 to lock System V shared memory into RAM and prevent it from being paged135 out to swap. This can be accomplished using the <code class="command">sysctl</code>136 setting <code class="literal">kern.ipc.shm_use_phys</code>.137 </p><p>138 If running in a FreeBSD jail, you should set its139 <code class="literal">sysvshm</code> parameter to <code class="literal">new</code>, so that140 it has its own separate System V shared memory namespace.141 (Before FreeBSD 11.0, it was necessary to enable shared access to142 the host's IPC namespace from jails, and take measures to avoid143 collisions.)144 </p></dd><dt><span class="term"><span class="systemitem">NetBSD</span>145 <a id="id-1.6.6.7.3.14.3.1.2" class="indexterm"></a>146 </span></dt><dd><p>147 The default shared memory settings are usually good enough, unless148 you have set <code class="literal">shared_memory_type</code> to <code class="literal">sysv</code>.149 You will usually want to increase <code class="literal">kern.ipc.semmni</code>150 and <code class="literal">kern.ipc.semmns</code>,151 as <span class="systemitem">NetBSD</span>'s default settings152 for these are uncomfortably small.153 </p><p>154 IPC parameters can be adjusted using <code class="command">sysctl</code>,155 for example:156</p><pre class="screen">157<code class="prompt">#</code> <strong class="userinput"><code>sysctl -w kern.ipc.semmni=100</code></strong>158</pre><p>159 To make these settings persist over reboots, modify160 <code class="filename">/etc/sysctl.conf</code>.161 </p><p>162 If you have set <code class="literal">shared_memory_type</code> to163 <code class="literal">sysv</code>, you might also want to configure your kernel164 to lock System V shared memory into RAM and prevent it from being paged165 out to swap. This can be accomplished using the <code class="command">sysctl</code>166 setting <code class="literal">kern.ipc.shm_use_phys</code>.167 </p></dd><dt><span class="term"><span class="systemitem">OpenBSD</span>168 <a id="id-1.6.6.7.3.14.4.1.2" class="indexterm"></a>169 </span></dt><dd><p>170 The default shared memory settings are usually good enough, unless171 you have set <code class="literal">shared_memory_type</code> to <code class="literal">sysv</code>.172 You will usually want to173 increase <code class="literal">kern.seminfo.semmni</code>174 and <code class="literal">kern.seminfo.semmns</code>,175 as <span class="systemitem">OpenBSD</span>'s default settings176 for these are uncomfortably small.177 </p><p>178 IPC parameters can be adjusted using <code class="command">sysctl</code>,179 for example:180</p><pre class="screen">181<code class="prompt">#</code> <strong class="userinput"><code>sysctl kern.seminfo.semmni=100</code></strong>182</pre><p>183 To make these settings persist over reboots, modify184 <code class="filename">/etc/sysctl.conf</code>.185 </p></dd><dt><span class="term"><span class="systemitem">Linux</span>186 <a id="id-1.6.6.7.3.14.5.1.2" class="indexterm"></a>187 </span></dt><dd><p>188 The default shared memory settings are usually good enough, unless189 you have set <code class="literal">shared_memory_type</code> to <code class="literal">sysv</code>,190 and even then only on older kernel versions that shipped with low defaults.191 System V semaphores are not used on this platform.192 </p><p>193 The shared memory size settings can be changed via the194 <code class="command">sysctl</code> interface. For example, to allow 16 GB:195</p><pre class="screen">196<code class="prompt">$</code> <strong class="userinput"><code>sysctl -w kernel.shmmax=17179869184</code></strong>197<code class="prompt">$</code> <strong class="userinput"><code>sysctl -w kernel.shmall=4194304</code></strong>198</pre><p>199 To make these settings persist over reboots, see200 <code class="filename">/etc/sysctl.conf</code>.201 </p></dd><dt><span class="term"><span class="systemitem">macOS</span>202 <a id="id-1.6.6.7.3.14.6.1.2" class="indexterm"></a>203 </span></dt><dd><p>204 The default shared memory and semaphore settings are usually good enough, unless205 you have set <code class="literal">shared_memory_type</code> to <code class="literal">sysv</code>.206 </p><p>207 The recommended method for configuring shared memory in macOS208 is to create a file named <code class="filename">/etc/sysctl.conf</code>,209 containing variable assignments such as:210</p><pre class="programlisting">211kern.sysv.shmmax=4194304212kern.sysv.shmmin=1213kern.sysv.shmmni=32214kern.sysv.shmseg=8215kern.sysv.shmall=1024216</pre><p>217 Note that in some macOS versions,218 <span class="emphasis"><em>all five</em></span> shared-memory parameters must be set in219 <code class="filename">/etc/sysctl.conf</code>, else the values will be ignored.220 </p><p>221 <code class="varname">SHMMAX</code> can only be set to a multiple of 4096.222 </p><p>223 <code class="varname">SHMALL</code> is measured in 4 kB pages on this platform.224 </p><p>225 It is possible to change all but <code class="varname">SHMMNI</code> on the fly, using226 <span class="application">sysctl</span>. But it's still best to set up your preferred227 values via <code class="filename">/etc/sysctl.conf</code>, so that the values will be228 kept across reboots.229 </p></dd><dt><span class="term"><span class="systemitem">Solaris</span><br /></span><span class="term"><span class="systemitem">illumos</span></span></dt><dd><p>230 The default shared memory and semaphore settings are usually good enough for most231 <span class="productname">PostgreSQL</span> applications. Solaris defaults232 to a <code class="varname">SHMMAX</code> of one-quarter of system <acronym class="acronym">RAM</acronym>.233 To further adjust this setting, use a project setting associated234 with the <code class="literal">postgres</code> user. For example, run the235 following as <code class="literal">root</code>:236</p><pre class="programlisting">237projadd -c "PostgreSQL DB User" -K "project.max-shm-memory=(privileged,8GB,deny)" -U postgres -G postgres user.postgres238</pre><p>239 </p><p>240 This command adds the <code class="literal">user.postgres</code> project and241 sets the shared memory maximum for the <code class="literal">postgres</code>242 user to 8GB, and takes effect the next time that user logs243 in, or when you restart <span class="productname">PostgreSQL</span> (not reload).244 The above assumes that <span class="productname">PostgreSQL</span> is run by245 the <code class="literal">postgres</code> user in the <code class="literal">postgres</code>246 group. No server reboot is required.247 </p><p>248 Other recommended kernel setting changes for database servers which will249 have a large number of connections are:250</p><pre class="programlisting">251project.max-shm-ids=(priv,32768,deny)252project.max-sem-ids=(priv,4096,deny)253project.max-msg-ids=(priv,4096,deny)254</pre><p>255 </p><p>256 Additionally, if you are running <span class="productname">PostgreSQL</span>257 inside a zone, you may need to raise the zone resource usage258 limits as well. See "Chapter2: Projects and Tasks" in the259 <em class="citetitle">System Administrator's Guide</em> for more260 information on <code class="literal">projects</code> and <code class="command">prctl</code>.261 </p></dd></dl></div></div><div class="sect2" id="SYSTEMD-REMOVEIPC"><div class="titlepage"><div><div><h3 class="title">19.4.2. systemd RemoveIPC <a href="#SYSTEMD-REMOVEIPC" class="id_link">#</a></h3></div></div></div><a id="id-1.6.6.7.4.2" class="indexterm"></a><p>262 If <span class="productname">systemd</span> is in use, some care must be taken263 that IPC resources (including shared memory) are not prematurely264 removed by the operating system. This is especially of concern when265 installing PostgreSQL from source. Users of distribution packages of266 PostgreSQL are less likely to be affected, as267 the <code class="literal">postgres</code> user is then normally created as a system268 user.269 </p><p>270 The setting <code class="literal">RemoveIPC</code>271 in <code class="filename">logind.conf</code> controls whether IPC objects are272 removed when a user fully logs out. System users are exempt. This273 setting defaults to on in stock <span class="productname">systemd</span>, but274 some operating system distributions default it to off.275 </p><p>276 A typical observed effect when this setting is on is that shared memory277 objects used for parallel query execution are removed at apparently random278 times, leading to errors and warnings while attempting to open and remove279 them, like280</p><pre class="screen">281WARNING: could not remove shared memory segment "/PostgreSQL.1450751626": No such file or directory282</pre><p>283 Different types of IPC objects (shared memory vs. semaphores, System V284 vs. POSIX) are treated slightly differently285 by <span class="productname">systemd</span>, so one might observe that some IPC286 resources are not removed in the same way as others. But it is not287 advisable to rely on these subtle differences.288 </p><p>289 A <span class="quote">“<span class="quote">user logging out</span>”</span> might happen as part of a maintenance290 job or manually when an administrator logs in as291 the <code class="literal">postgres</code> user or something similar, so it is hard292 to prevent in general.293 </p><p>294 What is a <span class="quote">“<span class="quote">system user</span>”</span> is determined295 at <span class="productname">systemd</span> compile time from296 the <code class="symbol">SYS_UID_MAX</code> setting297 in <code class="filename">/etc/login.defs</code>.298 </p><p>299 Packaging and deployment scripts should be careful to create300 the <code class="literal">postgres</code> user as a system user by301 using <code class="literal">useradd -r</code>, <code class="literal">adduser --system</code>,302 or equivalent.303 </p><p>304 Alternatively, if the user account was created incorrectly or cannot be305 changed, it is recommended to set306</p><pre class="programlisting">307RemoveIPC=no308</pre><p>309 in <code class="filename">/etc/systemd/logind.conf</code> or another appropriate310 configuration file.311 </p><div class="caution"><h3 class="title">Caution</h3><p>312 At least one of these two things has to be ensured, or the PostgreSQL313 server will be very unreliable.314 </p></div></div><div class="sect2" id="KERNEL-RESOURCES-LIMITS"><div class="titlepage"><div><div><h3 class="title">19.4.3. Resource Limits <a href="#KERNEL-RESOURCES-LIMITS" class="id_link">#</a></h3></div></div></div><p>315 Unix-like operating systems enforce various kinds of resource limits316 that might interfere with the operation of your317 <span class="productname">PostgreSQL</span> server. Of particular318 importance are limits on the number of processes per user, the319 number of open files per process, and the amount of memory available320 to each process. Each of these have a <span class="quote">“<span class="quote">hard</span>”</span> and a321 <span class="quote">“<span class="quote">soft</span>”</span> limit. The soft limit is what actually counts322 but it can be changed by the user up to the hard limit. The hard323 limit can only be changed by the root user. The system call324 <code class="function">setrlimit</code> is responsible for setting these325 parameters. The shell's built-in command <code class="command">ulimit</code>326 (Bourne shells) or <code class="command">limit</code> (<span class="application">csh</span>) is327 used to control the resource limits from the command line. On328 BSD-derived systems the file <code class="filename">/etc/login.conf</code>329 controls the various resource limits set during login. See the330 operating system documentation for details. The relevant331 parameters are <code class="varname">maxproc</code>,332 <code class="varname">openfiles</code>, and <code class="varname">datasize</code>. For333 example:334</p><pre class="programlisting">335default:\336...337 :datasize-cur=256M:\338 :maxproc-cur=256:\339 :openfiles-cur=256:\340...341</pre><p>342 (<code class="literal">-cur</code> is the soft limit. Append343 <code class="literal">-max</code> to set the hard limit.)344 </p><p>345 Kernels can also have system-wide limits on some resources.346 </p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p>347 On <span class="productname">Linux</span> the kernel parameter348 <code class="varname">fs.file-max</code> determines the maximum number of open349 files that the kernel will support. It can be changed with350 <code class="literal">sysctl -w fs.file-max=<em class="replaceable"><code>N</code></em></code>.351 To make the setting persist across reboots, add an assignment352 in <code class="filename">/etc/sysctl.conf</code>.353 The maximum limit of files per process is fixed at the time the354 kernel is compiled; see355 <code class="filename">/usr/src/linux/Documentation/proc.txt</code> for356 more information.357 </p></li></ul></div><p>358 </p><p>359 The <span class="productname">PostgreSQL</span> server uses one process360 per connection so you should provide for at least as many processes361 as allowed connections, in addition to what you need for the rest362 of your system. This is usually not a problem but if you run363 several servers on one machine things might get tight.364 </p><p>365 The factory default limit on open files is often set to366 <span class="quote">“<span class="quote">socially friendly</span>”</span> values that allow many users to367 coexist on a machine without using an inappropriate fraction of368 the system resources. If you run many servers on a machine this369 is perhaps what you want, but on dedicated servers you might want to370 raise this limit.371 </p><p>372 On the other side of the coin, some systems allow individual373 processes to open large numbers of files; if more than a few374 processes do so then the system-wide limit can easily be exceeded.375 If you find this happening, and you do not want to alter the376 system-wide limit, you can set <span class="productname">PostgreSQL</span>'s <a class="xref" href="runtime-config-resource.html#GUC-MAX-FILES-PER-PROCESS">max_files_per_process</a> configuration parameter to377 limit the consumption of open files.378 </p><p>379 Another kernel limit that may be of concern when supporting large380 numbers of client connections is the maximum socket connection queue381 length. If more than that many connection requests arrive within a very382 short period, some may get rejected before the <span class="productname">PostgreSQL</span> server can service383 the requests, with those clients receiving unhelpful connection failure384 errors such as <span class="quote">“<span class="quote">Resource temporarily unavailable</span>”</span> or385 <span class="quote">“<span class="quote">Connection refused</span>”</span>. The default queue length limit is 128386 on many platforms. To raise it, adjust the appropriate kernel parameter387 via <span class="application">sysctl</span>, then restart the <span class="productname">PostgreSQL</span> server.388 The parameter is variously named <code class="varname">net.core.somaxconn</code>389 on Linux, <code class="varname">kern.ipc.soacceptqueue</code> on newer FreeBSD,390 and <code class="varname">kern.ipc.somaxconn</code> on macOS and other BSD391 variants.392 </p></div><div class="sect2" id="LINUX-MEMORY-OVERCOMMIT"><div class="titlepage"><div><div><h3 class="title">19.4.4. Linux Memory Overcommit <a href="#LINUX-MEMORY-OVERCOMMIT" class="id_link">#</a></h3></div></div></div><a id="id-1.6.6.7.6.2" class="indexterm"></a><a id="id-1.6.6.7.6.3" class="indexterm"></a><a id="id-1.6.6.7.6.4" class="indexterm"></a><p>393 The default virtual memory behavior on Linux is not394 optimal for <span class="productname">PostgreSQL</span>. Because of the395 way that the kernel implements memory overcommit, the kernel might396 terminate the <span class="productname">PostgreSQL</span> postmaster (the397 supervisor server process) if the memory demands of either398 <span class="productname">PostgreSQL</span> or another process cause the399 system to run out of virtual memory.400 </p><p>401 If this happens, you will see a kernel message that looks like402 this (consult your system documentation and configuration on where403 to look for such a message):404</p><pre class="programlisting">405Out of Memory: Killed process 12345 (postgres).406</pre><p>407 This indicates that the <code class="filename">postgres</code> process408 has been terminated due to memory pressure.409 Although existing database connections will continue to function410 normally, no new connections will be accepted. To recover,411 <span class="productname">PostgreSQL</span> will need to be restarted.412 </p><p>413 One way to avoid this problem is to run414 <span class="productname">PostgreSQL</span> on a machine where you can415 be sure that other processes will not run the machine out of416 memory. If memory is tight, increasing the swap space of the417 operating system can help avoid the problem, because the418 out-of-memory (OOM) killer is invoked only when physical memory and419 swap space are exhausted.420 </p><p>421 If <span class="productname">PostgreSQL</span> itself is the cause of the422 system running out of memory, you can avoid the problem by changing423 your configuration. In some cases, it may help to lower memory-related424 configuration parameters, particularly425 <a class="link" href="runtime-config-resource.html#GUC-SHARED-BUFFERS"><code class="varname">shared_buffers</code></a>,426 <a class="link" href="runtime-config-resource.html#GUC-WORK-MEM"><code class="varname">work_mem</code></a>, and427 <a class="link" href="runtime-config-resource.html#GUC-HASH-MEM-MULTIPLIER"><code class="varname">hash_mem_multiplier</code></a>.428 In other cases, the problem may be caused by allowing too many429 connections to the database server itself. In many cases, it may430 be better to reduce431 <a class="link" href="runtime-config-connection.html#GUC-MAX-CONNECTIONS"><code class="varname">max_connections</code></a>432 and instead make use of external connection-pooling software.433 </p><p>434 It is possible to modify the435 kernel's behavior so that it will not <span class="quote">“<span class="quote">overcommit</span>”</span> memory.436 Although this setting will not prevent the <a class="ulink" href="https://lwn.net/Articles/104179/" target="_top">OOM killer</a> from being invoked437 altogether, it will lower the chances significantly and will therefore438 lead to more robust system behavior. This is done by selecting strict439 overcommit mode via <code class="command">sysctl</code>:440</p><pre class="programlisting">441sysctl -w vm.overcommit_memory=2442</pre><p>443 or placing an equivalent entry in <code class="filename">/etc/sysctl.conf</code>.444 You might also wish to modify the related setting445 <code class="varname">vm.overcommit_ratio</code>. For details see the kernel documentation446 file <a class="ulink" href="https://www.kernel.org/doc/Documentation/vm/overcommit-accounting" target="_top">https://www.kernel.org/doc/Documentation/vm/overcommit-accounting</a>.447 </p><p>448 Another approach, which can be used with or without altering449 <code class="varname">vm.overcommit_memory</code>, is to set the process-specific450 <em class="firstterm">OOM score adjustment</em> value for the postmaster process to451 <code class="literal">-1000</code>, thereby guaranteeing it will not be targeted by the OOM452 killer. The simplest way to do this is to execute453</p><pre class="programlisting">454echo -1000 > /proc/self/oom_score_adj455</pre><p>456 in the <span class="productname">PostgreSQL</span> startup script just before457 invoking <code class="filename">postgres</code>.458 Note that this action must be done as root, or it will have no effect;459 so a root-owned startup script is the easiest place to do it. If you460 do this, you should also set these environment variables in the startup461 script before invoking <code class="filename">postgres</code>:462</p><pre class="programlisting">463export PG_OOM_ADJUST_FILE=/proc/self/oom_score_adj464export PG_OOM_ADJUST_VALUE=0465</pre><p>466 These settings will cause postmaster child processes to run with the467 normal OOM score adjustment of zero, so that the OOM killer can still468 target them at need. You could use some other value for469 <code class="envar">PG_OOM_ADJUST_VALUE</code> if you want the child processes to run470 with some other OOM score adjustment. (<code class="envar">PG_OOM_ADJUST_VALUE</code>471 can also be omitted, in which case it defaults to zero.) If you do not472 set <code class="envar">PG_OOM_ADJUST_FILE</code>, the child processes will run with the473 same OOM score adjustment as the postmaster, which is unwise since the474 whole point is to ensure that the postmaster has a preferential setting.475 </p></div><div class="sect2" id="LINUX-HUGE-PAGES"><div class="titlepage"><div><div><h3 class="title">19.4.5. Linux Huge Pages <a href="#LINUX-HUGE-PAGES" class="id_link">#</a></h3></div></div></div><p>476 Using huge pages reduces overhead when using large contiguous chunks of477 memory, as <span class="productname">PostgreSQL</span> does, particularly when478 using large values of <a class="xref" href="runtime-config-resource.html#GUC-SHARED-BUFFERS">shared_buffers</a>. To use this479 feature in <span class="productname">PostgreSQL</span> you need a kernel480 with <code class="varname">CONFIG_HUGETLBFS=y</code> and481 <code class="varname">CONFIG_HUGETLB_PAGE=y</code>. You will also have to configure482 the operating system to provide enough huge pages of the desired size.483 To determine the number of huge pages needed, use the484 <code class="command">postgres</code> command to see the value of485 <a class="xref" href="runtime-config-preset.html#GUC-SHARED-MEMORY-SIZE-IN-HUGE-PAGES">shared_memory_size_in_huge_pages</a>. Note that the486 server must be shut down to view this runtime-computed parameter.487 This might look like:488</p><pre class="programlisting">489$ <strong class="userinput"><code>postgres -D $PGDATA -C shared_memory_size_in_huge_pages</code></strong>4903170491$ <strong class="userinput"><code>grep ^Hugepagesize /proc/meminfo</code></strong>492Hugepagesize: 2048 kB493$ <strong class="userinput"><code>ls /sys/kernel/mm/hugepages</code></strong>494hugepages-1048576kB hugepages-2048kB495</pre><p>496 497 In this example the default is 2MB, but you can also explicitly request498 either 2MB or 1GB with <a class="xref" href="runtime-config-resource.html#GUC-HUGE-PAGE-SIZE">huge_page_size</a> to adapt499 the number of pages calculated by500 <code class="varname">shared_memory_size_in_huge_pages</code>.501 502 While we need at least <code class="literal">3170</code> huge pages in this example,503 a larger setting would be appropriate if other programs on the machine504 also need huge pages.505 We can set this with:506</p><pre class="programlisting">507# <strong class="userinput"><code>sysctl -w vm.nr_hugepages=3170</code></strong>508</pre><p>509 Don't forget to add this setting to <code class="filename">/etc/sysctl.conf</code>510 so that it is reapplied after reboots. For non-default huge page sizes,511 we can instead use:512</p><pre class="programlisting">513# <strong class="userinput"><code>echo 3170 > /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages</code></strong>514</pre><p>515 It is also possible to provide these settings at boot time using516 kernel parameters such as <code class="literal">hugepagesz=2M hugepages=3170</code>.517 </p><p>518 Sometimes the kernel is not able to allocate the desired number of huge519 pages immediately due to fragmentation, so it might be necessary520 to repeat the command or to reboot. (Immediately after a reboot, most of521 the machine's memory should be available to convert into huge pages.)522 To verify the huge page allocation situation for a given size, use:523</p><pre class="programlisting">524$ <strong class="userinput"><code>cat /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages</code></strong>525</pre><p>526 </p><p>527 It may also be necessary to give the database server's operating system528 user permission to use huge pages by setting529 <code class="varname">vm.hugetlb_shm_group</code> via <span class="application">sysctl</span>, and/or530 give permission to lock memory with <code class="command">ulimit -l</code>.531 </p><p>532 The default behavior for huge pages in533 <span class="productname">PostgreSQL</span> is to use them when possible, with534 the system's default huge page size, and535 to fall back to normal pages on failure. To enforce the use of huge536 pages, you can set <a class="xref" href="runtime-config-resource.html#GUC-HUGE-PAGES">huge_pages</a>537 to <code class="literal">on</code> in <code class="filename">postgresql.conf</code>.538 Note that with this setting <span class="productname">PostgreSQL</span> will fail to539 start if not enough huge pages are available.540 </p><p>541 For a detailed description of the <span class="productname">Linux</span> huge542 pages feature have a look543 at <a class="ulink" href="https://www.kernel.org/doc/Documentation/vm/hugetlbpage.txt" target="_top">https://www.kernel.org/doc/Documentation/vm/hugetlbpage.txt</a>.544 </p></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="server-start.html" title="19.3. Starting the Database Server">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="runtime.html" title="Chapter 19. Server Setup and Operation">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="server-shutdown.html" title="19.5. Shutting Down the Server">Next</a></td></tr><tr><td width="40%" align="left" valign="top">19.3. Starting the Database Server </td><td width="20%" align="center"><a accesskey="h" href="index.html" title="PostgreSQL 16.3 Documentation">Home</a></td><td width="40%" align="right" valign="top"> 19.5. Shutting Down the Server</td></tr></table></div></body></html>