On Thu, Feb 25, 2010 at 6:29 PM, Yu-Ju Hong <yuru.hong@xxxxxxxxx> wrote: > Thanks for the reply. > > On Thu, Feb 25, 2010 at 5:48 PM, Greg Smith <greg@xxxxxxxxxxxxxxx> 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? >> >> 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. > > 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? Well if you're writing a lot of stuff to disk you could easily be I/O limited. > 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? Since you've provided no details on your hardware configuration I'm not sure how anyone could express an educated opinion on this (personally I wouldn't know anyway, but others here would). > Also, would you mind giving some examples where the applications are CPU > bound? That could be useful information to me. You'll typically be CPU bound when you're not I/O bound - i.e. when the data that your accessing is small enough to fit in memory. ...Robert -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
