Обсуждение: auto vacuum doens't appear to be working

Поиск
Список
Период
Сортировка

auto vacuum doens't appear to be working

От
Warren Little
Дата:
We have a bytea column where we store large attachments (ie pdf file).
every so often (2 weekly) we replace the large a attachment (5-15mb) with a
much smaller binary file (15k).

when I run
SELECT sum( relpages*8/1024 ) as MB FROM pg_class where relname != ''
I get a value of 104995 which I interpret to mean I have 104GB of stored data
in the database and this value has remained relatively static (+/- 1GB) over
the past couple of weeks.
We I to a df -h on the filesystem holding the database cluster I get a usage
of 140GB.  Again I interpret this to mean I have nearly 35GB of "uncleaned"
data.

Is this a case where I should be running the vacuum manually or is auto vacuum
all that should be necessary to keep track and mark the updated tuple space
ready for re-use.

thanks

--
Warren Little
Chief Technology Officer
Meridias Capital, Inc
1006 Atherton Dr
Salt Lake City, UT 84123
ph. 866.369.7763

Re: auto vacuum doens't appear to be working

От
Tom Lane
Дата:
Warren Little <warren.little@meridiascapital.com> writes:
> when I run
> SELECT sum( relpages*8/1024 ) as MB FROM pg_class where relname != ''
> I get a value of 104995 which I interpret to mean I have 104GB of stored data
> in the database and this value has remained relatively static (+/- 1GB) over
> the past couple of weeks.
> We I to a df -h on the filesystem holding the database cluster I get a usage
> of 140GB.  Again I interpret this to mean I have nearly 35GB of "uncleaned"
> data.

That conclusion is entirely incorrect --- relpages should be the whole
space usage for each table, assuming it's up-to-date (it might not be).
However a query done as above would account only for the current
database; perhaps the other space is in other databases?  If you've had
database crashes in the past, there could be problems with unreferenced
files.  Or the bloat could be in pg_xlog or one of the other overhead
directories, or not Postgres' fault at all considering that you're
examining the whole filesystem.  A single "df" number won't help you pin
it down, you need to do more careful analysis.  I'd start with a
directory-by-directory "du" listing, and check individual files if
necessary (contrib/oid2name or contrib/pgstattuple might help).  For
background see
http://www.postgresql.org/docs/8.1/static/storage.html
(adjust for your PG version)

            regards, tom lane

Re: auto vacuum doens't appear to be working

От
"Jim C. Nasby"
Дата:
Also, remember that a regular vacuum won't actually free any disk
space*, it only marks it as re-useable in the table.

* OK, technically it will reclaim space from the very end of the table
* in certain circumstances, but in reality it's pretty rare for that to
* happen.

On Fri, Jun 30, 2006 at 11:09:14AM -0400, Tom Lane wrote:
> Warren Little <warren.little@meridiascapital.com> writes:
> > when I run
> > SELECT sum( relpages*8/1024 ) as MB FROM pg_class where relname != ''
> > I get a value of 104995 which I interpret to mean I have 104GB of stored data
> > in the database and this value has remained relatively static (+/- 1GB) over
> > the past couple of weeks.
> > We I to a df -h on the filesystem holding the database cluster I get a usage
> > of 140GB.  Again I interpret this to mean I have nearly 35GB of "uncleaned"
> > data.
>
> That conclusion is entirely incorrect --- relpages should be the whole
> space usage for each table, assuming it's up-to-date (it might not be).
> However a query done as above would account only for the current
> database; perhaps the other space is in other databases?  If you've had
> database crashes in the past, there could be problems with unreferenced
> files.  Or the bloat could be in pg_xlog or one of the other overhead
> directories, or not Postgres' fault at all considering that you're
> examining the whole filesystem.  A single "df" number won't help you pin
> it down, you need to do more careful analysis.  I'd start with a
> directory-by-directory "du" listing, and check individual files if
> necessary (contrib/oid2name or contrib/pgstattuple might help).  For
> background see
> http://www.postgresql.org/docs/8.1/static/storage.html
> (adjust for your PG version)
>
>             regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: Have you checked our extensive FAQ?
>
>                http://www.postgresql.org/docs/faq
>

--
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