DPACK Basics: Queue Depth Values
Queue depth is important to understand along with other metrics to help qualify potential bottlenecks to maximize performance in a system. Queue depth is the number of outstanding I/Os waiting to be processed at the disk drive from the Disk Controller. However, Queue Depth by itself is not a measure of good or bad, it’s simply a number.
Queue depth is probably one of the most misunderstood metrics in DPACK. It is very often inappropriately pointed out to suggest a disk limitation too quickly. In order to understand Queue Depth in DPACK you would need to know the number of disks that made up a particular drive. Unfortunately, DPACK does not have this information.
It is important to note that DPACK monitors the number of outstanding I/O operations from the host OSes perspective. Host level queue depth will be reported differently than at a storage array-level and the two may have extremely different values.
To extract value from the Queue Depth in DPACK you will need to have a few rules of thumb, the corresponding latency values, and optionally knowledge of the system itself.
Obtaining knowledge of the system might not be an option, but these rules of thumb will help get you started.
Host based Queue Depth should be kept at between 2-4 outstanding I/Os per drive that make up the drive or LUN. For example, in a RAID set of 5 drives, then 10-20 or below for a Disk Queue in DPACK would be in a normal range.
However, that is a tedious and largely unneeded task when trying to get general information. Using the Viewer to show all graphs at once will place the Disk Queue and Latency graphs on top of each other. Each graph is representing the same time recording, so this makes it easy to look for corresponding values.
Low Queue Depth/ High Latency: Potential Network or Server bottleneck
Low Queue Depth/ Low Latency: under-utilized or properly designed Disk resources
High Queue Depth/ Low latency: no particular problems
High Queue Depth/ High Latency: Potential Disk Bottleneck
This last entry is where you can start to look at disk as the problem. If there are mirroring spike values between latency and Queue Depth. Then inspecting the disk would be a logical activity.
Here is a picture of Latency that would look suspiciously effected by high Queue Depth