On Wed, Aug 24, 2005 at 12:56:54PM -0400, Chris Hoover wrote: > I don't have real numbers to give you, but we know that our systems > are hurting i/o wise and we are growing by about 2GB+ per week (net). > We actually grow by about 5GB/week/server. However, when I run my > weekly maintenance of vacuum full, reindex, and the vacuum analyze, we > end up getting about 3GB back. Unfortunately, I do not have the i/o > bandwidth to vacuum during the day as it causes major slowdowns on our > system. Each night, I do run a vacuum analyze across all db's to try > and help. I also have my fsm parameters set high (8000000 fsm pages, > and 5000 fsm relations) to try and compensate.
[...] > Right now, we are still on 7.3.4. However, these ideas would be > implemented as part of an upgrade to 8.x (plus, we'll initialize the > new clusters with a C locale). If you were on a newer version, I'd suggest that you use the cost-based vacuum delay, and vacuum at least some of the tables more often. This way you can reduce the continual growth of the data files without affecting day-to-day performance, because you allow the VACUUM-inflicted I/O to be interleaved by normal query execution. Sadly (for you), I think the cost-based vacuum delay feature was only introduced in 8.0. -- Alvaro Herrera (<alvherre[a]alvh.no-ip.org>) Officer Krupke, what are we to do? Gee, officer Krupke, Krup you! (West Side Story, "Gee, Officer Krupke") ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly