2,5 года назад я написал перевод vSphere 4.1 performance troubleshooting. С тех пор утекло много воды, рекомендации мною так и не были переведены, поэтому исправляюсь: перепечатаю статью нашего спонсора – компании ИТ-Град.
Как быстро идентифицировать проблему, связанную с производительностью процессора, какие метрики в этом случае будут наиболее информативными? На эти и многие другие вопросы, имеющие отношение к производительности CPU в виртуальном окружении vSphere, ответим в этой статье.
Интенсивность потребления процессорных ресурсов зависит от множества факторов и различных условий. Именно поэтому вопрос контроля ресурсоемкости и загруженности CPU должен быть максимально проработанным. Допустим, в окружении vSphere используется слишком большое количество виртуальных машин с запущенными на них высоконагруженными приложениями, это может привести к нехватке процессорных ресурсов. Иногда причиной подобной нехватки становится неэффективное использование или неоптимальная конфигурация виртуальных машин. В любом случае, нехватка ресурсов CPU может привести к серьёзным проблемам с производительностью и сказаться на работе жизненно важных для бизнеса сервисов.
Самые распространенные проблемы производительности CPU
# Ready Time – процессор находится в состоянии готовности, когда виртуальная машина готова к старту, однако не может быть запущена в силу недостаточности ресурсов физического хоста. Показатель Ready Time считается нормальным, когда его значение не превышает 10 %. Если же наблюдается рост этого показателя, повышается вероятность сбоев и зависания гостевой операционной системы. Однако менее чувствительные к показателям CPU приложения и виртуальные машины могут продолжать корректно функционировать и при значении Ready Time выше 10 %.
# High Co–stoptime – показатель Co-stoptime указывает на наличие большего количества vCPU, чем необходимо. А это зачастую вызывает дополнительное расходование ресурсов, уменьшая производительность виртуальной машины. В подобной ситуации при снижении количества vCPU ВМ сможет работать значительно лучше.
# CPU Limits – указывает на установленные процессорные лимиты, запрещающие виртуальной машине превышать пороговые значения. Такое ограничение, в случае если виртуальной машине требуется большее количество ресурсов, становится причиной проблем с производительностью.
# Host CPU Saturation – используется для проверки загрузки процессора хоста. Если средняя загрузка составляет более 75 % или пиковая – более 90 %, то наблюдается нехватка ресурсов CPU узла vSphere, что чревато проблемами запуска имеющихся виртуальных машин.
# Guest CPU Saturation – указывает на загрузку процессора виртуальной машины. Если приложение виртуальной машины использует 90 % и более ресурсов CPU, то наблюдается проблема с производительностью. В этом случае vCPU становится «узким горлышком». Добавление дополнительного vCPU может улучшить производительность виртуальной машины, если приложение умеет распараллеливать нагрузку.
# Low Guest Usage – может указывать на некорректную конфигурацию приложения или недостаточность других ресурсов (будь то оперативная память или жесткий диск) и, следовательно, выделенные ресурсы vCPU не смогут использоваться в полной мере.
Скрипт как средство имитации загрузки CPU: изучаем особенности
Для имитации загрузки CPU в тестовой среде воспользуемся скриптом и понаблюдаем за поведением виртуальной машины. Для начала необходимо запустить VMware vSphere Power CLI, после чего станет доступным окно командной строки, в котором и запускается скрипт Start CPU Test.
За неимением этого скрипта можете взять пару виртуальных машин и запустить в них какое-нибудь стрессовое приложение, например, 7z в режиме тестирования производительности.
Плюсом данного скрипта является то, что он отображает некоторое количество “попугаев”, выжимаемых ВМ.
Переключаемся в окно vSphere, переходим в закладку мониторинга производительности машины PERF-WORKER-01A. Поскольку интересны расширенные параметры, необходимо выбрать опцию Advanced –> Chart Options.
Здесь выбираются необходимые счетчики, полезные для отслеживания производительности процессора.
При расследовании проблем производительности CPU стоит обратить внимание на следующие счетчики:
- Demand – количество CPU виртуальной машины, необходимых (требуемых) для использования.
- Ready – показатель времени, в течение которого виртуальная машина готова запуститься, но не может в силу недостаточности физически ресурсов.
- Usage – количество CPU виртуальной машины, фактически разрешенных для использования в текущий момент.
Для выбора Demand, Ready, Usage и других счетчиков необходимо перейти в раздел метрик CPU и указать необходимые элементы, после чего нажать кнопку ОК.
Виртуальные машины могут находиться в одном из представленных ниже состояний, которые отслеживаем с помощью соответствующих счетчиков:
- Wait (VMWAIT) – такое состояние фиксируется, когда гостевая ОС виртуальной машины находится в состоянии простоя или ожидается выполнение задач на уровне vSphere. К примеру, vCPU может перейти в режим Wait в случае, если ожидается завершение операций ввода-вывода или выполнение «свопирования» на уровне ESX. Иными словами, такой счетчик отображает процент времени, который виртуальная машина потратила на ожидание, пока ядро ESX выполняло какие-либо операции.
- Ready (RDY) – главная составляющая производительности процессора. Процессор может находиться в состоянии RDY, когда виртуальная машина готова к запуску, но в силу недостаточности физических ресурсов хоста запуститься не может. Одной из причин может быть установленный на CPU лимит (выше мы говорили об этом), или лимит ресурсного пула.
- Co–Stop (CSTP): этот статус соотносится со временем, когда виртуальная машина готова исполнять команды, но вынуждена ждать высвобождения других vCPU для возможности их одновременного использования.
- Run (исполнение): показывает, что виртуальная машина «исполняется» в системе.
Исходя из рассмотренных статусов и счетчиков, нелишним будет ознакомиться с одной важной формулой. Она верна для отдельно взятой VM, которая либо простаивает и находится в ожидании (%WAIT), либо готова исполнять команды, но CPU занят (%RDY), либо ожидает высвобождения нескольких процессоров (%CSTP), либо исполняется в системе (%RUN).
Для одного vCPU справедливо следующее уравнение.
%WAIT + %RDY + %CSTP + %RUN = 100% |
Сравнение показателей Demand и Usage
Обратите внимание на то, сколько ресурсов CPU требуется для работы виртуальной машины и сколько в действительности используется. Как видно на рисунке, требуется (demand) значительно больше, чем используется (use). Также обратите внимание на показатель Ready Time, равный 9977 ms. Как вы помните, если это значение будет больше 10% или 1000ms, вероятна проблема с производительностью. Для перевода значения из миллисекунд в проценты можно воспользоваться следующей формулой:
Заметка: поскольку некоторые показатели в отчетах vCenter отображаются в миллисекундах, приведенную формулу можно использовать для перевода значений в проценты. Эта формула справедлива для 1vCPU. Если vCPU несколько, то пороговое значение необходимо умножить на количество vCPU. К примеру, для 4vCPU пороговым значением является 40% CPU Ready или 4000ms.
Кроме того, если вы оцениваете исторические значения (прошлый день, неделя и т.д.), то вам необходимо ознакомиться со следующей статьей.
Статистика CPU на уровне хоста
Для просмотра статистики на уровне хоста выбирается необходимый узел и используется закладка Monitor-Performance, как показано на рисунке. После выбора опции Advanced станет доступной возможность просмотра счетчиков производительности.
Здесь можно отслеживать статистику по CPU на уровне хоста ESX.
Согласно рисунку, только один из процессоров хоста претерпевает значительную нагрузку, тогда как остальные практически не задействованы.
Примечание: данная ситуация совершенно нетипична, далее вы увидите почему!
Редактирование параметров виртуальной машины
А давайте что-нибудь изменим в настройках ВМ. Для этого выделим нашу ВМ VMPERF-WORKER-01A, выберем Actions, а затем Edit Settings, как указано на рисунке.
Выполним проверку параметров CPU affinity на машине PERF-WORKER-01A.
Как видно на рисунке, значение Scheduling affinity равно единице. Это означает, что vCPU этой ВМ работает только на ядре №1. Чтобы сбалансировать виртуальные машины на использование всех физических процессоров в системе, необходимо очистить установленное значение «1» и нажать ОК. Аналогичное действие выполняем и на второй виртуальной машине (PERF-WORKER-01B).
Заметка: в большинстве случаев VMware не рекомендует использовать установленные вручную значения Scheduling affinity. vSphere способна выполнять оптимальную балансировку VM в контексте физических процессорных ресурсов. Кроме того, использование значений «affinity», выставленных вручную, не даст использовать vMotion, а также может вызвать сложности в управлении и проблемы с производительностью.
На прощанье прорекламирую продолжение этой статьи.
проверил у себя всё, нашёл одну проблемную вм, база данных оркл 4 тб, производительности схд не хватает ожидание цп много(
Бывает.
Очень интересная статья! Спасибо. Но, 10% это не 1000ms, а 2000ms (ведь 20000ms). Ну и 40% CPU Ready = 8000ms 🙂