From: Benjamin Minshall <minshall@intellicon.biz>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Alvaro Herrera <alvherre@commandprompt.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: stats collector process high CPU utilization
Date: Fri, 09 Feb 2007 11:27:07 -0500
Message-ID: <45CCA0DB.2010903@intellicon.biz> (raw)
In-Reply-To: <29832.1171036557@sss.pgh.pa.us>
References: <45CB5D06.7090004@intellicon.biz>
<7994.1170960391@sss.pgh.pa.us>
<45CB9330.3000603@intellicon.biz>
<19935.1170969862@sss.pgh.pa.us>
<45CB9C4D.30902@intellicon.biz>
<20601.1170972476@sss.pgh.pa.us>
<45CBA443.9090101@intellicon.biz>
<7959.1170986672@sss.pgh.pa.us>
<62089.75.14.32.120.1170994418.squirrel@intellicon.biz>
<14668.1170995218@sss.pgh.pa.us>
<20070209142459.GB4253@alvh.no-ip.org>
<24717.1171033699@sss.pgh.pa.us>
<29832.1171036557@sss.pgh.pa.us>
Tom Lane wrote:
> I wrote:
>> Alvaro Herrera <alvherre@commandprompt.com> writes:
>>> Regarding temp tables, I'd think that the pgstat entries should be
>>> getting dropped at some point in both releases. Maybe there's a bug
>>> preventing that in 8.2?
>
>> Hmmm ... I did rewrite the backend-side code for that just recently for
>> performance reasons ... could I have broken it?
>
> I did some testing with HEAD and verified that pgstat_vacuum_tabstat()
> still seems to do what it's supposed to, so that theory falls down.
>
> Alvaro, could you send Benjamin your stat-file-dumper tool so we can
> get some more info?
> Alternatively, if Benjamin wants to send me a copy
> of his stats file (off-list), I'd be happy to take a look.
>
> regards, tom lane
When I checked on the server this morning, the huge stats file has
returned to a normal size. I set up a script to track CPU usage and
stats file size, and it appears to have decreased from 90MB down to
about 2MB over roughly 6 hours last night. The CPU usage of the stats
collector also decreased accordingly.
The application logs indicate that there was no variation in the
workload over this time period, however the file size started to
decrease soon after the nightly pg_dump backups completed. Coincidence
perhaps?
Nonetheless, I would appreciate a copy of Alvaro's stat file tool just
to see if anything stands out in the collected stats.
Thanks for your help, Tom.
--
Benjamin Minshall <minshall@intellicon.biz>
Senior Developer -- Intellicon, Inc.
http://www.intellicon.bizAttachments:
smime.p7s (application/x-pkcs7-signature, 5.1K) download
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: minshall@intellicon.biz, tgl@sss.pgh.pa.us, alvherre@commandprompt.com
Subject: Re: stats collector process high CPU utilization
In-Reply-To: <45CCA0DB.2010903@intellicon.biz>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox