Link: https://social.technet.microsoft.com/wiki/contents/articles/3214.sql-server-monitoring-disk-usage.aspx

You should only use the secondary counters for the drive(s) that have high latency. If the drive has acceptable latency, there is no point in moving forward.

Disk counters that you can monitor to determine disk activity are divided into the following two groups:

  • Primary

    • PhysicalDisk: Avg. Disk sec/Write
    • PhysicalDisk: Avg. Disk sec/Read
  • Secondary

    • PhysicalDisk: Avg. Disk Queue Length
    • PhysicalDisk: Disk Bytes/sec
    • PhysicalDisk: Disk Transfers/sec

Why is disk queue length an ineffective measure when there is no latency?

  • 3
    Why would you care how many requests are in the queue if your application receives data without delay?
    – mustaccio
    Jul 7, 2022 at 13:41
  • Why would there be a sizable queue if the disk can process data without delay?
    – variable
    Jul 7, 2022 at 14:56

1 Answer 1


Queue length is simply not a good indicator by itself.

Everything needs to go through the queue to get processed. A long queue might not mean slow response times.

Lets think about this with a metaphor from real life.

If I go to my local post office, there is usually just one employee there. If there are five people waiting in line, I would consider that "long" for my post office. If folks are just dropping off packages, the queue might move very quickly, and I would be able to do my business with ease. If they are doing more complicated transactions, I might be frustrated with how long it takes to get through the queue.

If I am at a restaurant, if they have a wait to be seated, the number of people in front of you waiting for tables might not matter. There could be five tables in front of you in queue, but all the seated diners stay seated--you will have an unacceptably long wait. Or, there could be 25 tables that all showed up at once making a long queue, but plenty of available tables--you would have to get through the front door, but sit down immediately--with very little wait to get to the front of the queue.

Back to disks

Simply stated, if there are a bunch of IO requests happening at the same time, they might have to spend a short time traversing the queue, and the queue depth might spike momentarily. However, if the queue is fast moving it won't be a problem. Similarly, with a high throughput system, you might see a constant queue depth that (by itself) seems high, but because it is responding to requests quickly it would not cause any problems.

You generally want to monitor all of the recommended counters, but you should only alert when there is a problem on both the Primary & Secondary counters.

  • It might be worth mentioning that the device driver might choose to queue I/O requests on its own, if it thinks that batching them or sending them in a particular order would be more efficient. Also, the fact that a particular request is considered to be in the queue doesn't mean it's blocked: in-flight requests will be counted as well.
    – mustaccio
    Jul 7, 2022 at 22:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.