pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  
help / color / mirror / Atom feed
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.biz

Attachments:

  smime.p7s (application/x-pkcs7-signature, 5.1K) download

view thread (27+ messages)  latest in thread

Message-ID: <45CCA0DB.2010903@intellicon.biz>
Permalink:  ../45CCA0DB.2010903@intellicon.biz/
Also on:    postgresql.org/message-id/45CCA0DB.2010903@intellicon.biz

 · 

reply

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