Thread: vacuum taking longer over time
Hi All, 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? Will upgrading to postgres 8.0 resolve this problem? Any ideas would be greatly appreciated. Thanks in advance. Enzo D'Addario
Enzo D'addario wrote:
>Hi All,
>
>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.
Good luck.
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Enzo D'addario wrote:
>Hi All,
>
>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.
Good luck.
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
http://archives.postgresql.org