Received: from maia.hub.org (unknown [200.46.208.211]) by mail.postgresql.org (Postfix) with ESMTP id 9594D632E37 for ; Wed, 3 Feb 2010 03:48:39 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.208.211]) (amavisd-maia, port 10024) with ESMTP id 22628-10 for ; Wed, 3 Feb 2010 07:48:25 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.8]) by mail.postgresql.org (Postfix) with ESMTP id BC04463259D for ; Wed, 3 Feb 2010 03:48:28 -0400 (AST) Received: from [192.168.1.3] (pool-96-244-14-10.bltmmd.fios.verizon.net [96.244.14.10]) by mrelayeu.kundenserver.de (node=mrbap0) with ESMTP (Nemesis) id 0MNO5B-1NeVv20cIb-007W4A; Wed, 03 Feb 2010 08:48:22 +0100 Message-ID: <4B692A43.1070007@2ndquadrant.com> Date: Wed, 03 Feb 2010 02:48:19 -0500 From: Greg Smith User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Andy Colson CC: Rob , pgsql-performance@postgresql.org Subject: Re: System overload / context switching / oom, 8.3 References: <4B6878DF.3000004@yahoo.com> <4B688F76.9010002@squeakycode.net> In-Reply-To: <4B688F76.9010002@squeakycode.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V01U2FsdGVkX1/f1vF1PVu5slImyONfgFYO25ZATd/AdPci8e0 /1xMxsPJuaveQ4ZiIHko3txIC+8sbGINM8ETIat52YEhOXn8nC tvUaZkWKm9MzRYF6pyusFVglu4OOLqg X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-2.438 tagged_above=-10 required=5 tests=AWL=0.161, BAYES_00=-2.599 X-Spam-Level: X-Archive-Number: 201002/48 X-Sequence-Number: 37469 Andy Colson wrote: > The oom-killer is kicking in, at some point, so somebody is using too > much ram. There should be messages or logs or something, right? > (I've never enabled the oom stuff so dont know much about it). But > the log messages might be helpful. They probably won't be. The information logged about what the OOM killer decided to kill is rarely sufficient to tell anything interesting about the true cause in a PostgreSQL context--only really helpful if you've got some memory hog process it decided to kill. In this case, seems to be a simple situation: way too many connections for the work_mem setting used for a 8GB server to support. I'd take a look at the system using "top -c" as well, in good times and bad if possible, just to see if any weird memory use is showing up somewhere, perhaps even outside the database. -- Greg Smith 2ndQuadrant US Baltimore, MD PostgreSQL Training, Services and Support greg@2ndQuadrant.com www.2ndQuadrant.us