IOPS (Input/Output Operations Per Second)
2009-12-09 Initial Post
I haven’t been able to find any one standard for measuring IOPS (like something from ANSI or ISO), so it seems that vendors can use different variables to test IOPS, thereby attempting to make their numbers look better than that of their competitors’.
Based on the info below (I particularly like the whitepaper from Texas Memory Systems since it’s very succinct and easy to understand) and previous knowledge, here are some things to keep in mind regarding IOPS:
1.) Since there are no IOPS measurement standards, you really need to consult a third party or test the devices out yourself with your particular applications and workload. You should not depend solely on a vendor’s numbers—remember, they’re trying to sell you something, so of course they’ll give you the best-case scenario numbers, which might not be applicable in the real world.
2.) IOPS settings need to be optimized for specific applications. Some applications do more reading than writing, so in that case, optimizing the IOPS for reads would be more beneficial. And some applications read data in specific chunks, such as Exchange Server 2003 reading 4KB database pages. Just because a particular device has higher total IOPS, it might not work well for every application.
3.) Because storage arrays abstract a lot of the underlying storage, you can’t depend on the IOPS specs for the array’s underlying hard drives. All the major vendors should have best practices for optimizing IOPS for major applications such as Exchange and SQL, so always follow the vendor’s guidance.
4.) To increase IOPS, you might need to actually purchase separate systems to get higher aggregate IOPS.
##### From http://en.wikipedia.org/wiki/IOPS on 2009-12-09:
Like with any benchmark, IOPS numbers published by drive and SAN vendors are often misleading and do not guarantee real-world application performance. . .
The specific number of IOPS possible in any server configuration will vary greatly depending upon the variables the tester enters into the program, including the balance of read and write operations, the mix of random or sequential access patterns, the number of worker threads and queue depth, as well as the data block sizes. . .
The most common performance characteristics that are measured or defined are as follows:
Total IOPS
Total number of I/O operations per second (when performing a mix of read and write tests)
Random Read IOPS
Average number of random read I/O operations per second.
Random Write IOPS
Average number of random write I/O operations per second.
Sequential Read IOPS
Average number of sequential read I/O operations per second.
Sequential Write IOPS
Average number of sequential write I/O operations per second.
The random IOPS numbers are primarily dependent upon the storage device's random seek time, whereas the sequential IOPS numbers (especially when using a large block size) typically indicate the maximum bandwidth that a storage device can handle. Often the latter get replaced by a simple MB/s number. #####
##### From http://www.texmemsys.com/files/f000164.pdf on 2009-12-09:
Be wary of hardware vendors that publish burst rates, as these are not sustainable in a realistic high traffic environment. Similarly, many storage systems will publish high IOPS rates “from cache,” which cannot reflect real-world application performance. . .
Be wary of hardware vendors publishing IOPS that are based on sequential reads and writes [as compared to random reads and writes]. These numbers are not generally representative of real‐world data traffic. . .
A good rule of thumb is that as frame [aka block or sector] size increases, the number of IOPS decrease and MB/s increases. Therefore you are likely to see the best IOPS performance with small frame sizes and the best bandwidth (MB/s) performance with large frame sizes.
When storage manufacturers design interfaces they tend to optimize the hardware and software for 512 byte transfers, to maximize their advertised IOPS rate. . .
It is often the case, especially in older systems, that a single processor is not capable of driving a system to generate sufficient IOPS to saturate the RamSan. This is especially true if multiple HBAs are used in a single system. Additionally, while multi‐processor systems improve overall throughput, it does not scale linearly. Therefore, we frequently see multiprocessor systems that cannot provide the throughput of an equivalent number of separate host servers. #####
