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 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Cristian Gafton | 2008-01-29 19:06:12 | Re: Large pgstat.stat file causes I/O storm |
Previous Message | Jeff Davis | 2008-01-29 17:48:15 | Re: [PATCHES] Proposed patch: synchronized_scanning GUCvariable |