Received: from localhost (maia-3.hub.org [200.46.204.184]) by postgresql.org (Postfix) with ESMTP id 6B3419FB5C8 for ; Wed, 24 Jan 2007 04:49:39 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.184]) (amavisd-new, port 10024) with ESMTP id 58527-02 for ; Wed, 24 Jan 2007 04:49:32 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey-1.7.4 Received: from mail.metronet.co.uk (mail.metronet.co.uk [213.162.97.75]) by postgresql.org (Postfix) with ESMTP id 592FC9FB588 for ; Wed, 24 Jan 2007 04:49:35 -0400 (AST) Received: from server3.office.archonet.com (84-51-143-99.archon037.adsl.metronet.co.uk [84.51.143.99]) by smtp.metronet.co.uk (MetroNet Mail) with ESMTP id 4C9CB73B4B; Wed, 24 Jan 2007 08:49:29 +0000 (GMT) Received: from [192.168.1.36] (dell36.office.archonet.com [192.168.1.36]) by server3.office.archonet.com (Postfix) with ESMTP id E57C32742E2; Wed, 24 Jan 2007 08:49:28 +0000 (GMT) Message-ID: <45B71D98.5080805@archonet.com> Date: Wed, 24 Jan 2007 08:49:28 +0000 From: Richard Huxton User-Agent: IceDove 1.5.0.9 (X11/20061220) MIME-Version: 1.0 To: Subramaniam Aiylam Cc: pgsql-performance@postgresql.org Subject: Re: Postgres processes have a burst of CPU usage References: <519784.22637.qm@web60714.mail.yahoo.com> In-Reply-To: <519784.22637.qm@web60714.mail.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200701/361 X-Sequence-Number: 22962 Subramaniam Aiylam wrote: > Now, there is one particular update that I make from > one of the client machines - this involves a > reasonably large object graph (from the Java point of > view). It deletes a bunch of rows (around 20 rows in > all) in 4-5 tables and inserts another bunch into the > same tables. > > When I do this, I see a big spike in the CPU usage > of postgres processes that are associated with ALL the > client machines, not just the one I executed the > delete/insert operation on. The spike seems to happen > a second or two AFTER the original update completes > and last for a few seconds. So what are the other backends doing? They're not going to be using CPU cycles for nothing, they must be executing queries. Perhaps turn on statement logging, and track process IDs. I can't think of any PostgreSQL caching that would be seriously affected by updating a few dozen rows. It might be that one of your java libraries is clearing its cache though, causing it to issue more queries. -- Richard Huxton Archonet Ltd