Re: why is autovacuum still ongoing even if set to off ? - Mailing list pgsql-general

From Scott Marlowe
Subject Re: why is autovacuum still ongoing even if set to off ?
Date
Msg-id dcc563d10907302345j46bd5269j29ae7c0892294cbf@mail.gmail.com
Whole thread Raw
In response to Re: why is autovacuum still ongoing even if set to off ?  (Costin Grigoras <costing@gmail.com>)
Responses Re: why is autovacuum still ongoing even if set to off ?
List pgsql-general
On Fri, Jul 31, 2009 at 12:24 AM, Costin Grigoras<costing@gmail.com> wrote:

> => show autovacuum;
> autovacuum
> ------------
> off
>
> I really overdid it, I know, but this issue is very annoying. Even with
> these settings it's still ongoing.
>
> The IO doesn't seem to be an issue, the DB sits on a RAID6 of 8 10K rpm
> disks while the logs are on another identical controller, 512M cache on
> each. 32G of RAM with 30 being only cache also help. fsync is off and below
> is the output of iostat. But something is indeed weird, if autovacuum
> doesn't consume CPU and doesn't do much IO then where does it spend the time

sleeping so as not to get in the way.

> Btw, I've tried "vacuum full analyze" on the same table that autovacuum
> reports vacuumed in 542 seconds and it only took 36 seconds on the command
> line (when the files were not in cache, 7 seconds when they were)! And I see
> the vacuum process using a lot of cpu in "top" while the autovacuum process
> is always at 2-3% only. This raises another question, why is autovacuum
> taking so long to do much less?!

What's the difference between autovacuum_vacuum_cost_delay and
vacuum_cost_delay ?

Since autovacuum seems to not be causing any actual problems, why are
you so invested in turning it off instead of making sure it's tuned to
not get in the way?

pgsql-general by date:

Previous
From: Scott Marlowe
Date:
Subject: Re: why is autovacuum still ongoing even if set to off ?
Next
From: Jennifer Trey
Date:
Subject: Re: pg_config --sharedir points to the wrong folder.. is this a problem?