Re: More Autovacuum Questions - Mailing list pgsql-admin

From Jim C. Nasby
Subject Re: More Autovacuum Questions
Date
Msg-id 20060516184053.GL26212@pervasive.com
Whole thread Raw
In response to More Autovacuum Questions  ("Chris Hoover" <revoohc@gmail.com>)
List pgsql-admin
On Tue, May 16, 2006 at 02:00:21PM -0400, Chris Hoover wrote:
> Thanks to those who answered my first question.  I am looking at
> implementing autovacuuming on our new production 8.1.3 systems.  I am
> reading the documentation on the various configuration parameters.  The
> autovacuum_analyze_threshold and autovacuum_vacuum_threshold talk about the
> number of updated and deleted tuples.  Is there anyway to calculate these
> numbers in a running database?
>
> The reason I'm asking is that we are having some sporadic slowness issues
> with our databases, and I'm wanting to see how the database looks during
> these times.  I know that vacuuming some specific tables tends to fix the
> problem.  So, if I can see what autovacuum might see, I could set the
> parameters correctly to try and fix the issue.

Your best bet is to turn up your logging verbosity, so that you actually
get more detailed info from autovacuum. Short of that, you can monitor
those tables in pg_stat_user_tables; in particular you need to watch
n_tup_upd and n_tup_del.

As for the autovacuum settings, I've found that the default threasholds
and scale factors are too big by at least a factor of 2. By default, it
will allow a relation to grow to 40% dead rows before vacuuming, which
is a pretty decent amount of waisted space.

Finally, there are certain tables that aren't well suited to autovacuum,
namely any tables that see a very high rate of updates or deletes. For
these tables I usually schedule vacuums via crontab. For tables that
should be kept small (ie: queue tables), I'll even go as far as
vacuuming once a minute, or more often, since these tables should stay
small enough for vacuum to be very fast.
--
Jim C. Nasby, Sr. Engineering Consultant      jnasby@pervasive.com
Pervasive Software      http://pervasive.com    work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf       cell: 512-569-9461

pgsql-admin by date:

Previous
From: "Jim C. Nasby"
Date:
Subject: Re: How can i hide the unnecessary schemas from developers
Next
From: Tom Lane
Date:
Subject: Re: does wal archiving block the current client connection?