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

Postgres processes have a burst of CPU usage

From: Subramaniam Aiylam <aiylam_s(at)yahoo(dot)com>
To: pgsql-performance(at)postgresql(dot)org
Subject: Postgres processes have a burst of CPU usage
Date: 2007-01-23 16:11:11
Message-ID: 519784.22637.qm@web60714.mail.yahoo.com (view raw or flat)
Thread:
Lists: pgsql-performance
Hello all,

  I have a setup in which four client machines access
a Postgres database (8.1.1) (on a Linux box). So,
there are connections from each machine to the
database; hence, the Linux box has about 2 postgres
processes associated with each machine.

  I am using the JDBC driver
(postgresql-8.1-404.jdbc3.jar) to talk to the
database. I am also using the Spring framework(1.2.2)
and Hibernate (3.0.5) on top of JDBC. I use Apache's
DBCP database connection pool (1.2.1).

  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.

  Is it that this operation is forcibly clearing some
client cache on ALL the postgres processes? Why is
there such an interdependency? Can I set some
parameter to turn this off?

Regards and thanks,
S.Aiylam




 
____________________________________________________________________________________
Do you Yahoo!?
Everyone is raving about the all-new Yahoo! Mail beta.
http://new.mail.yahoo.com

Responses

pgsql-performance by date

Next:From: Bruno Wolff IIIDate: 2007-01-23 17:59:51
Subject: Re: slow result
Previous:From: Merlin MoncureDate: 2007-01-23 16:05:51
Subject: Re: extract(field from timestamp) vs date dimension

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