Dave North wrote:
> Morning folks,
> Long time listener, first time poster.
Hi Dave
> Postgres 8.1.8
> shared_buffers = 2000
> max_fsm_pages = 400000
> Redhat Enterprise 4
> Running on HP DL380 w/ 4GB RAM, dual 10K HDDs in RAID 0+1
> Also running on the server is a tomcat web server and other ancillaries
The value of 2000 seems a bit low for shared_buffers perhaps. Oh, and
8.1.13 seems to be the latest bugfix for 8.1 too.
> Now, the problem. We have an application that continually writes a
> bunch of data to a few tables which is then deleted by a batch job each
> night. We're adding around 80,000 rows to one table per day and
> removing around 75,000 that are deemed to be "unimportant".
[snip]
> We had this problem around a month ago and again yesterday. Because the
> application needs reasonably high availability, we couldn't full vacuum
> so what we did was a dump and load to another system. What I found here
> was that after the load, the DB size was around 2.7GB - a decrease of
> 5GB. Re-loading this back onto the main system, and the world is good.
Well, that's pretty much the definition of bloat. Are you sure you're
vacuuming enough? I don't have an 8.1 to hand at the moment, but a
"vacuum verbose" in 8.2+ gives some details at the end about how many
free-space slots need to be tracked. Presumably you're not tracking
enough of them, or your vacuuming isn't actually taking place.
Check the size of your database every night. It will rise from 2.7GB,
but it should stay roughly static (apart from whatever data you add of
course). If you can keep it so that most of the working-set of your
database fits in RAM speed will stay just fine.
> Yes, I know we need to upgrade to 8.3 but that's going to take some time
> :)
I think you'll like some of the improvements, but it's probably more
important to get 8.1.13 installed soon-ish.
--
Richard Huxton
Archonet Ltd
