Re: Vacuum verbose output? - Mailing list pgsql-general

From Robert Treat
Subject Re: Vacuum verbose output?
Date
Msg-id 1042559669.24625.64.camel@camel
Whole thread Raw
In response to Vacuum verbose output?  ("Julian Scarfe" <julian.scarfe@ntlworld.com>)
Responses Re: Vacuum verbose output?
Re: Vacuum verbose output?
Re: Vacuum verbose output?
List pgsql-general
On Tue, 2003-01-14 at 04:46, Julian Scarfe wrote:
> Is there any documentation on the output of VACUUM VERBOSE please?

AFAIK your best bet is to search the mailing archives or look through
the source :-(

>
> NOTICE:  Pages 371: Changed 3, reaped 364, Empty 0, New 0; Tup 8180: Vac
> 1786, Keep/VTL 0/0, UnUsed 6285, MinLen 115, MaxLen 648; Re-using:
> Free/Avail. Space 622460/621672; EndEmpty/Avail. Pages 0/350.
>
> in a little detail.
>

All from memory, probably wrong on a couple, so take this with a grain
of salt.

Pages = the number of files on the system involved in this table.
Changed = the number of pages that had to be modified. Reaped mean the
number of pages that were made compleltely blank, ready for reuse. Empty
= pages that are currently empty, ready for reuse. New = pages that had
to be created as a result of vacuuming?


> The application is a database where the data in the tables are essentially
> write-once-read-many, and a tuple stays active for about 3 hours before
> being deleted/archived.  With a regular, simple VACUUM, the number of Pages
> increases steadily until a VACUUM FULL is performed.  But a write-lock on
> the tables is a real pain, as the entire population mechanism has to be
> suspended, and it backs up very quickly.
>

Sounds like you need to run vacuum at least every 3 hours.

 > In order to understand the space and performance implications of how often
> we do a VACUUM FULL rather than simple VACUUM, I'd like to understand the
> output.
>
> Example (just successive VACUUM output, longer entries are VACUUM FULL):
<snip output>

ISTM that at times your vacuuming regularly and actually recovering
space, but then there are times when your space grows rather quickly.
This is either an indication that you need to time your vacuums better
(to coincide with large batch inserts or deletes) or you need to vacuum
more often, to recover more space between batches.

I should also say that it might also be an indication that your free
space map settings aren't set appropriately, make sure max_fsm_relation
and max_fsm_pages are set high enough. Without looking at your complete
database there's no way to know for sure. (Although max_fsm_relations is
almost assuredly to low).

>
> It grows steadily until a VACUUM FULL is performed, when it shrinks back.
> If we never do a VACUUM FULL, will it just keep on growing, and does
> performance suffer as it does so?
>

The thing with vacuum is at some point you should reach a condition
where space on the disk increases only when the total number of inserts
is greater than the total number of deletions over a given time frame.
If it increases when inserts is less than deletes, your not vacuuming
enough. If you can reach this level of "symbiosis" with regular vacuums,
you should never have to do vacuum full.

Robert Treat



pgsql-general by date:

Previous
From: Tom Lane
Date:
Subject: Re: pg_dump fail beacuse of oid larger than int32
Next
From: Julian Scarfe
Date:
Subject: Re: Vacuum verbose output?