SIOC and Adaptive Queue Depth testing on iSCSI LUNs
This is a guest post by Andy Grant.
This is a continuation of the post Some Answers About Queues: LUN and HBA Queue Depth on ESX(i) Hosts.
Questions arose about conflicting support statements for Storage IO Control and in an effort to further the investigation, I have performed additional testing on an iSCSI LUN.
I will keep this short and sweet and let you draw your own conclusion.
My test configuration includes two ESX 4.1U1 hosts, 3 WinXP VM's sharing a single iSCSI LUN provided by an HP P4000 VSA. Each VM was running IOMeter v1.1-RC1 performing a 4K, 100% sequential read with 128 outstanding IO.
For a baseline metric, here are the queue stats for the LUN at idle.
Starting the IOMeter load with SIOC disabled and the default Disk.SchedNumReqOutstanding of 32.
Because I tested using only 3 VM's across two hosts, we can observe the behavior noted by Jason Boche in his comment in the original post. The esxtop window on the left is the host with two VM's and the window on the right with one VM. Notice that only the host on the left is throttled down to the Disk.SchedNumReqOutstanding parameter.
Now I enable SIOC on the same load.
The behavior of SIOC is following in the footsteps of my local disk testing. The per-LUN queue (DQLEN) has increased above Disk.SchedNumReqOutstanding (DSNRO).
Due-diligence dictates that I repeat the Adaptive Queue Depth testing as well with SIOC disabled. In my previous local disk testing I did not observe any behavioral difference with this feature enabled.
SIOC disabled and Adaptive Queue Depth (QFull) parameters adjusted.
The results of enabling the Adaptive Queue Depth algorithm differ from my previous local disk testing. Observe the “SIOC-like” behavior when using an iSCSI LUN. I must clarify that the Adaptive Queue Depth algorithm is not a replacement for the slot-based scheduling mechanism provided by SIOC based on VM disk shares.
Your feedback and comments are welcome.
Hi,
what is Disk.QFullthreshold value.