RE: I/O performance
Date: Thu, 21 Jun 2012 16:19:39 +0000
Message-ID: <A250F0C68C23514CA9F3DF63D60EE10E163C62B3_at_onews31>
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
- Random IO is spread across the entire disk
- 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_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] 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_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] 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.
-- http://www.freelists.org/webpage/oracle-lReceived on Thu Jun 21 2012 - 11:19:39 CDT