pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Robert Haas <robertmhaas@gmail.com>
To: Yu-Ju Hong <yuru.hong@gmail.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: dbt2 performance
Date: Wed, 3 Mar 2010 12:09:38 -0500
Message-ID: <603c8f071003030909m1a27372dm4900badeac7c17df@mail.gmail.com> (raw)
In-Reply-To: <516a4a601002251529y7d445a19w15750315db8b5bd8@mail.gmail.com>
References: <516a4a601002251323udcc2b41tf5a09b968bef3a7c@mail.gmail.com>
	<4B86FE2A.1030205@2ndquadrant.com>
	<516a4a601002251529y7d445a19w15750315db8b5bd8@mail.gmail.com>

On Thu, Feb 25, 2010 at 6:29 PM, Yu-Ju Hong <yuru.hong@gmail.com> wrote:
> 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?
>>
>> 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



view thread (4+ messages)

Message-ID: <603c8f071003030909m1a27372dm4900badeac7c17df@mail.gmail.com>
Permalink:  ../603c8f071003030909m1a27372dm4900badeac7c17df@mail.gmail.com/
Also on:    postgresql.org/message-id/603c8f071003030909m1a27372dm4900badeac7c17df@mail.gmail.com

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-performance@postgresql.org
  Cc: robertmhaas@gmail.com, yuru.hong@gmail.com
  Subject: Re: dbt2 performance
  In-Reply-To: <603c8f071003030909m1a27372dm4900badeac7c17df@mail.gmail.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox