Tag Archives: queue depth

VMware: “adaptive queue depth” setting

What is the recommended LUN queue depth throttling in VMware ESX/ESXi?

According to EMC this “adaptive queue depth” setting is not yet supported (June 2013). The full article can be found on this link. It is known as Primus solution id emc279718.

My advice would be not to use this setting until EMC certifies this setting for use with their arrays.

The exact Article is as follows:

What is the recommended LUN queue depth throttling in VMware ESX/ESXi?
  • Need to know QFullThreshold,QFullSampleSize & Queue Fulls values for VMware.
  • Host Connectivity Guide does not include any standard values.
  • Performance issues.
OS: VMware ESX / ESXi
Product: CLARiiON / Symmetrix and I assume VNX as well
According to Engineering, enabling the adaptive queue depth algorithm is NOT documented in the Host Connectivity Guide or the EMC Support Matrix.
The recommendation is to use the default setting which is disable adaptive queue depth.
Additional checks with E-Lab VMware quality engineers, E-Lab testing is done with the default setting.
See emc274169 for additional information and or changes.  Also see these two documents on support pages support.emc.com or Powerlink.Using EMC VNX Storage with VMware VsphereUsing EMC Clariion Storage with Vmware Vsphere & VMware Infracture Version 4.0

Setting the queue depth or Execution throttle parameters – Clariion / VNX

Each FC storage array port has a maximum queue depth of 2048. For performance reasons we’ll have to do the math with 1600. Suppose a large number of HBAs (initiators) are generating IOs, a specific port queue can fill up to the maximum. The host’s HBA will notice this by getting queue full (QFULL) messages and very poor response times. It depends on the Operating system how this is dealt with. Older OSs could loose access to it’s drives or even freeze or get a blue screen. Modern OSs will throttle IOs down to a minimum to get rid of this inconvenience. VMware ESX for example decreases it’s LUN queue depth down to 1. When the number of queue full messages disappear, ESX will increase the queue depth a bit until it’s back at the configured value. This could take up to around a minute.
During the QFULL events the hosts may experience some timeouts, even if the overall performance of the CLARiiON is OK. The response to a QFULL is HBA dependent, but it typically results in a suspension of activity for more than one second. Though rare, this can have serious consequences on throughput if this happens repeatedly.

Read more »