Skip site navigation (1) Skip section navigation (2)

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: (view raw, whole thread or download thread mbox)
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:
>>>,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  

Jeff Trout <jeff(at)jefftrout(dot)com>

In response to


pgsql-performance by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group