Re: Manual vacs 5x faster than autovacs?

On Thu, Nov 12, 2009 at 9:58 AM, Wayne Beaver <wayne(at)acedsl(dot)com> wrote:
>> Quoting Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>:
>>
>>>> On Thu, Nov 12, 2009 at 9:14 AM, Wayne Beaver <wayne(at)acedsl(dot)com> wrote:
>>>> I'd seen autovacs running for hours and had mis-attributed this to
>>>> growing
>>>> query times on those tables  - my thought was that "shrinking" the
>>>> tables
>>>> "more quickly" could make them "more-optimized", more often. Sounds like
>>>> I
>>>> could be chasing the wrong symptoms, though.
>>>
>>> Now it is quite possible that a slow autovac is causing your queries
>>> to run slower.  So, if it has a moderate to high cost delay, then it
>>> might not be able to keep
>>> up with the job and your tables will become bloated.
>>>
>>> The problem isn't that autovac is stealing too many resources, it's
>>> that it's not stealing enough.
>>>
>>> I see you're technically running 8.3, but you're running RC2
>>> for some reason?  I don't usually run 8.x.0 in production.  Let alone
>>> RCs.  You should really update before some nasty bug that's been
>>> squashed in later releases bites you.
>
>
> Hahaha. Yes, 8.3RC2 was latest version at time I implemented related client
> app. Install is "production-like", more so than production -
> non-mission-critical,  but important to some "VIP-like" users at intervals
> which are not necessarily predictable. I'm long past my goal of migrating to
> 8.4, actually...

Worry far more about being out of date on 8.3. Since you're on an rc
release you'll likely need to dump and restore to safely migrate to
8.3.latest, but once there, simply shutting down, updating and
starting up is all that's usually required.

>
> My autovac settings are all at default values, so sounds like I can at least
> tinker with _workers and _cost_delay. I've not yet gotten to you iostat
> inquiry from your previous response...

Don't worry too much, just want to see if your IO system is maxed out.