В этой статье я расскажу, как искать иголку в стоге сена причину проблем с производительностью ВМ на ESXi. Главным способом будет то, что так не любят многие администраторы: планомерная проверка всех ресурсов на утилизацию, сатурацию и ошибки. Я приведу ключевые метрики, на которые следует обратить внимание, их краткое описание и значения, на которые можно ориентироваться, как на норму. При этом важно понимать, что разные системы имеют разные требования к производительности. Следовательно, то, что приемлемо для одной системы, для другой может являться признаком аварийного состояния.

Кроме своих наработок, я также использовал материалы из разных англоязычных источников. По некоторым вопросам описания тянули на отдельные статьи, поэтому на них я дал ссылки.

Нашим первым шагом должна быть быстрая базовая проверка основных параметров – ее сценарий я опишу в начале статьи. Если базовая проверка не нашла причины проблем, то, скорее всего, укажет направление, в котором мы запустим расширенную проверку. В любом случае, более глубокая расширенная проверка всех доступных параметров поможет в итоге найти корень проблем. С этим обнадеживающим фактом давайте приступим. Напомню, что проверяемые параметры стоит фиксировать скриншотами.

Выясняем симптомы проблемы

Вот краткий список ключевых вопросов, на которые нужно ответить:

1. Как проявляются проблемы производительности? Описываем словами, снимками, прикладываем графики.

2. Когда работало хорошо и когда начало работать плохо? Вспоминаем даты и время.

3. Были ли какие-то аппаратные, программные или нагрузочные изменения?

4. Охватывает ли проблема другие системы или только одну, например: ВМ, vApp, группу ВМ, кластер, группу кластеров и т. д.

Часть 1. Базовая проверка

Цель базовой проверки – быстро выяснить направление, в котором находится источник проблем производительности. Учитывайте, что графики в vSphereClient усредняют значения со временем, и лучше собирать максимум информации в любую стороннюю систему мониторинга (Prometeus, Zabbix, VMware vRealize Operation Manager и т. д.). Если такой системы нет, то воспроизводим проблему в реальном времени и наблюдаем за ней со стороны гипервизора. По результатам базовой проверки решаем, нужно ли дальнейшее расследование.

Проверяем ВМ из vSphereClient

1. Triggered Alarms, Tasks и Events не должны содержать событий, коррелирующих с проблемой.

2. CPU:

   1. Usage не должен превышать 90%.

      Usage – процент активно задействованных мощностей виртуальных CPU. Это среднее значение загруженности CPU в виртуальной машине. Например, если виртуальная машина с одним виртуальным CPU работает на хосте, имеющем четыре физических CPU, и Usage виртуального CPU составляет 100%, то виртуальная машина полностью использует один физический CPU.

      Usage виртуального CPU = usagemhz / кол-во виртуальных CPUx (частота ядра).

   2. Ready не должен превышать 10% на ядро.

      Ready показывает время, в течение которого виртуальная машина была готова к использованию, но не могла быть запущена на физическом CPU из-за нехватки ресурсов. Ready % зависит от количества виртуальных машин на хосте и загруженности их CPU.

3. Memory:

   1. Ballooned должен быть равен 0.

      Этот параметр указывает на объем памяти, захваченной драйвером управления памятью ВМ (vmmemctl), который установлен в гостевую ОС вместе с VMwareTools. Данный объем перераспределяется от ВМ к гипервизору в условиях её нехватки. То же самое происходит, когда неверно выставлен MemoryLimit на ВМ или ресурсный пул – это тоже ухудшает производительность ВМ.

   2. Swapped должен быть равен 0.

      Это текущий объем гостевой физической памяти, которую  VMKernel выгрузил в файл подкачки ВМ. Выгруженная память остается на диске до тех пор, пока она не понадобится ВМ, либо пока не будет запущен принудительный механизм unswap. Подробнее расписано тут.

4. Virtual Disk:

   1. Нормально, если отсутствуют мгновенные снимки старше 24 часов.

   2. Highest latency не должен превышать приемлемых для приложения значений.

      Это наибольшее значение задержки среди всех дисков, используемых ВМ. Измеряет время, необходимое для обработки команды SCSI, которое гостевая ОС предоставила виртуальной машине. Задержка ядра – это время, которое требуется VMKernel для обработки запроса ввода/вывода. Задержка устройства – это время, которое требуется оборудованию для обработки запроса.

      Есть прямая зависимость от размера блока ввода/вывода (Write request size и Read request size) с временем задержки, за которое этот блок будет обработан подсистемой хранения.

   3. Write request size и Read request size не должны коррелировать с Highest latency.

      Важным нюансом этой метрики является то, что vSphere не отображает размеры блока более 512 КБ: вы увидите рост задержек вследствие роста размера блока выше 512 КБ, но при этом не будете видеть рост размера самого блока. Увидеть его можно только через утилиту хоста ESXi vscsiStats.

      Подробнее о vscsiStats здесь.

      Здесь можно превратить вывод команды в гистограмму.

   4. Average commands issued per second не должен превышать IOPS Limit.

   5. Commands aborted и Bus resets должны равняться 0.

5. Network:

   1. Usage не должен достигать предела (vmnic хоста, политик коммутирующего оборудования или маршрутизатора).

      Этот параметр отображает объем данных, переданных и полученных всеми виртуальными сетевыми картами, подключенными к виртуальной машине.

   2. Receive packets dropped и Transmit packets dropped должен равняться 0.

   3. Packets received и Packets transmitted не должны содержать скачков, коррелирующих с проблемой в разбивке по типам Broadcast, Unicast и Multicast.

Проверяем хост из vSphereClient

1. Triggered Alarms, Tasks и Events не должны содержать событий, коррелирующих с проблемой.

2. CPU:

   1. Usage по всему хосту не должен превышать 80%.

   2. Ready не должен превышать 10% на ядро (как перевести из summation в проценты подробно читайте тут).

3. Memory:

   1. Balloned должен равняться 0.

      Это сумма значений vmmemctl для всех включенных ВМ и служб vSphere на хосте. Если целевой размер balloon (дословно переводится как «шар») больше, чем текущий,  VMKernel «раздувает» balloon внутри ВМ, в результате чего освобождается больше памяти хоста. Если целевой размер balloon меньше, чем текущий,  VMKernel «сдувает» balloon, что позволяет процессам внутри ВМ при необходимости использовать больше памяти. Подробнее про ballooning тут.

   2. Swap consumed должен быть равен 0.

      Это объем памяти, которая используется для подкачки всех включенных ВМ и служб vSphere на хосте.

   3. Page-fault latency должно равняться 0.

      Это время ожидания виртуальной машиной доступа к сжатой памяти или файлу подкачки.

   4. Storage adapter.

   1. Write rate и Read rate не должны превышать пропускную способность vmhba, коммутирующего оборудования до хранилища или пропускной способности хранилища.

   2. Write latency и Read latency должны примерно равняться по всем активным vmhba.

      Если какая-то из vmhba сильно выбивается по задержкам или нагрузке, то следует удостовериться, что политика мультипасинга выставлена корректно. Подробнее о политиках тут. Большинство современных хранилищ позволяют применять политику Round Robin. После проверки политики стоит обратить внимание на качество соединения.

   5. Network:

   1. Usage не должен превышать пределов vmnic

      Это суммарный объем данных, которые передают и получают все физические сетевые карты, подключенные к хосту.

   2. Receive packets dropped и Transmit packets dropped должны равняться 0.

   3. Packets received и Packets transmitted не должны содержать скачков, коррелирующих с проблемой в разбивке по типам Broadcast, Unicast и Multicast.

Часть 2. Расширенная проверка

Если результаты базовой проверки не указали на главную причину проблем с производительностью, делаем расширенную проверку.

Проверяем ВМ и хост

Здесь большая часть метрик берется из утилиты хоста ESXiesxtop. Очень кстати вывод esxtop можно записывать в csv-файл. Формат csv позволяет открыть его, к примеру, в PerfMon на Windows и проанализировать не только мгновенные значения, но и их изменение во времени.

Запись одной тысячи точек с шагом раз в две секунды можно выполнить так:

esxtop -a -b -d 2 -n 1000 > esxtop-output.csv.

1. Должны отсутствовать ошибки в vmware.log ВМ, VMKernel.log хоста и во внешних системах журналирования по объектам, релевантным проблеме.

2. CPU esxtop:

   1. CPU loadaverage не должен превышать 1.

      Это среднее арифметическое значение загрузки CPU за 1 минуту, 5 минут и 15 минут, основанное на 6-секундных выборках.

   2. %USED не должен превышать 90 на ядро.

      Это процент физического процессорного времени, приходящийся на world. В эту величину входит метрика %RUN, обозначающая процент времени, когда world вычислялся на физическом CPU. Дополнительно сюда засчитывается %SYS, обозначающая процент времени, при котором VMKernel обрабатывал прерывания и выполнял иные системные действия для данного world. Метрика же %OVRLP вычитается из данной и отражает процент времени, которое world провел в очереди на выполнение, ожидая завершения системных действий в отношении других world.

      %USED = %RUN + %SYS - %OVRLP.

   3. %RDY не должен превышать 10.

      Это процент времени, в течение которого world был готов к запуску.

      Поясню: world, который стоит в очереди, ожидает, пока планировщик разрешит ему запуск на физическом CPU. %RDY – процент от этого времени, поэтому он всегда меньше 100%.

      Если в настройках ресурсов ВМ установлен CPULimit, то планировщик не станет размещать ВМ на физическом CPU, когда она израсходует выделенный ей ресурс CPU. Это может произойти даже при наличии большого количества свободных тактов CPU. Время, в течение которого планировщик намеренно удерживает ВМ, отображается в параметре %MLMTD, который мы опишем дальше. Обратите внимание, что параметр %RDY включает в себя %MLMTD. Для определения задержки процессора мы будем использовать формулу: %RDY – %MLMTD. Поэтому, если показатель %RDY – %MLMTD высокий, например больше 10%, вы можете столкнуться с проблемой нехватки мощностей CPU.

      Рекомендуемый порог зависит от обстоятельств. Для пробы можно начать с 10%. Если скорость работы приложения в ВМ в порядке, то оставьте порог как есть. В противном случае – снизьте порог.

      Закономерный вопрос: а что составляет 100% времени?

      World может находиться в разных состояниях: он запланирован к запуску, готов к запуску, но не запланирован, или не готов к запуску, то есть ожидает какое-либо событие.

      100% = %RUN + %RDY + %CSTP + %WAIT.

   4. %CSTP не должен превышать 3.

      Это процент времени, в течение которого world находится в состоянии co-schedule. Состояние co-schedule применимj только для многопроцессорных виртуальных машин. Планировщик CPU ESXi намеренно переводит виртуальный CPU в это состояние, если этот виртуальный CPUопережает в вычислениях другие виртуальные CPU данной ВМ.

      Высокий показатель %CSTP означает, что ВМ неравномерно использует виртуальные CPU. Приложение использует CPU с высоким %CSTP внутри ВМ гораздо чаще, чем остальные её CPU.

   5. %MLMTD должен равняться 0.

      Это процент времени, в течение которого world был готов к запуску, но не запущен планировщиком из-за настроек CPULimit.

      Обратите внимание, что параметр %MLMTD уже учтен в расчете %RDY. Показатель %MLMTD высок, когда ВМ не может быть запущена из-за настройки CPULimit. Если вы хотите повысить производительность этой ВМ, то увеличьте этот лимит. В целом, использование CPULimit не рекомендуется.

   6. %SWPWT должен равняться 0.

      Это процент времени, в течение которого world ожидает, пока VMKernel завершит подкачку памяти. Время %SWPWT (ожидание подкачки) включено в %WAIT.

3. Memory esxtop:

   1. Memory хоста в состоянии High. Про memory state подробно написано здесь.

   2. MCTLSZ должен равняться 0.

      Это объем гостевой физической памяти, перераспределенной balloon-драйвером.

      Высокий показатель MCTLSZ означает, что много гостевой физической памяти этой виртуальной машины «украдено», чтобы уменьшить нагрузку на память хоста. Сам по себе высокий показатель MCTLSZ не говорит о проблеме, поскольку balloon-драйвер старается разумно «красть» гостевую физическую память, чтобы не вызывать проблем с производительностью.

      Как тогда узнать, что виртуальная машина работает в режиме ballooning? Если показатель MCTLSZ изменяется, balloon-драйвер активно освобождает память хоста, раздувая «шар памяти» в ВМ. Скорость ballooning в краткосрочной перспективе можно оценить по изменению MCTLSZ в какую-либо сторону.

      Если после ballooning рабочий набор гостевой памяти меньше, чем физическая память гостя, то на производительность гостевых приложений это не повлияет. В противном случае, это может вынудить гостевую ОС задействовать подкачку и снизить производительность гостевых приложений.

      Если вы заметили проблемы с производительностью, проверьте причину ballooning и примите соответствующие меры для снижения нагрузки на память. Есть две возможные причины ballooning:

      1. Хосту недостаточно памяти для работы.

      2. ВМ достигла лимита задействованной памяти, который установлен в параметре MemoryLimit ВМ, или лимита пула ресурсов, в котором ВМ находится.

         В любом из этих случаев ballooning необходим и предпочтительнее подкачки.

   3. SWCUR должно равняться 0.

      Это общее количество мегабайт подкачки, которые используются в файле vswp ВМ или в системном файле подкачки, а также миграционном файле подкачки. ВМ в состоянии vMotion использует миграционный файл подкачки для удержания выгруженной памяти на целевом узле, если целевому узлу не хватает памяти.

      Для ВМ это текущий объем гостевой физической памяти, выгруженной в зарезервированное хранилище. Обратите внимание, что эта статистика относится к своппингу VMKernel, а не к своппингу гостевой ОС внутри ВМ.

      Высокий показатель SWCUR у ВМ означает, что гостевая физическая память ВМ находится не в оперативной памяти, а на диске. Если в ближайшем будущем эта память не будет использоваться, то проблем нет. В противном случае, гостевая система начнет подкачивать память с диска, что может снизить производительность ВМ.

   4. SWR/s и SWW/s должны равняться 0.

      SWR/s – это скорость, с которой память подкачивается с диска. Обратите внимание, что эта статистика относится к своппингу VMKernel, а не к своппингу гостевой ОС внутри ВМ.

      Высокий показатель SWR/s означает проблему с производительностью ВМ. Поскольку операция swap-in является синхронной, ВМ необходимо подождать, пока запрошенные страницы будут считаны в память ВМ. Это происходит, когда VMKernel сначала выгрузил память ВМ, а теперь она снова нужна ВМ.

      SWW/s – это скорость, с которой память выгружается на диск. Обратите внимание, что эта статистика также относится к своппингу VMKernel, а не к своппингу гостевой ОС.

      Это может произойти в двух случаях:

      1. Хосту недостаточно памяти для работы.

      2. ВМ достигла лимита задействованной памяти, который установлен в параметре MemoryLimit ВМ, или лимита пула ресурсов, в котором ВМ находится.

      Высокий показатель SWW/s также означает проблему с производительностью ВМ.

   5. N%L должен быть больше 80.

      Это процент объема виртуальной памяти ВМ, который находится в локальной для её виртуальных CPU NUMA Node. Низкий процент N%L означает, что, с высокой вероятностью, какие-то запросы виртуальных процессоров ВМ используют данные оперативной памяти ВМ через межпроцессорное соединение.

      Подробнее об этом можно почитать в цикле статей от Frank Denneman.

   6. В IPMI хоста журналы не должны содержать ошибок ОЗУ.

4. Disk ВМ esxtop:

   1. LAT/rd и LAT/wr не должны превышать приемлемых для приложения значений.

   2. CMDS/s не должен достигать IOPSLimit.

   3. MBREAD/s + MBWRTN/s не должен достигать пределов vmhba.

5. Disk Adapter esxtop:

   1. QAVG/cmd должно быть около 0 и не превышать KAVG/cmd.

      Это среднее время ожидания в очереди.

      QAVG должен входить в KAVG, как показано на рисунке. Но при проблемах с физическим устройством или соединительными линиями QAVG может превышать KAVG. Если показатель QAVG высокий, то следует обратить внимание на глубину очередей на каждом уровне стека хранения.

   2. GAVG/cmd, KAVG/cmd и DAVG/cmd не должны превышать приемлемые значения для данного хранилища данных.

      GAVG – это круговая задержка для всех запросов ввода/вывода, которые гостевая система отправляет на виртуальное устройство хранения. Параметр GAVG = KAVG + DAVG.

      KAVG – этот параметр отслеживает задержки, связанные с работой VMKernel.

      Значение KAVG должно быть намного меньше значения DAVG и близко к нулю. Когда в ESXi много очередей, KAVG может быть таким же высоким или даже выше, чем DAVG. Если это произошло, проверьте статистику очередей и лимиты политики хранения или виртуального диска.

      DAVG – это задержка, наблюдаемая на уровне драйвера устройства. Она включает в себя время приема-передачи между HBA и хранилищем.

      DAVG – хороший индикатор производительности хранилища. Если есть подозрения, что задержки ввода/вывода являются причиной проблем с производительностью, то следует проверить DAVG. Сравните задержки ввода/вывода с соответствующими данными из массива. Если они сходятся, проверьте массив на предмет неправильной конфигурации или неисправностей. Если нет, то сравните DAVG с соответствующими данными из точек между массивом и сервером ESXi, например, FC-коммутаторов. Если эти промежуточные данные также совпадают со значениями DAVG, вероятно, приложению не хватает ресурсов для корректной работы в этом хранилище. В таких случаях может помочь добавление накопителей или изменение уровня RAID.

   3. MBREAD/s + MBWRTN/s не должно достигать пределов vmhba.

   4. FCMDS/s, ABRTS/s, RESETS/s должно равняться 0.

      FCMDS/s – это количество команд в секунду, завершившихся ошибкой. Может указывать на проблемы с контроллером хранения, состоянием соединения до хранилища или непосредственно с хранилищем.

      ABRTS/s – это количество прерванных команд в секунду. Параметр может указывать на то, что система хранения данных не удовлетворяет требованиям гостевой ОС. Гостевая система прерывает обработку команды, если хранилище не отвечает в течение приемлемого времени (может быть настроено в гостевой ОС, в том числе и в результате установки VMwareTools). Кроме того, гостевая ОС может прервать все команды, выполняемые на ее виртуальном SCSI-адаптере.

      RESETS/s – это количество сброшенных команд в секунду. Указывает на число отброшенных команд в результате сброса состояния адаптера. Сброс может быть вызван драйвером как реакция на какие-либо события в сети хранения данных.

6. FC:

   1. Вывод команды esxcli storage san fc stats get не должен содержать ошибок.

   2. Мониторинг портов сети хранения данных не должен содержать ошибок.

7. Diskdevice:

   1. QAVG/cmd должно быть около 0 и не превышать KAVG/cmd.

   2. KAVG/cmd должно быть около 0.

   3. DAVG/cmd, GAVG/cmd не должны превышать приемлемых для приложения значений.

   4. DQLEN должен быть более 32 (кроме устройств USB и CDROM).

      Глубина очереди (queue depth) – одна из ключевых характеристик подсистемы ввода/вывода, особенно в виртуализации, где требуется высокий параллелизм операций. Глубина очереди определяет число команд ввода/вывода, которые подсистема может осуществлять одновременно. На глубину очереди влияют протоколы, аппаратные возможности устройств, прошивки и драйверы.

      Регулируется, как минимум, в следующих местах:

      • в драйвере HBA глобально на хост: подробнее

      • на каждом LUN есть два параметра: подробнее

        1. Device Max Queue Depth наследуется от Queue Depth драйвера HBA (предыдущий шаг). Однако может быть занижено такими технологиями, как SIOCv1 (включается в vSphere Client на Datastore) и Adaptive Queue Depth (подробнее тут), которая включается расширенными настройками QFullSampleSize и QFullThreshold.

        2. No of outstanding IOs with competing worlds (DSNRO) по умолчанию равняется 32. Это глубина очереди к LUN, если с ним одновременно работают более одной ВМ.

      • на контроллере и диске ВМ: подробнее.

   Важно: если параллелизм операций с хостов ESXi превысит допустимый параллелизм нижележащих HBA, SAN или СХД, то есть совокупная глубина очереди выполняемых в настоящий момент операций ВМ превысит глубину очереди инфраструктуры, то хост будет получать SCSI-примитивы QFULL или BUSY, и в журнале VMKernel.log будут регистрироваться такие события:

   • H:0x0 D:0x28 P:0x0 Valid sense data: 0x## 0x## 0x##

   • H:0x0 D:0x08 P:0x0 Valid sense data: 0x## 0x## 0x##

   • H:0x0 D:0x8 P:0x0 Valid sense data: 0x## 0x## 0x## 

   5. QUED должно равняться 0.

      Это количество команд VMKernel, которые находятся в очереди. Статистика применима только к world и LUN.

      Большое количество команд в очереди может быть признаком того, что система хранения перегружена. Постоянно высокое значение счетчика QUED сигнализирует об узком месте (bottleneck, дословно – «бутылочное горлышко») в системе хранения, которое в некоторых случаях можно устранить, увеличив глубину очереди. После увеличения глубины очереди проверьте, что LOAD меньше 1. Это должно увеличить количество обработанных команд в секунду и повысить производительность.

   6. %USD не должно превышать 60.

      Это процент глубины очереди, используемой активными командами VMKernel. Эта статистика применима только к world и LUN.

      %USD = ACTV / QLEN × 100%.

      Чтобы рассчитать статистику по world, в качестве знаменателя используйте WQLEN. Для статистики LUN (устройства) в качестве знаменателя используйте LQLEN.

      %USD показывает, сколько доступных слотов очереди команд задействованы. Высокие значения говорят о возможности образования очередей. Тогда вам потребуется настроить глубину очередей для HBA, если QUED также постоянно больше 1. Размеры очередей можно настроить в нескольких местах на пути ввода/вывода. Это помогает смягчить проблемы с производительностью, вызванные большими задержками.

   7. FCMDS/s, ABRTS/s, RESETS/s должны равняться 0.

   8. ATSF должно быть значительно меньше ATS.

      Примитив VAAI Atomic Test and Set позволяет ускорить ряд операций с подсистемой хранения. Ниже приведены две статьи, подробно объясняющие каждую операцию. Множество неудавшихся операций ATS могут стать причиной проблем в работе подсистемы хранения.

      Про ATS heartbeat: подробнее.

      Про ATS lock: подробнее.

   9. Политика мультипасинга должна быть рекомендована вендором СХД.

   10. No of outstanding IOs with competing worlds (DSNRO) должно равняться Queue Depth.

8. Network esxtop:

   1. MbTX/s, MbRX/s не должны превышать vmnic.

      Это мегабиты, передаваемые (MbTX) или принимаемые (MbRX) в секунду.

      В зависимости от рабочей нагрузки MbRX/s может не совпадать с PKTRX/s, потому что размер пакетов может быть разным. Средний размер пакета можно рассчитать по формуле: средний размер пакета = MbRX/s / PKTRX/s. Увеличение размера пакетов может повысить эффективность обработки пакетов процессором. Однако потенциально это также может увеличить задержку.

   2. %DRPTX, %DRPRX должны равняться 0.

      %DRPTX – это процент потерянных исходящих пакетов.

      %DRPTX = потерянные исходящие пакеты / (успешно отправленные исходящие пакеты + потерянные исходящие пакеты).

      Высокое значение %DRPTX обычно указывает на проблемы с отправкой данных. Проверьте, полностью ли используются возможности физических сетевых карт. Возможно, нужно заменить сетевые карты на карты с лучшей производительностью. Или вы можете подключить еще несколько сетевых карт и настроить политику балансировки нагрузки, чтобы равномерно распределить нагрузку по всем картам.

      %DRPRX – это процент потерянных входящих пакетов. Вычисляется по формуле: %DRPRX = потерянные входящие пакеты / (успешные принятые входящие пакеты + потерянные входящие пакеты).

      Высокое значение %DRPRX обычно указывает на проблемы с приемом входящего трафика. Стоит выделить больше ресурсов CPU для затронутой ВМ или увеличить размер ringbuffer.

9. Network:

   1. Вывод команды esxclinetworknicstatsget -n vmnicX не должен содержать ошибок.

   2. Статистика релевантных портов vsish не должна содержать ошибок и дропов.

      Бывает так, что ВМ испытывает резкие скачки входящего трафика, способные переполнить RxRingBuffers. Расследовать такие ситуации можно, выяснив PORT-ID сетевой карточки ВМ через раздел network утилиты esxtop или командой esxclinetworkvmlist -> посмотреть World ID нужной ВМ ->esxclinetworkvmportlist -w <World ID>.

      Затем в vsish:

      cd /net/portsets/<vSwitch-NAME>/ports/<PORT-ID>/

      cat stats

      packet stats {

         pktsTx:823080899

      pktsTxMulticast:18571

         pktsTxBroadcast:1908

      pktsRx:961804917

         pktsRxMulticast:48602

         pktsRxBroadcast:1947286

         droppedTx:0

         droppedRx:27314

      }

      Ненулевое значение droppedRx может означать превышение Rx Ring Buffers. Расследуем дальше:

      cd /net/portsets/vSwitch0/ports/<PORT-ID>/vmxnet3

      cat rxSummary

      stats of a vmxnet3 vNICrx queue {

         ...

         1st ring size:1024

         2nd ring size:64

         # of times the 1st ring is full:349

         # of times the 2nd ring is full:0

      ...

      }

      Здесь мы видим размеры ring buffers и сколько раз они были переполнены. Ненулевое значение – хороший повод увеличить ring size. Там же есть директория rxqueues, в которой может быть одна или более поддиректорий. Если включена NetQueue или RSS, то в данных директориях можно посмотреть статистику каждой очереди по отдельности.

   3. Вывод команды arp-scan подсети не должен содержать дубликатов IP и MAC-адресов.

   4. Запись трафика в момент воспроизведения проблемы не должна содержать аномалий. Об этом подробнее тут.

      ***

      В этой статье был приведен список ключевых точек для исследования при поиске проблем с производительностью ВМ и их краткое описание. Если требуется более глубокое погружение в материал, то рекомендую обратиться к циклу наших прошлых статей по данной теме:

      Часть 1. CPU.

      Часть 2. Memory

      Часть 3. Storage

      На этом я завершаю описание сценария поиска проблем с производительностью ВМ на ESXi. Буду рад обсудить нюансы и ответить на вопросы.