I've been lobbying management here for us to allocate some resources to testing 
8.3 once it hits beta.  If it is approved, it might happen on a time frame too 
short to get much feedback before the tests, so I'm throwing the question out 
here now: what would people like us to bang on?
The box most likely to be used for the testing is a bit old, but still, it is 
SMP and we would be throwing real-world traffic at it, so it should be of some 
value.  It has 4 2 GHz Xeon MP CPUs, 6 GB RAM, and a RAID controller with 256 
MB battery-backed RAM cache.  The 230 GB database would be sitting on a 407 GB 
RAID 5 array.  In addition to the PostgreSQL instance there would be two Java 
middle tiers running on the box.
One middle tier is for modifying data based on transactions received from 72 
source databases; this load is about 1 million database transactions on a 
typical work day, with an average of maybe 20 INSERT, UPDATE, and DELETE 
statements per transaction.  (We don't typically have many deletes.)  The other 
middle tier uses a login which only has SELECT rights to support our web site.  
We have about 2 million web hits per day generating about 10 million database 
transactions.  We can play the actual HTTP requests from our log through a bank 
of renderers to get a real mix of queries from production.
We're particularly interested in seeing what configuration changes we may have 
to make to achieve optimal performance with the checkpoints and background 
writer in the new release.  When we first went to PostgreSQL our biggest 
problem was that dirty buffers would accumulate in shared memory until a 
checkpoint, and then overrun the controllers cache.  This would cause disk 
reads to queue up behind the writes, and queries which normally ran in a 
millisecond or two were timing out at our renderers' 20 second limit.  The 
problem went away completely when we used a very aggressive background writer 
configuration, to put the dirty pages in front of the OS file system right 
away, so that its algorithms and the controller cache could deal with things 
before they got out of hand.
We could run some tests with just the read-only web load, if that is useful, or 
push the update load alone.  We could pace input.  My guess is that the most 
useful tests would involve letting both run as fast as the machine can handle 
it with various configurations and see what throughput and timeout counts we 
Any thoughts or suggestions welcome, particularly about what configurations to 

---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at


Reply via email to