3 Replies Latest reply on Jul 28, 2008 7:03 PM by aLTeReGo

    Avg Disk Queue Length

    BryanBecker

      I've been working with support the past few days since my upgrade to V9.  My system is pretty fast...some spots are slower than others.  They looked at the Db server and noticed the Avg. Disk Queue Length was very high.  Mine is reporting between 380-420.  Everything I read anything over 2 is bad....so this must be really bad.

      My DB is on a shared SQL server with other DBs attached to a SAN.  Before I go to the server/SQL admin team I just want to make sure this indeed is a very bad thing.

      BB

        • Re: Avg Disk Queue Length
          tdanner

          Yes, that's not good. We've seen issues with some other customers using SQL on a SAN. Their SAN was tuned for read performance, not large numbers of writes. But Orion's data access pattern (probably the access pattern for any normal database-backed polling engine) is lots of small writes. I don't know whether that's what's going on with your system, but it might be something to ask your DBAs about.

            • Re: Avg Disk Queue Length
              BryanBecker
              I'll have them look at it.....they did come back to say "Just thought of something -- I have read other documentation on performance -- the average disk queue is not an accurate measure of disk performance with SAN units.  A better metric is average sec /read, avg sec / write, avg sec / transfer. "

              BB
                • Re: Avg Disk Queue Length
                  aLTeReGo

                  I have read other documentation on performance -- the average disk queue is not an accurate measure of disk performance with SAN units.


                  Yes and no. It all depends on where these statistics are coming from. I'm not sure what kind of SAN you have, but we run EMC. It's true that Windows is incapable of accurately reporting the average queued I/O read/write statistics since it's not the Windows server itself that's writing the information out to the disk. That's the job of the service processor. If you're operating in a SAN environment you'll want to use a tool like NaviAnalyzer to dig deep into the problem. This will accurately tell you what your queued I/O and read/write cache hit ratios are. Only then will you be able to determine where your disk I/O problems lie.


                  As a side note, if you are running an EMC SAN and have PowerPath installed on your database server (which is required for dual attached HBAs) then PowerPath will provide you with accurate I/O statistics.  


                  The most common SAN related performance issues are usually poor selection of RAID level. Raid 0+1 Raid 10 is your best choice when dealing with high I/O operations like databases. The second most common source of issues is not enough spindles (physical disks) to handle the number of I/Os that need processing. You may not need the additional disk capacity but adding additional spindles is a sure fire way to increase read/write performance. Lastly, optimizing your read/write cache for the type of systems that you're running. This is what Tim Danner what eluding to in his post. Most environments optimize read performance because users more frequently access data (read) then write, so a larger read cache makes perfect sense. This however is not the case with Orion, which writes more data then it reads.


                  Hope this helps.