Re: Autovacuum behavior - Mailing list pgsql-admin

From John Scalia
Subject Re: Autovacuum behavior
Date
Msg-id CABzCKRAVcKieKfWtnXJ0gDisDzWVYV0+cCb_adzZooAO3_2DoA@mail.gmail.com
Whole thread Raw
In response to Re: Autovacuum behavior  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: Autovacuum behavior  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-admin
autovacuum_vacuum_cost_limit is currently set at -1. Not really sure what it should be, as I still need to look that up.

On Thu, Jul 30, 2015 at 1:59 PM, Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
John Scalia wrote:
> Hi all,
>
> The autovacuum settings for a 9.4.2 database are shown below, I'm not
> absolutely certain if I missed anything:
>
> autovacuum = on
> log_autovacuum_min_duration = 100
> autovacuum_max_workers = 15
> autovacuum_naptime = 10min
> #autovacuum_vacuum_threshold = 50
> autovacuum_analyze_threshold = 80
> autovacuum_vacuum_scale_factor = 0.1
> autovacuum_analyze_scale_factor = 0.2
> autovacuum_freeze_max_age = 100000000
> autovacuum_vacuum_cost_delay = 20ms
> autovacuum_vacuum_cost_limit = -1

What's the vacuum_cost_limit setting?  Maybe they are sleeping for too
long, and don't have time to get to some of the other tables because all
15 workers are busy.  This gets worse the more workers there are.

I don't think the 10min naptime is doing you any favors, is it?

If you want them to go faster, maybe you need to lower the cost_delay.

--
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

pgsql-admin by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Autovacuum behavior
Next
From: Merlin Moncure
Date:
Subject: Re: [GENERAL] How Many PG_Locks are considered too many