I have the problem that on our servers it happens regularly under a
certain workload (several times per minute) that all backend processes
get a SIGUSR1 and spend several seconds in ProcessCatchupEvent(). At
100-200 connections (most of them idle) this causes the system load to
skyrocket. I am not really familiar with the code but my wild guess is
that the processes spend most of their time waiting for spinlocks.
We have reduced the number of connections as much as possible for now
but it still makes up for roughly 50% of the total CPU time. Has
anyone experienced a similar problem?
I can reproduce the issue on a test system with production data but it
is not so easy to pinpoint what exactly causes the problem. The queries
are basically tsearch2 full text searches over moderately big tables
(~35GB). The queries are performed by functions which aggregate data
from partitions in temporary tables, cache some data, and perform
calculations before returning it to the user.
The PostgreSQL version is 8.3.12, the test server has 8 amd64 cores
and 16GB of ram. I experimented with shared_buffers between 1GB and
4GB but it doesn't make much of a difference. Disk IO doesn't seem to
be an issue here.
Julian v. Bock
Julian v. Bock Projektleitung Software-Entwicklung
OpenIT GmbH Tel +49 211 239 577-0
In der Steele 33a-41 Fax +49 211 239 577-10
D-40599 Düsseldorf http://www.openit.de
HRB 38815 Amtsgericht Düsseldorf USt-Id DE 812951861
Geschäftsführer: Oliver Haakert, Maurice Kemmann
pgsql-performance by date
|Next:||From: Tom Lane||Date: 2010-12-29 15:18:41|
|Subject: Re: long wait times in ProcessCatchupEvent() |
|Previous:||From: Greg Smith||Date: 2010-12-29 02:20:02|
|Subject: Re: Regression: 8.3 2 seconds -> 8.4 100+ seconds|