On Thu, Feb 25, 2010 at 5:48 PM, Greg Smith <greg@xxxxxxxxxxxxxxx> wrote:
Yu-Ju Hong wrote:dbt2 is almost exclusively disk I/O bound once the data set gets big enough. There are some applications where most of the data fits in RAM and therefore CPU performance is the limiter. dbt2 is exactly the opposite of such an application though, and the idea that "modern database systems should be CPU bound" is not really true at all. That's only the case if the data you're operating on fits in RAM. Otherwise, databases are just as I/O bound as they've always been. Main thing that's changed is there's a lot more RAM in systems nowadays.
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@xxxxxxxxxxxxxxx www.2ndQuadrant.us
Thanks,
Yu-Ju
