When do I want to look at IOPs and when megs per second?

Question: When do I want to look at IOPs and when megs per second?

Answer: IOPs and Megs Per second are two very different numbers, and there are specific times when you want to look at each one. When dealing with sequential IO, which is typically generated by a data warehouse or reports being run that look at large amounts of data you want to monitor the counters which report the number of Megs Per Second.  When dealing with random IO, which is typically generated by OLTP databases, you want to monitor the number of IOPs that are being processed.

The reason for the difference is that when dealing with random IO you need to keep in mind that it takes time for the head to move from each place to the next that it needs to read or write.  The further apart that these blocks are on the physical disks are from each other the lower the number of IO that the disks can process per second.  While when dealing with sequential IO the blocks are right next to each other so you want to keep track of the amount of data that is being pushed down to the disks.  The number of IO being processed end up going through the roof as the blocks are next to each other, so when doing sequential IO monitoring the IO numbers isn't helpful instead you'll want to monitor the throughput in megabytes.


Discuss this Blog Entry 1

on Dec 2, 2011
Hi Denny, Thanks for the clarification. This is very helpful. I understand why it isn't useful to monitor IOPS in a sequential IO scneraio, but I don't understand why it isn't useful to monitor megs per second in a random IO scenario. In an OLTP system, if all IO operations were of the same size, then there wouldn't be a difference between monitoring IOPS vs. megs per second. But in reality there are small IO operations and large IO operations. Monitoring megs per second will give us some kind of average throughput in the system. What's wrong with this approach? If we can always monitor IO activity with the same counters, then our life would be easier, because we won't need to make assumptions about the characteristics of each system - whether it's more sequential or more random in nature. Guy Glantser, SQL Server Consultant, Madeira

Please or Register to post comments.

What's Troubleshooting SQL Server Storage Problems?

Practical advice, insight, and help for core SQL Server considerations.


Denny Cherry

Denny Cherry is the owner and principal consultant for Denny Cherry & Associates Consulting and has over a decade of experience working with platforms such as Microsoft SQL Server, Hyper-V,...
Blog Archive

Sponsored Introduction Continue on to (or wait seconds) ×