Received: from maia.hub.org (maia-2.hub.org [200.46.204.251]) by mail.postgresql.org (Postfix) with ESMTP id B06EC632605 for ; Fri, 25 Jun 2010 14:01:41 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.251]) (amavisd-maia, port 10024) with ESMTP id 38136-01 for ; Fri, 25 Jun 2010 17:01:33 +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 4752C632304 for ; Fri, 25 Jun 2010 14:01:33 -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 o5PH1Vci006204; Fri, 25 Jun 2010 13:01:31 -0400 (EDT) To: Craig James cc: pgsql-performance@postgresql.org Subject: Re: Occasional giant spikes in CPU load In-reply-to: <4C24D679.7030701@emolecules.com> References: <4BBCFB12.1010306@emolecules.com> <4BBD3A17.90209@emolecules.com> <4C23FD52.40508@emolecules.com> <23596.1277438692@sss.pgh.pa.us> <4C24B3BB.3070901@emolecules.com> <2286.1277477230@sss.pgh.pa.us> <4C24D679.7030701@emolecules.com> Comments: In-reply-to Craig James message dated "Fri, 25 Jun 2010 09:16:57 -0700" Date: Fri, 25 Jun 2010 13:01:31 -0400 Message-ID: <6203.1277485291@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.91 tagged_above=-10 required=5 tests=BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 X-Spam-Level: X-Archive-Number: 201006/474 X-Sequence-Number: 39330 Craig James writes: > On 6/25/10 7:47 AM, Tom Lane wrote: >> Any chance of going to 8.4? If this is what I suspect, you really need >> this 8.4 fix: >> http://archives.postgresql.org/pgsql-committers/2008-06/msg00227.php >> 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. I wouldn't put a lot of faith in pg_migrator for an 8.3 to 8.4 conversion ... it might work, but test it on a copy of your DB first. Possibly it'll actually be recommendable in 9.0. > 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)? No, an in-place upgrade to 8.4 isn't magically going to fix that. This might actually be sufficient reason to stick with the tried&true dump and reload method, since you're going to have to do something fairly expensive anyway to clean out the bloat. regards, tom lane