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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Large pgstat.stat file causes I/O storm
Дата
Msg-id 23701.1201632002@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Large pgstat.stat file causes I/O storm  (Cristian Gafton <gafton@rpath.com>)
Ответы Re: Large pgstat.stat file causes I/O storm  (Cristian Gafton <gafton@rpath.com>)
Список pgsql-hackers
Cristian Gafton <gafton@rpath.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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Jeff Davis
Дата:
Сообщение: Re: [PATCHES] Proposed patch: synchronized_scanning GUCvariable
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [PATCHES] Proposed patch: synchronized_scanning GUCvariable