Vacuum Problems (locking) - Mailing list pgsql-admin

From Mike Goldner
Subject Vacuum Problems (locking)
Date
Msg-id 1161806057.2095.154.camel@localhost.localdomain
Whole thread Raw
Responses Re: Vacuum Problems (locking)
Re: Vacuum Problems (locking)
Re: Vacuum Problems (locking)
Re: Vacuum Problems (locking)
List pgsql-admin
I have a nightly vacuum scheduled as follows:

su - postgres -c "/usr/bin/vacuumdb --analyze --dbname=mydb"

Last night, it appears that the vacuum blocked db access from my
application server (JBoss).  Here is the logfile snippet:

[3693-jbossdb-postgres-2006-10-25 06:52:29.488 EDT]NOTICE:  number of
page slots needed (559472) exceeds max_fsm_pages (200000)
[3693-jbossdb-postgres-2006-10-25 06:52:29.488 EDT]HINT:  Consider
increasing the configuration parameter "max_fsm_pages" to a value over
559472.
[3693-jbossdb-postgres-2006-10-25 06:52:29.488 EDT]LOG:  number of page
slots needed (559472) exceeds max_fsm_pages (200000)
[3693-jbossdb-postgres-2006-10-25 06:52:29.488 EDT]HINT:  Consider
increasing the configuration parameter "max_fsm_pages" to a value over
559472.
[3693-jbossdb-postgres-2006-10-25 06:52:29.530 EDT]LOG:  transaction ID
wrap limit is 1073813592, limited by database "benchpg"
[3693-jbossdb-postgres-2006-10-25 06:52:29.530 EDT]LOG:  transaction ID
wrap limit is 1073813592, limited by database "benchpg"
[3693-jbossdb-postgres-2006-10-25 06:52:29.530 EDT]LOG:  duration:
10224738.050 ms  statement: VACUUM ANALYZE;

First of all, my max_fsm_pages is obviously way off.  However, every
time I increase my max_fsm_pages the next vacuum says that it requires
more.  Will there every be a plateau in the requested pages?  What is
the impact of exceeding the pages slots needed?

Secondly, in this case, it almost looks like there were two vacuum
process running based on the duplicated log messages.  There is only one
cron job, so there shouldn't have been a second vacuum running.  Should
I just ignore this?

Finally, and most important is the blocking.  The vacuum duration
reported in the log converts to about 170 minutes.  I can track
backwards in the log and the only messages prior to the 6:52am
completion of the vacuum end at 3:57am (almost exactly 170 minutes
prior).

So, all indications point to postgres blocking all access during the
entire vacuum.

The only semi-unusual characteristic of my database is that I have one
table in particular that grows and shrinks dramatically.  My entire
database after a vacuum --full is about 8GB.  However, after a day or
two, the db will grow as large as 75GB.  Truncating that one table
(since it empties regularly) will shrink the db right back to the 8GB.

Is it possible that the extreme table size (maybe requiring the high
number of page slots) is causing postgres to block more than it should
in order to process that table?

Thanks,

Mike

pgsql-admin by date:

Previous
From: Luís Sousa
Date:
Subject: pg_restore and drop table problems
Next
From: "Joshua D. Drake"
Date:
Subject: Re: Vacuum Problems (locking)