Skip site navigation (1) Skip section navigation (2)

Re: Large pgstat.stat file causes I/O storm

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Cristian Gafton <gafton(at)rpath(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Large pgstat.stat file causes I/O storm
Date: 2008-01-29 18:40:02
Message-ID: 23701.1201632002@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Cristian Gafton <gafton(at)rpath(dot)com> writes:
> On Tue, 29 Jan 2008, Cristian Gafton wrote:
>> I have a ~150GB sized server, containing two databases that are active in 
>> mostly read mode. I have noticed lately that the global/pgstat.stat file is 
>> somewhere around 1MB freshly after a restart, but at some point it baloons to 
>> 74MB in size for no apparent reason, after a few hours of uptime. Needless to 
>> say, having the stats collector dump 74MB of stuff on disk on its every loop 
>> takes a big bite of the I/O capabilities of this box.

> Of course, leaving out the most important thing - this is postgresql 8.2.6 
> on x86_64

Hmm ... do you have autovacuum enabled?  If not, what's the vacuuming
policy on that box?  I'm wondering if this is triggered by something
deciding to vacuum or analyze a bunch of otherwise-unused tables, and
thereby causing stats entries to be created for those tables.

You could investigate by comparing the contents of the stats views
before and after the file balloons.  I would expect to see a lot more
rows, and the key is exactly what non-null activity is recorded in
the extra rows.

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Cristian GaftonDate: 2008-01-29 19:06:12
Subject: Re: Large pgstat.stat file causes I/O storm
Previous:From: Jeff DavisDate: 2008-01-29 17:48:15
Subject: Re: [PATCHES] Proposed patch: synchronized_scanningGUCvariable

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group