From: Tom Lane <tgl@sss.pgh.pa.us>
To: Craig James <craig_james@emolecules.com>
Cc: jd@commandprompt.com
Cc: pgsql-performance@postgresql.org
Subject: Re: Occasional giant spikes in CPU load
Date: Wed, 07 Apr 2010 20:18:51 -0400
Message-ID: <10446.1270685931@sss.pgh.pa.us> (raw)
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>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: tgl@sss.pgh.pa.us, craig_james@emolecules.com, jd@commandprompt.com
Subject: Re: Occasional giant spikes in CPU load
In-Reply-To: <10446.1270685931@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox