Vacuum not identifying rows for removal..

From: "Eamonn Kent" <ekent(at)xsigo(dot)com>
To: <pgsql-performance(at)postgresql(dot)org>
Subject: Vacuum not identifying rows for removal..
Date: 2006-08-21 18:50:02
Message-ID: 9146E3EBBFBCC94D95F95A1C4065348A837AB1@exch01.xsigo.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Hi,

I am using PostgreSQL 8.1.4 for an embedded application. For some
reason, vacuum is not able to identify rows that are candidates for
removal (i.e., mark space as available).

Background Info:

I observed some performance problems - our database seemed to be using
an unusually high amount of cpu. Further investigation of the problem
revealed a very bloated database; the database was around 300M when it
should have been about 150M. A number of the database files were quite
large, however, the tables that they stored information for were very
small. For example, we had one table that had only 46 rows, but was
using up more than 17M of disk space. We had a number of other tables
that were similarly large.

We run auto vacuum and I can see from the logs that it is running quite
frequently. When I run vacuum full from the psql, I can see that space
is not being recovered. I have run vacuum full with the verbose flag
set, I can see that messages that indicate the existence of "dead row
versions that cannot be removed yet.

<--- CUT FROM VACUUM OUTPUT --->

CPU 0.00s/0.00u sec elapsed 0.18 sec.

INFO: "ibportreceivestatsca": found 0 removable, 88017 nonremovable row
versions in 4001 pages

DETAIL: 87957 dead row versions cannot be removed yet.

There were 1 unused item pointers.

<--- CUT FROM VACUUM OUTPUT --->

If I shutdown our application and run a vacuum full, the space is
recovered and the database size goes down to 150M.

So, my best guess is that something in our application is preventing
vacuum from removing dead rows. What could cause this? Would it be
caused by a long-living transaction? What is the best way to track the
problem down...right now, I am looking through pg_stat_activity and
pg_locks to find processes that are "in transaction" and what locks they
are holding.

Has anyone had a similar problem? If so, how did you resolve it?

Thanks

Ike

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Brad Nicholson 2006-08-21 19:25:04 Re: Vacuum not identifying rows for removal..
Previous Message Tom Lane 2006-08-21 18:26:19 Re: Index usage