Thanks for the reply.
On Thu, Feb 25, 2010 at 5:48 PM, Greg Smith
<greg@2ndquadrant.com> wrote:
Yu-Ju Hong wrote:
2. Moreover, the disk utilization was high and the "await" time from iostat is around 500 ms. Could disk I/O limit the overall throughput? The server has 2 SATA disks, one for system and postgresql and the other is dedicated to logging (pg_xlog). As far as I understand, modern database systems should be CPU-bound rather than I/O-bound, is it because I did not perform adequate performance tuning?
In my test, there was almost no disk reads (mostly disk writes), so I assumed the size of the database didn't cause the performance bottleneck. Maybe I was wrong. If so, should I increase shared_buffer?
Assuming that dbt2 was limited by disk I/O in my experiments, do you think the numbers I got with my server configuration are reasonable?
Also, would you mind giving some examples where the applications are CPU bound? That could be useful information to me.
By the way: a large increase in checkpoint_segments is the first thing you should do. If you check the database logs, they're probably filled with complaints about it being too low. 32 would be a useful starting value, going much higher for a test that's only 10 minutes long is probably cheating.
I increased the checkpoint_segments to 10 when I ran the tests. I'll certainly increase it to 32 and give it a try.
--
Greg Smith 2ndQuadrant US Baltimore, MD
PostgreSQL Training, Services and Support
greg@2ndQuadrant.com www.2ndQuadrant.us
Thanks,
Yu-Ju
