Re: stats collector suddenly causing lots of IO

Поиск
Список
Период
Сортировка
От Josh Kupershmidt
Тема Re: stats collector suddenly causing lots of IO
Дата
Msg-id q2o4ec1cf761004161240ia4a46e65gab65b33d8b9126a0@mail.gmail.com
обсуждение исходный текст
Ответ на Re: stats collector suddenly causing lots of IO  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-performance
On Fri, Apr 16, 2010 at 3:22 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Josh Kupershmidt <schmiddy@gmail.com> writes:
>>         name         | current_setting |       source
>> ----------------------+-----------------+--------------------
>>  vacuum_cost_delay    | 200ms           | configuration file
>>  vacuum_cost_limit    | 100             | configuration file
>>  vacuum_cost_page_hit | 6               | configuration file
>>
>> It looks like the default which I have of autovacuum_vacuum_cost_limit
>> = -1, which means it's inheriting the vacuum_cost_limit of 100 I had
>> set. I'll try bumping vacuum_cost_limit up to 1000 or so.
>
> Actually I think the main problem is that cost_delay value, which is
> probably an order of magnitude too high.  The way to limit vacuum's
> I/O impact on other stuff is to make it take frequent short delays,
> not have it run full speed and then sleep a long time.  In any case,
> your current settings have got it sleeping way too much.  Two WEEKS !!!??

Yup, I was going to turn vacuum_cost_delay down to 20. The two weeks
was for the pg_catalog table which has bloated to 145 GB, I think. One
of those manual VACUUMs I kicked off just finished, after 48 hours --
and that table was only 25 GB or so. I wasn't the one who set up this
postgresql.conf, but I am stuck fixing things :/

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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: stats collector suddenly causing lots of IO
Следующее
От: Віталій Тимчишин
Дата:
Сообщение: Re: Planner not using column limit specified for one column for another column equal to first