Re: Problem with 8.4 stats collector high load - Mailing list pgsql-hackers

From Greg Smith
Subject Re: Problem with 8.4 stats collector high load
Date
Msg-id 4B7A4950.20602@2ndquadrant.com
Whole thread Raw
In response to Problem with 8.4 stats collector high load  (Jakub Ouhrabka <kuba@comgate.cz>)
Responses Re: Problem with 8.4 stats collector high load
List pgsql-hackers
Jakub Ouhrabka wrote:
> I've found similar reports but with older versions of postgres:
> http://old.nabble.com/100--of-CPU-utilization-postgres-process-tt27302021.html 
>

Those all looked like a FreeBSD issue, doubt it's related to yours.

> The pgstat.stat is ~20MB. There are 650 databases, 140GB total.
> default_statistics_target = 1000
> The system is running Proxmox linux distribution. PostgreSQL is in 
> OpenVZ container.

With this many databases and this high of a statistics target, running 
in a VM, suspecting autovacuum seems reasonable.  You might want to try 
setting log_autovacuum_min_duration=0 in the postgresql.conf, restarting 
or signalling (pg_ctl reload) the server, and watching just what it's 
doing.  You might need to reduce how aggressively that runs, or limit 
the higher target to only the tables that need it, to get this under 
control.  You're really pushing what you can do in a VM with this many 
databases of this size.

-- 
Greg Smith  2ndQuadrant US  Baltimore, MD
PostgreSQL Training, Services and Support
greg@2ndQuadrant.com   www.2ndQuadrant.us



pgsql-hackers by date:

Previous
From: Jakub Ouhrabka
Date:
Subject: Problem with 8.4 stats collector high load
Next
From: Greg Smith
Date:
Subject: Re: psycopg2 license changed