Re: dbt2 performance

From: Greg Smith <greg(at)2ndquadrant(dot)com>
To: Yu-Ju Hong <yuru(dot)hong(at)gmail(dot)com>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: dbt2 performance
Date: 2010-02-25 22:48:10
Message-ID: 4B86FE2A.1030205@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

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.

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.

--
Greg Smith 2ndQuadrant US Baltimore, MD
PostgreSQL Training, Services and Support
greg(at)2ndQuadrant(dot)com www.2ndQuadrant.us

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Yu-Ju Hong 2010-02-25 23:29:42 Re: dbt2 performance
Previous Message Yu-Ju Hong 2010-02-25 21:23:53 dbt2 performance