Skip site navigation (1) Skip section navigation (2)

Re: Database size Vs performance degradation

From: Richard Huxton <dev(at)archonet(dot)com>
To: Dave North <DNorth(at)signiant(dot)com>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: Database size Vs performance degradation
Date: 2008-07-30 12:28:09
Message-ID: 48905E59.9040007@archonet.com (view raw or flat)
Thread:
Lists: pgsql-performance
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

In response to

Responses

pgsql-performance by date

Next:From: Matthew WakelingDate: 2008-07-30 12:36:42
Subject: Re: Database size Vs performance degradation
Previous:From: Dave NorthDate: 2008-07-30 12:09:10
Subject: Database size Vs performance degradation

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group