Received: from maia.hub.org (maia-3.hub.org [200.46.204.243]) by mail.postgresql.org (Postfix) with ESMTP id DB391632C0A for ; Fri, 25 Jun 2010 14:07:52 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.243]) (amavisd-maia, port 10024) with ESMTP id 20256-05 for ; Fri, 25 Jun 2010 17:07:44 +0000 (UTC) X-Greylist: delayed 00:06:16.130793 by SQLgrey-1.7.6 Received: from mail-fx0-f46.google.com (mail-fx0-f46.google.com [209.85.161.46]) by mail.postgresql.org (Postfix) with ESMTP id D8DC1632B61 for ; Fri, 25 Jun 2010 14:07:44 -0300 (ADT) Received: by fxm3 with SMTP id 3so108361fxm.19 for ; Fri, 25 Jun 2010 10:07:43 -0700 (PDT) Received: by 10.223.132.210 with SMTP id c18mr826432fat.48.1277485285606; Fri, 25 Jun 2010 10:01:25 -0700 (PDT) Received: from Craig-Jamess-MacBook-Pro.local (wsip-70-167-124-126.sd.sd.cox.net [70.167.124.126]) by mx.google.com with ESMTPS id x3sm9900830fag.35.2010.06.25.10.01.23 (version=SSLv3 cipher=RC4-MD5); Fri, 25 Jun 2010 10:01:24 -0700 (PDT) Message-ID: <4C24E0E1.7020301@emolecules.com> Date: Fri, 25 Jun 2010 10:01:21 -0700 From: Craig James User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: Kevin Grittner CC: Tom Lane , pgsql-performance@postgresql.org Subject: Re: Occasional giant spikes in CPU load 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> <4C2495D70200002500032B16@gw.wicourts.gov> In-Reply-To: <4C2495D70200002500032B16@gw.wicourts.gov> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-0.001 tagged_above=-10 required=5 tests=BAYES_20=-0.001 X-Spam-Level: X-Archive-Number: 201006/476 X-Sequence-Number: 39332 On 6/25/10 9:41 AM, Kevin Grittner wrote: > Craig James wrote: > >> I always just assumed that lots of backends that would be harmless >> if each one was doing very little. > > Even if each is doing very little, if a large number of them happen > to make a request at the same time, you can have problems. This is > exactly where a connection pool can massively improve both > throughput and response time. If you can arrange it, you want a > connection pool which will put a limit on active database > transactions and queue requests to start a new transaction until one > of the pending ones finishes. No, that's doesn't seem to be the case. There is no external activity that triggers this huge spike in usage. It even happens to our backup server when only one of us is using it to do a single query. This problem seems to be triggered by Postgres itself, not by anything external. Per Tom's suggestion, I think upgrading to 8.4.4 is the answer. I'll learn more when our new hardware comes into use with a shiny new 8.4.4 installation. Craig