Skip site navigation (1) Skip section navigation (2)

Re: Occasional giant spikes in CPU load

From: Craig James <craig_james(at)emolecules(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: Occasional giant spikes in CPU load
Date: 2010-06-25 16:16:57
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
On 6/25/10 7:47 AM, Tom Lane wrote:
> Craig James<craig_james(at)emolecules(dot)com>  writes:
>> On 6/24/10 9:04 PM, Tom Lane wrote:
>>> sinval queue overflow comes to mind ... although that really shouldn't
>>> happen if there's "no real load" on the server.  What PG version is
>>> this?
>> 8.3.10.  Upgraded based on your advice when I first asked this question.
> Any chance of going to 8.4?  If this is what I suspect, you really need
> this 8.4 fix:
> which eliminated the thundering-herd behavior that previous releases
> exhibit when the sinval queue overflows.

Yes, there is a chance of upgrading to 8.4.4.  I just bought a new server and it has 8.4.4 on it, but it won't be online for a while so I can't compare yet.  This may motivate me to upgrade the current servers to 8.4.4 too.  I was pleased to see that 8.4 has a new upgrade-in-place feature that means we don't have to dump/restore.  That really helps a lot.

A question about 8.4.4: I've been having problems with bloat.  I thought I'd adjusted the FSM parameters correctly based on advice I got here, but apparently not.  8.4.4 has removed the configurable FSM parameters completely, which is very cool.  But ... if I upgrade a bloated database using the upgrade-in-place feature, will 8.4.4 recover the bloat and return it to the OS, or do I still have to recover the space manually (like vacuum-full/reindex, or cluster, or copy/drop a table)?

> Or you could look at using connection pooling so you don't have quite
> so many backends ...

I always just assumed that lots of backends that would be harmless if each one was doing very little.  If I understand your explanation, it sounds like that's not entirely true in pre-8.4.4 releases due to the sinval queue problems.


In response to


pgsql-performance by date

Next:From: Tom MolesworthDate: 2010-06-25 16:39:05
Subject: Re: sudden spurt in swap utilization (was:cpu bound postgresql setup.)
Previous:From: Rajesh Kumar MallahDate: 2010-06-25 16:07:03
Subject: Re: Occasional giant spikes in CPU load

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group