What affects “IOPS” in a storage system?

For many, the primary barometer of storage performance is measured in Input/Output Operations Per Second, or IOPS for short.  While there are many other metrics used in production environments to ensure that everything runs as it should, when you’re in the market for storage for your virtual environment, many storage vendors like to tout IOPS values as a comparative metric.  Unfortunately, an IOPS is not an IOPS is not an IOPS.  There are a number of variables that determine just how many IOPS a storage system supports.  Also bear in mind that storage systems have both read and write functions and, as such, there is often different read and value IOPS potential for the same system.  It can be difficult in a virtual environment to perfectly calculate IOPS because of the mixed I/O nature of these kinds of architectures.  Different workloads have different I/O needs, so a storage array which, at first glance, looks like it might support  workload may, in fact, perform horribly.

I will discuss three primary – and broad – metrics in this article.

Disk type

Different kinds of disks perform differently.  You probably already know that a solid state disk generally performs vastly better than a SATA disk, for example.  There are all kinds of articles that discuss the disk type and how many IOPS are generally supported by that kind of disk.  Here are some generally accepted IOPS values for disk types:

  • 7200 RPM SATA disk. 50 to 75 IOPS.
  • 10K RPM SAS disk. 110 to 140 IOPS.
  • 15K RPM SAS disk.  150 to 200 IOPS.
  • Solid state disks.  Thousands of IOPS per disk.

Bear in mind that these IOPS figures are very raw and are just used for discussion purposes.  There are other factors that affect these figures.

RAID level

If you’re using a RAID-based system, the choice of RAID level is critically important when it comes to calculating IOPS.  For the common RAID levels — RAID 1, RAID 5, RAID 6, RAID 10 – IOPS, especially during write operations, are significant affected.  For example, for RAID 1, every time you write to the disk, two I/O operations are required – one for the first copy of the mirror and one for the second.  This need can effectively cut your write IOPS potential in half.  As you design a storage environment for your organization, this is a critical fact.

  • RAID 1 and 10. 2 IOPS required for every write operations.
  • RAID 5. 4 IOPS required for every write operation.
  • RAID 6. 6 IOPS required for every write operation.

I’ll say it again: Always keep RAID level in mind when you’re designing a storage system!  Also, bear in mind that many vendors have specialty RAID levels that can help you to get around some RAID performance issues, so be sure to do your homework.

Block size

Perhaps the most often neglected element in IOPS calculations is the block size selected for the storage.  In general, there is an inverse relationship between block size and IOPS count.  The larger the block size, the fewer IOPS that will be performed.  If you stop and think about this, it really makes sense.  A larger block size will take a bit longer to read or write while a small block size can be read or written very quickly.  So, IOPS will be lower with larger blocks.

But don’t go away thinking that’s a bad thing!  The “right” block size depends on your workload.  If you’re doing work that needs to constantly write very small files, a smaller block size will help that process move along faster.  If you were to use a larger block size, it could result in slower performance.  Likewise, if you write larger files, you might consider a larger block size since it will take fewer writes to write that files.

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top