A65: Automatic vacuum of table completed
SQLSTATE: n/a
Urgency: low
Example Postgres Log Output:
LOG: automatic vacuum of table "mydb.public.vac_test": index scans: 1
pages: 0 removed, 1 remain, 0 skipped due to pins, 0 skipped frozen
tuples: 3 removed, 6 remain, 0 are dead but not yet removable
buffer usage: 70 hits, 4 misses, 4 dirtied
avg read rate: 62.877 MB/s, avg write rate: 62.877 MB/s
system usage: CPU 0.00s/0.00u sec elapsed 0.00 sec
Explanation:
This log event describes in detail the statistics of a completed autovacuum
on a table in the database. Note that this will only be logged when
log_autovacuum_min_duration
is enabled on your database.
On most systems it is safe to simply turn on autovacuum logs for all durations,
which you can do by setting log_autovacuum_min_duration = 0
.
Monitoring the log data for these events has benefits compared to other approaches
(e.g. sampling pg_stat_progress_vacuum
/ pg_stat_acivity
) since even very
fast autovacuum runs will show up in the logs. The downside of course is that
you might see a lot of log events, so these are hard to parse through without
additional visualization.
One of the useful statistics in this log event, is that you can determine easily
how much I/O impact the autovacuum run had, based on the avg read rate
and
avg write rate
. This can be influenced by setting autovacuum_vacuum_cost_delay
on the table, or for the database.
Recommended Action:
This log event on its own does not indicate anything bad, after all VACUUM is an integral part of Postgres.
You might want to read up on autovacuum tuning if you encounter certain tables being vacuumed a lot, or vacuum runs taking a lot of time.
Learn More:
Couldn't find what you were looking for or want to talk about something specific?
Start a conversation with us →