Most of you hopefully read about the new queue depth throttling feature in the release notes of ESX 3.5 U4 which has been released last week. A couple of customers asked me if this would be beneficial for them to set up.
Currently queue depth throttling is only supported for 3PAR Storage Arrays.
This, of course, doesn’t mean that it will not work with any of the other arrays. It actually does… but it probably hasn’t been tested to the full extent. Again, keep in mind that it’s currently not supported with any other array then 3PAR.
Now, what’s this queue depth throttling about? The knowledge base article actually has a good explanation of what it does:
VMware ESX 3.5 Update 4 introduces an adaptive queue depth algorithm that adjusts the LUN queue depth in the VMkernel I/O stack. This algorithm is activated when the storage array indicates I/O congestion by returning a BUSY or QUEUE FULL status. These status codes may indicate congestion at the LUN level or at the port (or ports) on the array. When congestion is detected,VMkernel throttles the LUN queue depth. VMkernel attempts to gradually restore the queue depth when congestion conditions subside.
In laymans terms: It’s an “algorithm” for handling queue sizes. When the array indicates it’s busy and/or that the queue is full it cuts the size of the queue in half so the array isn’t flooded with requests and can recover to a normal situation. When the array gives the green light the size of the queue will be increased again till the max specified queue depth has been reached.
Especially helpfull in situation where you loose 2 out of 4 paths to your luns, for example because off a FC-switch failure.
Your infrastructure can normally cope with the loss of a FC-switch, with this queue depth throttling so will your controllerports on your array.
Does anyone know if the IBM DS8000 series also support queue depth throttling ? and if yes what the recommended values for the Disk.QFull settings are ?