On Fri, 20 Nov 2009, Lorenzo Allegrucci wrote:
> performance is degrading...
> In normal conditions the postgres process uses about 3% of cpu time
> but when is in "degraded" conditions it can use up to 25% of cpu time.
You don't really give enough information to determine what is going on
here. This could be one of two situations:
1. You have a constant incoming stream of short-lived requests at a
constant rate, and Postgres is taking eight times as much CPU to service
it as normal. You're looking at CPU usage in aggregate over long periods
of time. In this case, we should look at long running transactions and
other slowdown possibilities.
2. You are running a complex query, and you look at top and see that
Postgres uses eight times as much CPU as when it has been freshly started.
In this case, the "performance degradation" could actually be that the
data is more in cache, and postgres is able to process it eight times
*faster*. Restarting Postgres kills the cache and puts you back at square
Which of these is it?
Reality is that which, when you stop believing in it, doesn't go away.
-- Philip K. Dick
In response to
pgsql-performance by date
|Next:||From: Kevin Grittner||Date: 2009-11-20 15:24:17|
|Subject: Re: Postgres query completion status?|
|Previous:||From: Jonathan Foy||Date: 2009-11-20 15:01:35|
|Subject: Re: View based upon function won't use index on joins|
pgsql-general by date
|Next:||From: Doug Sampson||Date: 2009-11-20 15:51:58|
|Subject: PLPerl - Undefined symbol "MemoryContextSwitchTo"|
|Previous:||From: Tom Lane||Date: 2009-11-20 15:05:55|
|Subject: Re: how to use a cursor for update? |