Глубина очереди

Queuedepth, ее влияние на производительность и как поменять.
Суть:
Сервер посылает на СХД команды. Когда все хорошо, команда пришла - и исполнилась, СХД что то прочитала\записала. Если в какие то пиковые моменты СХД перестает справляться с запросами, то они становятся в очередь.
Небольшой нюанс виртуализации:
По пути от приложения, которое запросы посылает, до дисков, которые их обрабатывают, разных очередей много. Это очередь в гостевой ОС, в гипервизоре, на hba, на СХД...
Поэтому, в частности, вопрос производительности дисковой подсистемы и тонкого тюнинга так не прост.

Так вот, конкретные примеры, как определить узкое место, если оно в очереди команд гипервизора к ЛУНу:
запустить esxtop в Service Console(или resxtop в RCLI для ESXi ). Нажать "d".
Углядеть примерно такую картинку:
Это данные по загрузке HBA. Объяснение того, что там видно.

Значение в столбце QUED слишком близко к значению ACTV - т.е. очередь команд полна. Гипервизор простаивает при обращении к диску, ожидая обработки стоящих в очереди команд.
Далее: посмотрим данные по ВМ, которые лежат на этом ЛУНе. Я пока не понял, как понять какие именно ЛУНы нам нужны. Все, которые доступны через этот HBA?
Запустили esxtop, нашли нужную ВМ, запомнили ее GID.

Нажали "e", вбили GID.
Увидели картинку:

Величина LOAD должна быть менее 1. Не нулевое значение QUED практически всегда означает затык, что СХД не справляется.
В такой ситуации может помочь увеличение глубины очереди со значения по умолчанию - 32, до 64.

vmkload_mod -l | grep qla
esxcfg-module -s ql2xmaxqdepth=64 qla2300_707
esxcfg-boot –b

Перезагрузим сервер.
Наша цель - чтобы картинка загрузки дисков стала походить на эту:


Источник - A look at the ESX I/O stack.
Кстати, интересный англоязычный блог по СХД, рекомендую - Storage Nuts & Bolts.