Received: from maia.hub.org (unknown [200.46.204.183])
	by mail.postgresql.org (Postfix) with ESMTP id 140B863279A
	for <pgsql-performance-postgresql.org@mail.postgresql.org>;
	Wed,  7 Apr 2010 21:19:07 -0300 (ADT)
Received: from mail.postgresql.org ([200.46.204.86])
	by maia.hub.org (mx1.hub.org [200.46.204.183]) (amavisd-maia,
	port 10024) with ESMTP id 63416-06
	for <pgsql-performance-postgresql.org@mail.postgresql.org>;
	Thu,  8 Apr 2010 00:18:56 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130])
	by mail.postgresql.org (Postfix) with ESMTP id 96E41632315
	for <pgsql-performance@postgresql.org>;
	Wed,  7 Apr 2010 21:18:56 -0300 (ADT)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
	by sss.pgh.pa.us (8.14.2/8.14.2) with ESMTP id o380Iptr010447;
	Wed, 7 Apr 2010 20:18:51 -0400 (EDT)
To: Craig James <craig_james@emolecules.com>
cc: jd@commandprompt.com, pgsql-performance@postgresql.org
Subject: Re: Occasional giant spikes in CPU load 
In-reply-to: <4BBD0DD5.3050807@emolecules.com> 
References: <k2pda0294261004061437p9cd3810dqe9ce528b6ddb0873@mail.gmail.com>
	<m2m603c8f071004071413w1f2d2497hbbe07d9c6491848f@mail.gmail.com>
	<4BBCFB12.1010306@emolecules.com>
	<1270676410.19131.21.camel@jd-desktop.unknown.charter.com>
	<4BBCFCDE.5020405@emolecules.com>
	<1270679808.19131.28.camel@jd-desktop.unknown.charter.com>
	<4BBD0DD5.3050807@emolecules.com>
Comments: In-reply-to Craig James <craig_james@emolecules.com>
	message dated "Wed, 07 Apr 2010 15:57:25 -0700"
Date: Wed, 07 Apr 2010 20:18:51 -0400
Message-ID: <10446.1270685931@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Spam-Status: No, hits=-0.185 tagged_above=-10 required=5
	tests=BAYES_40=-0.185
X-Spam-Level: 
X-Archive-Number: 201004/83
X-Sequence-Number: 38333

Craig James <craig_james@emolecules.com> writes:
> On 4/7/10 3:36 PM, Joshua D. Drake wrote:
>> To have your CPUs so flooded that they are the cause of an inability to
>> log in is pretty suspect.

> I thought so too, except that I can't login during the flood.  If the CPUs were all doing iowaits, logging in should be easy.

> Greg's suggestion that shared_buffers and work_mem are too big for an 8 GB system fits these symptoms -- if it's having a swap storm, login is effectively impossible.

Yeah, but there is also the question of what's causing all the backends
to try to run at the same time.  Oversubscribed memory could well be the
direct cause of the machine getting driven into the ground, but there's
something else going on here too IMO.

Anyway I concur with the advice to lower shared_buffers, and run fewer
backends if possible, to see if that ameliorates the problem.

			regards, tom lane