Примерно 2,5 года назад вышел документ по решению проблем с производительностью в VMware vSphere 4.1.

Так как актуальность документ все еще не потерял, я попробую осуществить его перевод…

В начале документа находится схема траблшутинга

Соответственно, есть две дальнейшие диаграммы: базовая и продвинутая.

Базовая.

Возможные проблемы упорядочены по принадлежности (с VMware Tools, CPU, etc) и по их влиянию (от 100% влияния на производительность до возможного).

Проверка VMware Tools.

• Выберите хост в vClient;
• Перейдите на вкладку Virtual Machines;
• Добавьте столбец “VMware Tools Status”;
• Оцените статус. OK->возвращаемся к диаграмме траблшутинга.  Not Running/Out of date – устраняем.

Если VMware Tools не запущены, необходимо разбираться с гостевой операционной системой. Причина может скрываться в обновлении ядра Linux либо отключенной (кем-то) службе VMware Tools в Windows.

Если VMware Tools устарели, необходимо их обновить из контекстного меню vClient. Как правило, это случается после установки обновлений на хосты ESX/ESXi. После этого зачастую требуется обновить и VMware Tools.

Проверка загрузки процессора в пуле ресурсов (Resource Pool CPU Saturation).

Если используете пулы ресурсов и лимит на процессорные ресурсы пула, то читайте дальше. В противном случае сразу идите в следующий блок Host CPU Saturation.

• Выберите пул ресурсов и перейдите на вкладку Performance, там переключитесь в режим “Advanced” и выберите объект “CPU”;
• Оцените текущую загрузку в MHz (Usage);
• Сравните значение лимита пула ресурсов и текущую загрузку. Если текущая загрузка близка к лимиту, возможно, имеет место нехватка процессорных ресурсов и вам необходимо оценить значение CPU Ready отдельных виртуальных машин в этом пуле;

Проверка CPU Ready:

• Для измерения CPU Ready выберите одну из виртуальных машин (далее ВМ) в пуле, перейдите на вкладку Performance, выберите режим “Advanced” и переключитесь в обзор “CPU” (если вы решаете проблему производительности определенной ВМ, начните с нее);
• Оцените значение Ready для всех “объектов” ВМ. Отдельным “объектом” является каждый виртуальный процессор ВМ. Вам будет необходимо изменить свойства графика “Chart Options…” для отображения этого графика;
• Среднее или максимальное значение Ready для любого виртуального процессора превышает 2000мс? Если да, то у вас наблюдается нехватка процессорных ресурсов из-за установленного лимита на пул ресурсов;
• Повторите для всех ВМ этого пула.

На следующем рисунке проиллюстрирован этот пример

Проверка загрузки процессора хоста (Host CPU Saturation).

• Выберите хост, перейдите на вкладку Performance, там переключитесь в режим “Advanced” и выберите объект “CPU”;
• Оцените текущую загрузку в MHz (Usage);
• Превышает ли средняя загрузка 75% или пиковая – 90%? Если да, возможно, вам не хватает процессорных ресурсов хоста. Проверьте CPU Ready у ВМ этого хоста как показано ниже. Если средняя загрузка ЦП не превышает 75%, перейдите к следующему блоку…

Проверка CPU Ready:

• Если вы решаете проблему производительности определенной ВМ, начните с нее. В противном случае выберите хост, перейдите на вкладку Virtual Machines, отсортируйте список по столбцу Host CPU – MHz и проверьте одну-две ВМ из начала списка;
• Для измерения CPU Ready выберите ВМ, перейдите на вкладку Performance, выберите режим Advanced и переключитесь в обзор “CPU” (если вы решаете проблему производительности определенной ВМ, начните с нее);
• Оцените значение Ready для всех “объектов” виртуальной машины. Отдельным “объектом” является каждый виртуальный процессор ВМ. Вам будет необходимо изменить свойства графика “Chart Options…” для отображения этого графика;
• Среднее или максимальное значение Ready для любого виртуального процессора превышает 2000мс? Если да, то у вас наблюдается нехватка процессорных ресурсов хоста.

Схему анализа данного раздела также можно посмотреть на следующем рисунке:

Загрузка процессора ВМ (Guest CPU Saturation).

• Выберите ВМ с проблемами по производительности, перейдите на вкладку Performance, выберите режим Advanced и переключитесь в обзор “CPU”;
• Оцените уровень загрузки ЦП ВМ;
• Превышает ли средняя загрузка 75% или пиковая – 90%? Если да, возможно, вам не хватает процессорных ресурсов.

Проверка ВМ на активное использование свопа (Active VM Memory Swapping).

Нехватка памяти хоста или пула ресурсов может повлечь за собой активное использование технологии Host Swap. А это в свою очередь резко снизит производительность как одной ВМ, так и нескольких “соседних”.

• Выберите хост, перейдите на вкладку Performance, там переключитесь в режим “Advanced” и выберите объект “Memory”. Необходимо будет добавить счетчики “Swap in rate” и “Swap out rate”.
• Оцените показатели “Swap in rate” и “Swap out rate”;
• Если значения счетчиков больше нуля, то у хоста имеются проблемы с памятью.

Также можно проверить это значение для конкретной ВМ хоста:

• Выберите хост, перейдите на вкладку Performance, там переключитесь в режим “Advanced” и выберите объект “Memory”;
• Измените свойства графика (Chart Options…);
• Выберите Memory/Real-Time, смените тип графика на Stacked Graph (per VM). Выберите все ВМ и счетчики “Swap in rate” и “Swap out rate” для них;
• Если значения счетчиков больше нуля, имеются проблемы с памятью.

Примечание: если хост является частью DRS-кластера, следует оценить также загрузку по памяти остальных хостов.

Проверка ВМ на использование свопа в прошлом (VM Swap Wait).

Нехватка памяти в прошлом может вызвать выгрузку страниц памяти ВМ на диск сервера (Host Swap). ESXi не осуществляет загрузку неиспользуемой ВМ памяти обратно в память хоста, поэтому вы можете сталкиваться с замедлением в работе ВМ, пока такие страницы будут прочитаны с диска.

• Выберите ВМ с проблемами по производительности, перейдите на вкладку Performance, выберите режим Advanced и переключитесь в обзор “CPU”;
• Оцените значение Swap Wait для ВМ. Его будет необходимо добавить в свойствах графика;
• Содержит ли последний столбец ненулевое значение (столбец average)? Если да, тормоза ВМ из-за свопа. Самое простое решение – перезагрузка ВМ. Если нет – возвращаемся к базовой диаграмме.

Проверка ВМ на “заархивированность” памяти (VM Memory Compression).

• Выберите хост, перейдите на вкладку Performance, там переключитесь в режим “Advanced” и выберите объект “Memory”;
• Оцените счетчики “Compression rate” и “Decompression rate”. Да, их придется добавить 🙂 ;
• Принимали ли эти счетчики значения выше 0? Если да, на хосте имелись проблемы с нехваткой памяти (да и сейчас, быть может, имеются). Если нет, возвращаемся к базовой диаграмме;

Также можно проверить “заархивированность” памяти у ВМ:

• Выберите хост, перейдите на вкладку Performance, там переключитесь в режим “Advanced” и выберите объект “Memory”;
• Измените свойства графика (Chart Options…);
• Выберите Memory/Real-Time, смените тип графика на Stacked Graph (per VM). Выберите все ВМ и счетчики “Compression rate” и “Decompression rate” для них;
• Ненулевые значения будут свидетельствовать о нехватке памяти.

Примечание: если ВМ находится в пуле ресурсов DRS-кластера, следует оценить также загрузку остальных хостов.

Проверка перегруженности СХД (Overloaded Storage Device).

• Выберите хост, перейдите на вкладку Performance, там переключитесь в режим “Advanced” и выберите объект “Disk”;
• Добавьте на график счетчик “Commands aborted”;
• Если значение счетчика отлично от нуля, у вас проблемы на стороне СХД. В противном случае ищем дальше.

Проверка на отброс принимаемых пакетов (Dropped Receive Packets).

• Выберите хост, перейдите на вкладку Performance, там переключитесь в режим “Advanced” и выберите объект “Network”;
• Выберите счетчик Receive Packets Dropped для всех адаптеров vmnic*;
• Значение больше нуля? Если да, отправляйтесь решать сетевые проблемы. Нет, продолжаем искать причину тормозов.

Проверка на отброс отправляемых пакетов (Dropped Transmit Packets).

• Выберите хост, перейдите на вкладку Performance, там переключитесь в режим “Advanced” и выберите объект “Network”;
• Выберите счетчик Transmit Packets Dropped для всех адаптеров vmnic*;
• Значение больше нуля? Если да, отправляйтесь решать сетевые проблемы. Нет, продолжаем искать причину тормозов.

На этом “ясные” причины заканчиваются и начинаются нюансы…

Проверка, что во многопроцессорной ВМ используется только один vCPU (one vCPU in an SMP VM).

Если у ВМ несколько виртуальных процессоров (vCPU), возможно, гостевая ОС некорректно настроена и не использует все vCPU.

• Выберите ВМ, перейдите на вкладку Performance, выберите режим Advanced и переключитесь в обзор “CPU”;
• Оцените загрузку в MHz (Usage MHz) для всех vCPU;
• Загрузка для одного vCPU большая, для остальных – близка к нулю? Да, ваша ВМ использует только один vCPU, смотрите раздел решения проблем с ЦП. Нет – продолжаем поиски.

Проверка CPU Ready у ВМ на средне-нагруженном хосте.

Если на ВМ нагрузка появляется всплесками, то даже с невысокой средней загрузкой ЦП хоста ВМ может испытывать проблемы производительности.

• Выберите хост, перейдите на вкладку Performance, там переключитесь в режим “Advanced” и выберите объект “CPU”;
• Счетчик Usage достаточно большой, но не превышает 95%?
• Выберите проблемную ВМ, перейдите на вкладку Performance, выберите режим Advanced и переключитесь в обзор “CPU”;
• Включите отображение счетчика Ready для всех vCPU;
• Есть ли промежутки времени, когда Ready для любого процессора больше 1000ms? Если есть – идем и решаем проблемы с ЦП. Нет – ищем причины дальше.

Если на хосте есть другие ВМ, потенциально испытывающие проблемы – проверьте CPU Ready и у них.

Проверка медленного или перегруженного СХД.

Проверим наличие задержек на СХД:

• Выберите проблемную ВМ, перейдите на вкладку Performance, выберите режим Advanced и переключитесь в обзор “Virtual Disk”;
• Выберите отображение всех дисков и счетчиков “Read Latency”/”Write Latency”;
• Превышают ли задержки 50ms? Если да, определенные проблемы есть, идем проверять очереди.

Проверка задержки очередей:

• Выберите хост с проблемной ВМ, перейдите на вкладку Performance, там переключитесь в режим “Advanced” и выберите объект “Disk”;
• Включите отображение счетчика “Queue Command Latency” для всех хранилищ;
• Превышает ли величина задержки 0ms? Если превышает, то вам необходимо увеличить максимальную глубину очереди устройства, после чего измерить задержки физического устройства.

Измерение задержек физического устройства:

• Выберите хост с проблемной ВМ, перейдите на вкладку Performance, там переключитесь в режим “Advanced” и выберите объект “Disk”;
• Выберите счетчики “Physical Device Read Latency” и “Physical Device Write Latency” для всех хранилищ;
• Превышает ли величина задержек 50ms? Если да, мы имеем дело с перегруженным по вводу/выводу СХД. Идите в набор решений для СХД (ниже в документе).

Примечание: 50ms – это верхняя граница, когда все может функционировать. Возможно, в вашем случае это будет 30ms или даже 20ms!

Проверка пиковых нагрузок на СХД.

• Выберите хост, перейдите на вкладку Performance, там переключитесь в режим “Advanced” и выберите объект “Disk”;
• Выберите счетчики “Physical Device Read Latency” и “Physical Device Write Latency” для всех хранилищ;
• Имеются ли на графике пики, превышающие 20ms, даже если среднее значение ниже 10ms? Если да, мы имеем дело с перегруженным по вводу/выводу СХД

Проверка наличия пиков в передаче данных на сеть.

• Выберите хост, перейдите на вкладку Performance, там переключитесь в режим “Advanced” и выберите объект “Network”;
• Оцените “Data Transmit Rate” и “Data Receive Rate”;
• Есть ли периоды, когда пиковая нагрузка превышает 90% на какой-то адаптер? Если да, у вас могут быть проблемы из-за сети, смотрите набор решений под сеть. Если нет, идите и решайте проблему далее.

Проверка низкой загрузки процессора ВМ.

Если загрузка процессора ВМ низкая, но ВМ тормозит, могут быть некоторые проблемы с конфигурацией.

• Выберите проблемную ВМ, перейдите на вкладку Performance, выберите режим Advanced и переключитесь в обзор “CPU”;
• Оцените величину счетчика “Usage”;
• Среднее значение ниже 75%? Возможно, есть некоторые проблемы, которые необходимо “порешать”. Идем в раздел решения проблем с ЦП. Если тормоза затрагивают весь хост, повторяем процедуру с остальными ВМ с хоста.

Проверка того, что память ВМ в прошлом была помещена в своп (Past VM Memory Swapping).

• Выберите хост, перейдите на вкладку Performance, там переключитесь в режим “Advanced” и выберите объект “Memory”;
• Добавьте счетчик “Swap Used”;
• Значение счетчика больше нуля? Если да, хост в прошлом активно использовал своп. Читайте решение проблем с памятью. Для определения проблемной ВМ (которая “ушла” в своп) читайте дальше.
• Выберите хост, перейдите на вкладку Performance, там переключитесь в режим “Advanced” и выберите объект “Memory”;
• Выберите тип графика “Stacked Graph (Per VM)” и добавьте счетчик “Swap Used”;
• ВМ, у которых это значение ненулевое, могут испытывать из-за этого проблемы с производительностью.

Проверка нехватки памяти в пуле ресурсов.

Проверяем использование ballooning:

• Выберите пул ресурсов, перейдите на вкладку Performance, там переключитесь в режим “Advanced” и выберите объект “Memory”;
• Оцените счетчик “Ballooning”;
• Значение больше нуля? Возможно, в пуле ресурсов сильная конкуренция за память. Оцените “Balooning” отдельных ВМ.
• Выберите хост, являющийся частью DRS-кластера, перейдите на вкладку Performance, там переключитесь в режим “Advanced” и выберите объект “Memory”;
• В свойствах графика выберите типа графика “Stacked Graph (Per VM)”. Добавьте счетчик “Balloon”;
• Оцените значение счетчика для ВМ, являющихся частью пула. Больше ли оно нуля? Если да, то нехватка памяти вызывает своп в гостевой ОС. Читайте раздел по устранению проблем с ОЗУ. Если нет – повторите операцию с остальными хостами DRS-кластера. Если и там так же – ищем причины дальше.

Проверка нехватки памяти на хосте.

• Выберите хост, перейдите на вкладку Performance, там переключитесь в режим “Advanced” и выберите объект “Memory”;
• Оцените счетчик “Ballooning”;
• Значение больше нуля? Возможно, в пуле ресурсов сильная конкуренция за память. Оцените “Balooning” отдельных ВМ.
• В свойствах графика выберите типа графика “Stacked Graph (Per VM)”. Добавьте счетчик “Balloon”;
• Оцените значение счетчика для ВМ. Больше ли оно нуля? Если да, то нехватка памяти вызывает своп в гостевой ОС. Читайте раздел по устранению проблем с ОЗУ.

Нехватка памяти для гостевой ОС (High Guest Memory Demand).

• Выберите ВМ, перейдите на вкладку Performance, там переключитесь в режим “Advanced” и выберите объект “Memory”;
• Добавьте счетчик “Usage” и оцените его значение;
• Среднее значение превышает 80%, а пики – 90%? Скорее всего, ВМ не хватает оперативной памяти. Отправляйтесь в раздел устранения проблем с памятью.

Продвинутая диаграмма

Для решения вышеуказанных проблем мы будем использовать esxtop.

Проверка наличия проблем с прерываниями (High Timer-Interrupt Rates).

• Запускаем esxtop/resxtop;
• Выбираем экран ЦП, нажав “c”;
• Добавляем “Summary Stats”, нажав “f” и затем “i”. Нажмите любую клавишу для возвращения в основной экран esxtop;
• Оцените счетчик “Times/S”;
• Он больше 1000 для любой ВМ? Если да, необходимо снизить количество прерываний, прочитав соответствующие рекомендации.

Проверяем наличие косяков с NUMA.

• Запускаем esxtop/resxtop;
• Выбираем экран ОЗУ, нажав “m”;
• Добавим “Numa Stats”, нажав “f” и затем “g”. Нажмите любую клавишу для возвращения в основной экран esxtop;
• Оцените счетчик “N%L” для всех ВМ. Если столбец не видно на экране, необходимо нажать “o” и несколько раз “G”, для передвижения счетчиков “NUMA” поближе к началу;
• Если “N%L” меньше 80% для какой-то ВМ, то ВМ имеет косяки с точки зрения Numa-архитектуры. Проследуйте в раздел решения проблем с Numa.

Проверка большого времени отклика у ВМ со снапшотами.

• Запускаем esxtop/resxtop;
• Выбираем экран виртуальных дисков, нажав “v”;
• Если не отображаются задержки, включим их отображение, нажав “f”, а затем “g” и “h”. Нажмите любую кнопку, чтобы вернуться в основной экран esxtop;
• Оцените значения “LAT/rd” и “LAT/wr” для ВМ со снапшотами. Данные значения отражают средние величины задержек при операциях ввода-вывода;
• Перейдите на экран с дисковыми устройствами, нажав “u”;
• Если задержки не отображаются по умолчанию, добавьте требуемые поля, нажав “f”, а затем “j” и “k”. Нажмите любую кнопку, чтобы вернуться в основной экран esxtop;
• Оцените значения “QUED”, “DAVG/rd” и “DAVG/wr”. “QUED” показывает текущее значение дисковой очереди на LUN. DAVG/* – среднее время отклика устройства;
• Значение очереди равно нулю? Задержки на экране “виртуального диска” значительно превышают задержки физического LUN? Если да, то проблема в снапшотах ВМ.

To be continued…

Рекомендации по решению проблем ждите в следующей статье/переводе.