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 по дате отправления: