Linchi Shea : Best Practices, Queueshttp://sqlblog.com/blogs/linchi_shea/archive/tags/Best+Practices/Queues/default.aspxTags: Best Practices, QueuesenCommunityServer 2.1 SP2 (Build: 61129.1)Disk Queue Length: Some Data Points may Help!http://sqlblog.com/blogs/linchi_shea/archive/2007/11/12/disk-queue-length-some-data-points-may-help.aspxMon, 12 Nov 2007 21:38:00 GMT21093a07-8b3d-42db-8cbf-3350fcbf5496:3303Linchi Shea2http://sqlblog.com/blogs/linchi_shea/comments/3303.aspxhttp://sqlblog.com/blogs/linchi_shea/commentrss.aspx?PostID=3303<P>There has been much discussion on the usefulness of disk queue length as an indicator of a disk I/O bottleneck. Bob Dorr, for instance, addressed this issue directly in his excellent blog, <A style="TEXT-DECORATION:none;" href="http://blogs.msdn.com/psssql/archive/2007/02/21/sql-server-urban-legends-discussed.aspx"><FONT color=#000080>SQL Server Urban Legends Discussed</FONT></A>. But the issue is not settled for many since we still frequently see people using disk queue length as the key measure in analyzing disk I/O traffic, and still frequently get disk queue length related questions.</P>
<P>Hopefully, some concrete empirical data should help add clarity to the point that disk queue length &gt; 2&nbsp;may not indicate a problem and there are more useful disk I/O counters (e.g. I/O latency and I/O block size).</P>
<P>The following chart shows the data points taken on a real disk I/O path when 8K random reads are applied. The X-axis units are the disk queue length. The Y axis on the left represents I/Os per second, and the Y axis on the right represents I/O latency.</P>
<P><IMG src="http://sqlblog.com/blogs/linchi_shea/attachment/3303.ashx"> </P>
<P>Clearly, there is no disk I/O bottleneck when the queue length is at 2, 8, 16, or arguably even 32. Why? Because when the queue length is controlled at 2, 8, or 16, the I/O latency is relatively small (&lt; 10ms) and because the I/O path still has room to handle higher load to achieve higher I/Os per second. </P>
<P>Perhaps, that's because there are 8 or more spindles behind the I/O path. Maybe. But the beauty of&nbsp;using the I/O latency counter together with the I/O block size measure is that you don't really have to know how many spindles are there behind the scene in order to accurately assess whether the I/O path is overloaded or not. So for small block-sized I/Os such as 8K random reads, you generally want the latency to be below or around 10ms, and you can get these data points directly from their respective counters without requiring any additional info. </P>
<P>The problem with having to know the number of spindles before making use of the disk queue length counter is that many times you may not know how many spindles are there or it may take time to get to that info. This is often the case with more advanced&nbsp;I/O subsystems such as a high-end disk array behind a SAN.</P><img src="http://sqlblog.com/aggbug.aspx?PostID=3303" width="1" height="1">Best PracticesQueuesStorage