Re: Problem with 8.4 stats collector high load

From: Greg Smith <greg(at)2ndquadrant(dot)com>
To: Jakub Ouhrabka <kuba(at)comgate(dot)cz>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Problem with 8.4 stats collector high load
Date: 2010-02-16 07:29:20
Message-ID: 4B7A4950.20602@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)2ndQuadrant(dot)com www.2ndQuadrant.us

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Smith 2010-02-16 07:41:40 Re: psycopg2 license changed
Previous Message Jakub Ouhrabka 2010-02-16 07:15:33 Problem with 8.4 stats collector high load