Scott Marlowe <scott.marlowe@gmail.com> writes:
> On Sat, Apr 2, 2011 at 11:26 AM, Henry C. <henka@cityweb.co.za> wrote:
>> 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).
> Have you tried upping the aggressiveness of autovacuum?
I'm wondering about poor selection of the cost_delay settings in
particular. It's quite easy to slow autovacuum to the point that
it takes forever to do anything.
It's also possible that Henry is getting bit by the bug fixed here:
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [b58c25055] 2010-11-19 22:28:20 -0500
Branch: REL9_0_STABLE Release: REL9_0_2 [b5efc0940] 2010-11-19 22:28:25 -0500
Branch: REL8_4_STABLE Release: REL8_4_6 [fab2af30d] 2010-11-19 22:28:30 -0500
Branch: REL8_3_STABLE Release: REL8_3_13 [6cb9d5113] 2010-11-19 22:28:35 -0500
Fix leakage of cost_limit when multiple autovacuum workers are active.
When using default autovacuum_vac_cost_limit, autovac_balance_cost relied
on VacuumCostLimit to contain the correct global value ... but after the
first time through in a particular worker process, it didn't, because we'd
trashed it in previous iterations. Depending on the state of other autovac
workers, this could result in a steady reduction of the effective
cost_limit setting as a particular worker processed more and more tables,
causing it to go slower and slower. Spotted by Simon Poole (bug #5759).
Fix by saving and restoring the GUC variables in the loop in do_autovacuum.
regards, tom lane
