RE: I/O performance
- From: "Allen, Brandon" <Brandon.Allen@xxxxxxxxxxx>
- To: "ChrisDavid.Taylor@xxxxxxxxxxxxxxx" <ChrisDavid.Taylor@xxxxxxxxxxxxxxx>, "'niall.litchfield@xxxxxxxxx'" <niall.litchfield@xxxxxxxxx>, 'ORACLE-L' <oracle-l@xxxxxxxxxxxxx>
- Date: Thu, 21 Jun 2012 16:19:39 +0000
I've researched this more and was a little surprised by my findings so figured
I'd share them in case anyone else also finds them interesting and hoping
someone else will correct me if I'm wrong. The following article explains the
fact that the typical IOPS advertised or calculated for a given disk is based
on two major assumptions:
http://www.qdpma.com/Storage/IoQueueDepthStrategy.html
1) Random IO is spread across the entire disk
2) A queue length (aka depth) of 1
So, for example with a 15K disk rated for an avg seek time of 2ms and read
transfer time of 3.5ms, you might expect 182 IOPS (1/(.002+.0035)). However,
you can actually get much higher IOPS than that if your data is located nearby
on disk and/or if you run at higher queue length, allowing the controller to
reorder and group the IOs so they are closer together on disk, at the expense
of higher latency.
I tested this with Orion and I found that indeed, I was able to push up to 8500
IOPS on just 8 * 15K disks - but that was with a queue length of 240 and
latency of 28.4ms, which would probably be unacceptable for a latency-sensitive
(OLTP) app, but might be perfectly acceptable for throughput-sensitive activity
like nightly batch jobs, backups, etc.
Below is the output from orion executed with the option "-run oltp"
Outstanding IOs 12 24 36 48 60 72 84 96
108 120 132 144 156 168 180 192 204 216
228 240
IOPS 2579 4190 5139 5740 6178 6482 6746 6992 7209
7382 7565 7711 7818 7944 8050 8161 8240 8309 8389
8455
Latency (s) 0.0047 0.0057 0.0070 0.0084 0.0097 0.0111 0.0124 0.0137
0.0150 0.0163 0.0174 0.0187 0.0199 0.0211 0.0224 0.0235 0.0247 0.0260
0.0272 0.0284
I also just learned about "Little's Law", which can be interpreted as
IOPS*Latency=Queue_Length and I found that this hold perfectly true in the
Orion results, e.g. 8455 * .0284 = 240
Regards,
Brandon
-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On
Behalf Of Allen, Brandon
Sent: Friday, June 08, 2012 11:26 AM
I think the 75% estimate is a good rule of thumb, but I don't think the
explanation below is correct. I think if you run a test of only single-block
random reads, you can indeed hit the calculated max IOPS of a disk drive. I
think the reason for reducing the IOPS estimate to 75% for actual
implementation planning is that in real-world usage many of the IOs will
probably be larger sequential IOs (rather than random IOs), e.g. Full Table
Scans, which will increase the observed transfer rate, but decrease the IOPS.
Notice that I've prefaced all my statements with "I *think*" - that's because I
haven't actually tested these claims myself and I'm not a hardware expert, so
feel free to correct me if I'm wrong.
-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On
Behalf Of Taylor, Chris David
Of the approximate calculated IOPS, you can only count on about 75% of that
capacity as you will never reach the full calculated IOPS because there is a
direct relationship between disk utilization and response time - as utilization
increases, response time decreases, so only count on about 75% of the
calculated IOPS per disk. (I tried to find a specific link illustrating this
relationship but gave up)
________________________________
Privileged/Confidential Information may be contained in this message or
attachments hereto. Please advise immediately if you or your employer do not
consent to Internet email for messages of this kind. Opinions, conclusions and
other information in this message that do not relate to the official business
of this company shall be understood as neither given nor endorsed by it.
--
//www.freelists.org/webpage/oracle-l
Other related posts:
