From 36bffe4ffa5a7492d78a889e7feb0838be5449f1 Mon Sep 17 00:00:00 2001 From: Robert Haas Date: Thu, 30 Aug 2012 14:14:22 -0400 Subject: [PATCH] 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. --- doc/src/sgml/runtime.sgml | 18 ++++++++++++++++-- 1 file changed, 16 insertions(+), 2 deletions(-) diff --git a/doc/src/sgml/runtime.sgml b/doc/src/sgml/runtime.sgml index 7ba18f0319..ff8ef7ed40 100644 --- a/doc/src/sgml/runtime.sgml +++ b/doc/src/sgml/runtime.sgml @@ -1269,8 +1269,9 @@ default:\ optimal for PostgreSQL. Because of the way that the kernel implements memory overcommit, the kernel might terminate the PostgreSQL postmaster (the - master server process) if the memory demands of - another process cause the system to run out of virtual memory. + master server process) if the memory demands of either + PostgreSQL or another process cause the + system to run out of virtual memory. @@ -1297,6 +1298,19 @@ Out of Memory: Killed process 12345 (postgres). swap space are exhausted. + + If PostgreSQL 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 + shared_buffers + and work_mem. 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 + max_connections + and instead make use of external connection-pooling software. + + On Linux 2.6 and later, it is possible to modify the kernel's behavior so that it will not overcommit memory. -- 2.40.0