Enzo D'addario wrote:
>I currently have postgres 7.4.2 running on a dedicated server which has
>1GB RAM, a Pentium 4 2600 Mhz processor, uses ReiserFS filesystem and is
>running Debian stable.
>After approximately 1 month I have to dump & restore the database
>because vacuum time spirals out of control. To give you an idea of what
>I experience, when the DB is restored it takes 1 hour to vacuum, however
>by the time the restore is 30 days old it can take up to 6 hours. I
>never experienced such issues with earlier versions of postgres.
>The DB is approximately 6 GB in size and is vacuumed analyzed nightly
>because of a relatively high number of transactions per day.
>Another thing that I noticed from the vacuum logs is that the total
>pages needed shortly after restore is approximately 17000 and ends up
>over 50000 by the time the restore is 30 days old.
>Does this mean the DB is becoming fragmented?
Not fragmented, but bloated. Sounds like you need to vacuum more often
and / or increase your FSM settings.
>Will upgrading to postgres 8.0 resolve this problem?
No, I think a more agressive vacuum regiment and / or larger FSM
settings will solve this even 7.4. Lots of people either setup cron to
hit their more active tables more often, or use pg_autovacuum.
In response to
pgsql-admin by date
|Next:||From: Tom Arthurs||Date: 2005-06-28 05:03:36|
|Subject: Re: moving database to diff. server|
|Previous:||From: Michael Fuhr||Date: 2005-06-28 04:43:04|
|Subject: Re: pg_dump -Fc does not dump indexes|