On Fri, Apr 16, 2010 at 12:48 PM, Tom Lane <tgl@xxxxxxxxxxxxx> wrote:
> Josh Kupershmidt <schmiddy@xxxxxxxxx> writes:
>> Hrm, well autovacuum is at least trying to do work: it's currently
>> stuck on those bloated pg_catalog tables, of course. Another developer
>> killed an autovacuum of pg_attribute (or maybe it was pg_attrdef)
>> after it had been running for two weeks. See current pg_stat_activity
>> output attached, which shows the three autovacuum workers running plus
>> two manual VACUUM ANALYZEs I started yesterday.
>
> Two weeks? What have you got the autovacuum cost delays set to?
SELECT name, current_setting(name), source FROM pg_settings WHERE
source != 'default' AND name ILIKE '%vacuum%';
name | current_setting | source
----------------------+-----------------+--------------------
vacuum_cost_delay | 200ms | configuration file
vacuum_cost_limit | 100 | configuration file
vacuum_cost_page_hit | 6 | configuration file
(3 rows)
I'm guessing these values and the default autovacuum configuration
values need to be cranked significantly to make vacuum much more
aggressive :-(
> Once you're up to three AV workers, no new ones can get launched until
> one of those finishes or is killed. So that would explain failure to
> prune the stats collector's tables (the tabpurge code is only run during
> AV worker launch). So what we need to figure out is why it's taking so
> obscenely long to vacuum these tables ...
>
Hopefully changing those three vacuum_cost_* params will speed up the
manual- and auto-vacuums.. it'll take me a few days to see any
results, since I still need to do something about the bloat that's
already there.
Josh
--
Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
