Re: Autovacuum firing up during my manual vacuum on same table
От | Henry C. |
---|---|
Тема | Re: Autovacuum firing up during my manual vacuum on same table |
Дата | |
Msg-id | 340f1ad04ec1e0048de6bd5e057cc616.squirrel@zenmail.co.za обсуждение исходный текст |
Ответ на | Re: Autovacuum firing up during my manual vacuum on same table (Scott Marlowe <scott.marlowe@gmail.com>) |
Список | pgsql-general |
On Sat, April 2, 2011 21:26, Scott Marlowe wrote: > On Sat, Apr 2, 2011 at 11:26 AM, Henry C. <henka@cityweb.co.za> wrote: > >> On Sat, April 2, 2011 14:17, Jens Wilke wrote: >> >>> Nevertheless since at least 8.4 IMO there's no need to bother with >>> manual vacuum any more. >> >> Sadly, in my case, the db is so busy that autovac processes run for weeks >> and never catch up (insufficient h/w for the app quite frankly - the >> addition of some more SSD drives have already helped). I eventually run up >> against the wraparound wall and the only way forward is to stop everything >> and dump/restore (vacuuming the entire db would take an unknown period of N >> x weeks - dumping/restoring completes in a day or two). > > Have you tried upping the aggressiveness of autovacuum? Thanks for the suggestion - I'm going to give autovacuum_vacuum_cost_delay=0 a try (instead of the default 20ms, which if I'm reading the docs correctly, means the same aggressiveness as a manual vacuum), and see how things go in terms of the I/O cost/responsiveness and ensuring the damn vacuums finish in a reasonable time before the wraparound tactical nuke hits :)
В списке pgsql-general по дате отправления: