Re: Using pgiosim realistically

From: Jeff <threshar(at)torgo(dot)978(dot)org>
To: John Rouillard <rouilj(at)renesys(dot)com>
Cc: "ktm(at)rice(dot)edu" <ktm(at)rice(dot)edu>, pgsql-performance(at)postgresql(dot)org
Subject: Re: Using pgiosim realistically
Date: 2011-05-16 16:23:13
Message-ID: B15C84A0-369F-4F29-B3F3-A85C3107DDBD@torgo.978.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance


On May 16, 2011, at 9:17 AM, John Rouillard wrote:

>>>
>>> I am seeing really poor (70) iops with pgiosim. According to:
>>> http://www.tomshardware.com/reviews/2tb-hdd-7200,2430-8.html in the
>>> database benchmark they are seeing ~170 iops on a single disk for
>>> these drives. I would expect an 8 disk raid 10 should get better
>>> then
>>> 3x the single disk rate (assuming the data is randomly distributed).
>> Those drives are 7200 rpm drives which would give you a maximum write
>> rate of 120/sec at best with the cache disabled. I actually think
>> your
>> 70/sec is closer to reality and what you should anticipate in real
>> use.
>> I do not see how they could make 170/sec. Did they strap a jet
>> engine to
>> the drive. :)
>

also you are reading with a worst case scenario for the mechanical
disk - randomly seeking around everywhere, which will lower
performance drastically.

> Hmm, I stated the disk cache was disabled. I should have said the disk
> write cache, but it's possible the readhead cache is disabled as well
> (not quite sure how to tell on the lsi cards). Also there isn't a lot
> of detail in what the database test mix is and I haven't tried
> researching the site to see if the spec the exact test. If it included
> a lot of writes and they were being handled by a cache then that could
> explain it.
>

you'll get some extra from the os readahead and the drive's potential
own readahead.

> However, in my case I have an 8 disk raid 10 with a read only load (in
> this testing configuration). Shouldn't I expect more iops than a
> single disk can provide? Maybe pgiosim is hitting some other boundary
> than just i/o?
>

given your command line you are only running a single thread - use the
-t argument to add more threads and that'll increase concurrency. a
single process can only process so much at once and with multiple
threads requesting different things the drive will actually be able to
respond faster since it will have more work to do.
I tend to test various levels - usually a single (-t 1 - the default)
to get a base line, then -t (drives / 2), -t (#drives) up to probably
4x drives (you'll see iops level off).

> Also it turns out that pgiosim can only handle 64 files. I haven't
> checked to see if this is a compile time changable item or not.
>

that is a #define in pgiosim.c

also, are you running the latest pgiosim from pgfoundry?

the -w param to pgiosim has it rewrite blocks out as it runs. (it is a
percentage).

--
Jeff Trout <jeff(at)jefftrout(dot)com>
http://www.stuarthamm.net/
http://www.dellsmartexitin.com/

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Jeff Janes 2011-05-16 16:45:28 Re: reducing random_page_cost from 4 to 2 to force index scan
Previous Message Tom Lane 2011-05-16 15:46:45 Re: reducing random_page_cost from 4 to 2 to force index scan