Re: stats collector suddenly causing lots of IO

On Fri, Apr 16, 2010 at 2:14 PM, Greg Smith <greg(at)2ndquadrant(dot)com> wrote:
> Josh Kupershmidt wrote:
>>
>> 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
>>
>>  Hopefully changing those three vacuum_cost_* params will speed up the
>> manual- and auto-vacuums..
>
> Those only impact manual VACUUM statements.  There's a different set with
> names like autovacuum_vacuum_cost_delay that control the daemon.  You can
> set those to "-1" in order to match the regular VACUUM, but that's not the
> default.

It looks like the default which I have of autovacuum_vacuum_cost_limit
= -1, which means it's inheriting the vacuum_cost_limit of 100 I had
set. I'll try bumping vacuum_cost_limit up to 1000 or so.

> You really need to sort out the max_fsm_pages setting too, because until
> that issue goes away these tables are unlikely to ever stop growing.  And,
> no, you can't use CLUSTER on the system tables to clean those up.

I have max_fsm_pages = 524288 , but from the hints in the logfiles
this obviously needs to go up much higher. And it seems the only way
to compact the pg_catalog tables is VACUUM FULL + REINDEX on 8.3 -- I
had tried the CLUSTER on my 9.0 machine and wrongly assumed it would
work on 8.3, too.

Josh