| From: | "Matthew T(dot) O'Connor" <matthew(at)zeut(dot)net> | 
|---|---|
| To: | Enzo D'addario <enzo(at)pienetworks(dot)com> | 
| Cc: | pgsql-admin(at)postgresql(dot)org | 
| Subject: | Re: vacuum taking longer over time | 
| Date: | 2005-06-28 04:55:17 | 
| Message-ID: | 42C0D835.7000603@zeut.net | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-admin | 
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.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Arthurs | 2005-06-28 05:03:36 | Re: moving database to diff. server | 
| Previous Message | Michael Fuhr | 2005-06-28 04:43:04 | Re: pg_dump -Fc does not dump indexes |