-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Matthew T. O'Connor wrote:
| Gaetano Mendola wrote:
|
|> I'm pretty sure, see the attached graph. Each morning at 7 a script stop
|> the autovacuum, vacuum full the database and reindex the eavy updated
|> tables
|> and restart of course the autovacuum. Note also that for all the day I
|> didn't
|> have the usual disk usage increment.
|
|
| I don't know why the 1st VACUUM FULL wasn't able to reclaim the same
| amount of space as the 2nd one, but I would guess that it wasn't able to
| get a lock on some table. It could have been autovac if it was doing a
| vacuum at that moment, but it could have been something else too.
|
| From the attached graph, it looks like your stead state database size
| is approx 3.0G. After the 2nd VACUUM FULL, you dropped to 2.5G, but as
| you can see it's creeping up back up again.
|
| If you let it continue to run without running VACUUM FULL, but with
| autovacuum enabled, and it climbs to 3.0G and stops growing, then I
| think you are fine and you don't need to run VACUUM FULL at all. If it
| continues to grop witout bound, then you need to up your FSM and/or make
| autovac more aggressive.
|
| Bottom line, you shouldn't need VACUUM FULL, if you do, I think there
| are people on this list that would like to hear about it.
I will try to disable ( I hope the management is not reading this list )
the vacuum full performed each morning, I'll leave only the reindex for
a couple of table and I'll see what happen I will post another graph
Regards
Gaetano Mendola
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFA/p247UpzwH2SGd4RAokEAJ9+xhF9g8ZbzE3ne6qCFOuV6z3LmACg9yQR
hL7LaOX8EucswifK5okQZ9g=
=jKG9
-----END PGP SIGNATURE-----
