aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorRobert Haas <rhaas@postgresql.org>2012-08-30 14:14:22 -0400
committerRobert Haas <rhaas@postgresql.org>2012-08-30 14:23:05 -0400
commitf6956eb74edcdf21339f9d200ef63c4015a5f4cb (patch)
tree319d7b90ff6749e3e5bf87f8b8b9b5bc82c9e0c4
parent657face6fea6e8e29944b839c4e5ceb6c63e251e (diff)
downloadpostgresql-f6956eb74edcdf21339f9d200ef63c4015a5f4cb.tar.gz
postgresql-f6956eb74edcdf21339f9d200ef63c4015a5f4cb.zip
Document how to prevent PostgreSQL itself from exhausting memory.
The existing documentation in Linux Memory Overcommit seemed to assume that PostgreSQL itself could never be the problem, or at least it didn't tell you what to do about it. Per discussion with Craig Ringer and Kevin Grittner.
-rw-r--r--doc/src/sgml/runtime.sgml20
1 files changed, 17 insertions, 3 deletions
diff --git a/doc/src/sgml/runtime.sgml b/doc/src/sgml/runtime.sgml
index 49e09a88480..4964de394f4 100644
--- a/doc/src/sgml/runtime.sgml
+++ b/doc/src/sgml/runtime.sgml
@@ -1309,9 +1309,10 @@ default:\
In Linux 2.4 and later, the default virtual memory behavior is not
optimal for <productname>PostgreSQL</productname>. Because of the
way that the kernel implements memory overcommit, the kernel might
- terminate the <productname>PostgreSQL</productname> server (the
- master server process) if the memory demands of
- another process cause the system to run out of virtual memory.
+ terminate the <productname>PostgreSQL</productname> postmaster (the
+ master server process) if the memory demands of either
+ <productname>PostgreSQL</productname> or another process cause the
+ system to run out of virtual memory.
</para>
<para>
@@ -1339,6 +1340,19 @@ Out of Memory: Killed process 12345 (postgres).
</para>
<para>
+ If <productname>PostgreSQL</productname> itself is the cause of the
+ system running out of memory, you can avoid the problem by changing
+ your configuration. In some cases, it may help to lower memory-related
+ configuration parameters, particularly
+ <link linkend="guc-shared-buffers"><varname>shared_buffers</></link>
+ and <link linkend="guc-work-mem"><varname>work_mem</></link>. In
+ other cases, the problem may be caused by allowing too many connections
+ to the database server itself. In many cases, it may be better to reduce
+ <link linkend="guc-max-connections"><varname>max_connections</></link>
+ and instead make use of external connection-pooling software.
+ </para>
+
+ <para>
On Linux 2.6 and later, it is possible to modify the
kernel's behavior so that it will not <quote>overcommit</> memory.
Although this setting will not prevent the <ulink