Received: from localhost (maia-2.hub.org [200.46.204.187]) by postgresql.org (Postfix) with ESMTP id 70BB69FB502 for ; Fri, 2 Mar 2007 08:26:13 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.187]) (amavisd-new, port 10024) with ESMTP id 59766-05 for ; Fri, 2 Mar 2007 08:26:01 -0400 (AST) X-Greylist: delayed 00:24:51.367034 by SQLgrey-1.7.4 Received: from serv1.oss.ntt.co.jp (serv1.oss.ntt.co.jp [222.151.198.98]) by postgresql.org (Postfix) with ESMTP id 163499FB462 for ; Fri, 2 Mar 2007 08:26:06 -0400 (AST) Received: from [127.0.0.1] (unknown [172.17.1.114]) by serv1.oss.ntt.co.jp (Postfix) with ESMTP id 1D543104001; Fri, 2 Mar 2007 21:01:12 +0900 (JST) Message-ID: <45E811CB.8040300@oss.ntt.co.jp> Date: Fri, 02 Mar 2007 21:00:11 +0900 From: Toru SHIMOGAKI User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: pgsql-docs@postgresql.org Subject: avoiding a problem that postmaster is suddenly killed by OOM-Killer Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0.001 tagged_above=0 required=5 tests=BAYES_50 X-Spam-Level: X-Archive-Number: 200703/1 X-Sequence-Number: 4172 Hello all, To avoid a problem that postmaster is suddenly killed by OOM-Killer, some techniques are described in "16.4.3. Linux Memory Overcommit" http://www.postgresql.org/docs/8.2/interactive/kernel-resources.html#AEN19362 One way to avoid this problem is to run PostgreSQL on a machine where you can be sure that other processes will not run the machine out of memory. On Linux 2.6 and later, a better solution is to modify the kernel's behavior so that it will not "overcommit" memory. This is done by selecting strict overcommit mode via sysctl: This description may be misread, at least to me, because OOM-Killer's behavor has nothing to do with overcommit mode. It is true that turning overcommit off is one of the solutions but it is not enough: OOM-Killer is invoked whenever physical memory is exhausted not only by user application but also by in-kernel working. I checked it with some kernel hackers on Linux-2.6.9-42 (RHEL4 Update4). I think that to avoid this problem, "increasing swap area" should be added on this manual. Increasing both physical memory and swap area is easy to understand, but increasing physical memory is not software solution. Best regards, -- Toru SHIMOGAKI