Cpu ready vmware что это

Обновлено: 07.07.2024

Как быстро идентифицировать проблему, связанную с производительностью процессора, какие метрики в этом случае будут наиболее информативными? На эти и многие другие вопросы, имеющие отношение к производительности CPU в виртуальном окружении vSphere, ответим в этой статье.

Интенсивность потребления процессорных ресурсов зависит от множества факторов и различных условий. Именно поэтому вопрос контроля ресурсоемкости и загруженности CPU должен быть максимально проработанным. Допустим, в окружении vSphere используется слишком большое количество виртуальных машин с запущенными на них высоконагруженными приложениями, все это может привести к недостаточности процессорных ресурсов. Иногда причиной подобной нехватки становится и другой момент, связанный, к примеру, с неэффективным использованием или неоптимальной конфигурацией виртуальных машин. В любом случае нехватка ресурсов CPU может привести к серьёзным проблемам с производительностью и сказаться на работе жизненно важных для бизнеса сервисов.

Самые распространенные проблемы производительности CPU

Скрипт как средство имитации загрузки CPU: изучаем особенности

Для имитации загрузки CPU в тестовой среде воспользуемся скриптом и понаблюдаем за поведением виртуальной машины. Для начала необходимо запустить VMware vSphere Power CLI, после чего станет доступным окно командной строки, в котором и запускается скрипт Start CPU Test.

Рисунок 1. Окно командной строки

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

Рисунок 2. Запуск удаленных рабочих столов виртуальных машин

Скрипт имитирует ресурсоемкий процесс загрузки CPU виртуальных машин: PERF-WORKER-01Aи PERF-WORKER-01B, а графический интерфейс отображает значения производительности в режиме реального времени. Как видите, отметка производительности близка к значению 15 000.

Переключаемся в окно vSphere, переходим в закладку мониторинга производительности машины PERF-WORKER-01A. Поскольку интересны расширенные параметры, необходимо выбрать опцию Advanced –> Chart Options.

Рисунок 3. Обзор расширенных параметров в vSphere

Здесь выбираются необходимые счетчики, полезные для отслеживания производительности процессора.

Рисунок 4. Выбор соответствующих счетчиков производительности

При расследовании проблем производительности CPU стоит обратить внимание на следующие счетчики:

Demand – количество CPU виртуальной машины, необходимых (требуемых) для использования.
Ready – показатель времени, в течение которого виртуальная машина готова запуститься, но не может в силу недостаточности физически ресурсов.
Usage – количество CPU виртуальной машины, фактически разрешенных для использования в текущий момент.

Для выбора Demand, Ready, Usage и других счетчиков необходимо перейти в раздел метрик CPU и указать необходимые элементы, после чего нажать кнопку ОК.

Рисунок 5. Показатели CPU State

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

Wait(VMWAIT) – такое состояние фиксируется, когда гостевая ОС виртуальной машины находится в состоянии простоя или ожидается выполнение задач на уровне vSphere. К примеру, vCPU может перейти в режим Wait в случае, если ожидается завершение операций ввода-вывода или выполнение «свопирования» на уровне ESX. Иными словами, такой счетчик отображает процент времени, который виртуальная машина потратила на ожидание, пока ядро ESX выполняло какие-либо операции.

Ready(RDY) – главная составляющая производительности процессора. Процессор может находиться в состоянии RDY, когда виртуальная машина готова к запуску, но в силу недостаточности физических ресурсов хоста запуститься не может. Одной из причин может быть установленный на CPU лимит (выше мы говорили об этом), или лимит ресурсного пула.

Co-Stop(CSTP): этот статус соотносится со временем, когда виртуальная машина готова исполнять команды, но вынуждена ждать высвобождения других vCPU для возможности их одновременного использования.

Run(исполнение): показывает, что виртуальная машина «исполняется» в системе.

Исходя из рассмотренных статусов и счетчиков, нелишним будет ознакомиться с одной важной формулой. Она верна для отдельно взятой VM, которая либо простаивает и находится в ожидании (%WAIT), либо готова исполнять команды, но CPU занят (%RDY), либо ожидает высвобождения нескольких процессоров (%CSTP), либо исполняется в системе (%RUN).

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

Сравнение показателей Demand и Usage

Рисунок 6. Сравнение показателей счетчиков производительности

Обратите внимание на то, сколько ресурсов CPU требуется для работы виртуальной машины и сколько в действительности используется. Как видно на рисунке, требуется (demand) значительно больше, чем используется (use). Также обратите внимание на показатель Ready Time, равный 9977 ms. Как вы помните, если это значение будет больше 10 %, вероятна проблема с производительностью. Для перевода значения из миллисекунд в проценты можно воспользоваться следующей формулой:

Заметка: поскольку некоторые показатели в отчетах vCenter отображаются в миллисекундах, приведенную формулу можно использовать для перевода значений в проценты.

Статистика CPU на уровне хоста

Для просмотра статистики на уровне хоста выбирается необходимый узел и используется закладка Monitor-Performance, как показано на рисунке. После выбора опции Advanced станет доступной возможность просмотра счетчиков производительности.

Рисунок 7. Обзор статистики на уровне хоста

Здесь можно отслеживать статистику по CPU на уровне хоста ESX.

Рисунок 8. Обзор счетчиков производительности

Согласно рисунку, только один из процессоров хоста претерпевает значительную нагрузку, тогда как остальные практически не задействованы.

Редактирование параметров виртуальной машины

Зачастую возникает необходимость редактировать параметры виртуальной машины. Давайте рассмотрим, как это делается. Для начала обратимся к VMPERF-WORKER-01A, выберем Actions, а затем Edit Settings, как указано на рисунке.

Рисунок 9. Редактирование параметров виртуальной машины

Выполним проверку параметров CPU affinity на машине PERF-WORKER-01A.

Рисунок 10. Редактирование параметров CPU

Как видно на рисунке, значение affinity равно единице. Чтобы правильно сбалансировать виртуальные машины на использование физических процессоров в системе, необходимо очистить установленное значение «1» и нажать ОК. Аналогичное действие выполняем и на второй виртуальной машине (PERF-WORKER-01B).

Рисунок 11. Редактирование параметров CPU

Заметка: в большинстве случаев VMware не рекомендует использовать установленные вручную значения affinity. vSphere способна выполнять оптимальную балансировку VM в контексте физических процессорных ресурсов. Кроме того, использование значений «affinity», выставленных вручную, не даст использовать vMotion, а также может вызвать сложности в управлении и проблемы с производительностью.

Подводим итоги

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

Следите за новыми материалами нашего блога. В следующей статье мы продолжим рассказывать про оптимизацию производительности CPU в vSphere.

Рассказываем, что и почему "тормозит" и как сделать так, чтобы не "тормозило".

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

Буду рассматривать следующие аспекты производительности виртуальных машин:

Для анализа производительности нам понадобятся:

Ниже в статье расскажу немного про ESXTOP и приведу несколько полезных ссылок на документацию и статьи по теме.

Немного теории

Диаграмма состояний процесса в ESXi. Источник

В ESXi за работу каждого vCPU (ядра виртуальной машины) отвечает отдельный процесс – world в терминологии VMware. Также есть служебные процессы, но с точки зрения анализа производительности ВМ они менее интересны.

Процесс в ESXi может находиться в одном из четырех состояний:

Run – процесс выполняет какую-то полезную работу.
Wait – процесс не выполняет никакой работы (idle) либо ждет ввода/вывода.
Co-stop – состояние, которое возникает в многоядерных виртуальных машинах. Оно возникает, когда планировщик CPU гипервизора (ESXi CPU Scheduler) не может запланировать одновременное исполнение на физических ядрах сервера всех активных ядер виртуальной машины. В физическом мире все ядра процессора работают параллельно, гостевая ОС внутри ВМ рассчитывает на аналогичное поведение, поэтому гипервизору приходится замедлять ядра ВМ, у которых есть возможность закончить такт быстрее. В современных версиях ESXi планировщик CPU использует механизм, который называется relaxed co-scheduling: гипервизор считает разрыв между самым "быстрым" и самым “медленным" ядром виртуальной машины (skew). Если разрыв превышает определенный порог, "быстрое" ядро переходит в состояние co-stop. Если ядра ВМ проводят много времени в этом состоянии, это может вызвать проблемы с производительностью.
Ready – процесс переходит в данное состояние, когда у гипервизора нет возможности выделить ресурсы для его исполнения. Высокие значения ready могут вызвать проблемы с производительностью ВМ.

Основные счетчики производительности CPU виртуальной машины

CPU Usage, %. Показывает процент использования CPU за заданный период.

Как анализировать? Если ВМ стабильно использует CPU на 90% или есть пики до 100%, то у нас проблемы. Проблемы могут выражаться не только в "медленной" работе приложения внутри ВМ, но и в недоступности ВМ по сети. Если система мониторинга показывает, что ВМ периодически отваливается, обратите внимание на пики на графике CPU Usage.

Есть стандартный Аlarm, который показывает загрузку CPU виртуальной машины:

Что делать? Если у ВМ постоянно зашкаливает CPU Usage, то можно задуматься об увеличении количества vCPU (к сожалению, это не всегда помогает) или переносе ВМ на сервер с более производительными процессорами.

CPU Usage in Mhz

В графиках на vCenter Usage в % можно посмотреть только по всей виртуальной машине, графиков по отдельным ядрам нет (в Esxtop значения в % по ядрам есть).

По каждому ядру можно посмотреть Usage in MHz.

Как анализировать? Бывает, что приложение не оптимизировано под многоядерную архитектуру: использует на 100% только одно ядро, а остальные простаивают без нагрузки. Например, при дефолтных настройках бэкапа MS SQL запускает процесс только на одном ядре. В итоге резервное копирование тормозит не из-за медленной скорости дисков (именно на это изначально пожаловался пользователь), а из-за того, что не справляется процессор. Проблема была решена изменением параметров: резервное копирование стало запускаться параллельно в несколько файлов (соответственно, в несколько процессов).

Пример неравномерной нагрузки ядер

Также бывает ситуация (как на графике выше), когда ядра нагружены неравномерно и на некоторых из них есть пики в 100%. Как и при загрузке только одного ядра, alarm по CPU Usage не сработает (он по всей ВМ), но проблемы с производительностью будут.

Что делать? Если ПО в виртуальной машине нагружает ядра неравномерно (использует только одно ядро или часть ядер), нет смысла увеличивать их количество. В таком случае лучше переместить ВМ на сервер с более производительными процессорами.

Также можно попробовать проверить настройки энергопотребления в BIOS сервера. Многие администраторы включают в BIOS режим High Performance и тем самым отключают технологии энергосбережения C-states и P-states. В современных процессорах Intel используется технология Turbo Boost, которая увеличивает частоту отдельных ядер процессора за счет других ядер. Но она работает только при включенных технологиях энергосбережения. Если мы их отключаем, то процессор не может уменьшить энергопотребление ядер, которые не нагружены.

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

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

CPU Ready (Readiness)

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

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

В vCenter можно посмотреть 2 счетчика, связанных с CPU Ready:

Значения обоих счетчиков можно посмотреть как по всей ВМ, так и по отдельным ядрам.

Readiness показывает значение сразу в процентах, но только в Real-time (данные за последний час, интервал измерений 20 секунд). Этот счетчик лучше использовать только для поиска проблем "по горячим следам".

Значения счетчика Ready можно посмотреть также в исторической перспективе. Это полезно, если нужно установить закономерности и для более глубокого анализа проблемы. Например, если у виртуальной машины начинаются проблемы с производительностью в какое-то определенное время, можно сопоставить интервалы повешенного значения CPU Ready с общей нагрузкой на сервер, где данная ВМ работает, и принять меры по снижению нагрузки (если DRS не справился).

Ready в отличие от Readiness показывается не в процентах, а миллисекундах. Это счетчик типа Summation, то есть он показывает, сколько времени за период измерения ядро ВМ находилось в состоянии Ready. Перевести данное значение в проценты можно по несложной формуле:

(CPU ready summation value / (chart default update interval in seconds * 1000)) * 100 = CPU ready %

Например, для ВМ на графике ниже пиковое значение Ready на всю виртуальную машину получится следующим:

При подсчете значения Ready в процентах стоит обращать внимание на два момента:

Значение Ready по всей ВМ – это сумма Ready по ядрам.
Интервал измерения. Для Real-time – это 20 секунд, а, например, на дневных графиках – это 300 секунд.

При активном траблшутинге эти простые моменты можно легко упустить и потратить ценное время на решение несуществующих проблем.

Рассчитаем Ready на основе данных из графика ниже. (324474/(20*1000))*100 = 1622% на всю ВМ. Если смотреть по ядрам получится уже не так страшно: 1622/64 = 25% на ядро. В данном случае обнаружить подвох довольно просто: значение Ready нереалистичное. Но если речь идет о 10–20% на всю ВМ с несколькими ядрами, то по каждому ядру значение может быть в пределах нормы.

Что делать? Высокое значение Ready говорит о том, что серверу не хватает ресурсов процессора для нормальной работы виртуальных машин. В такой ситуации остается только уменьшить переподписку по процессору (vCPU:pCPU). Очевидно, этого можно добиться, уменьшив параметры существующих ВМ или путем миграции части ВМ на другие серверы.

Co-stop

Как анализировать? Данный счетчик также имеет тип Summation и переводится в проценты аналогично Ready:

(CPU co-stop summation value / (<chart default update interval in seconds> * 1000)) * 100 = CPU co-stop %

Здесь также нужно обращать внимание на количество ядер на ВМ и на интервал измерения.

В состоянии Costop ядро таже не выполняет полезную работу. При правильном подборе размера ВМ и нормальной нагрузке на сервер счетчик со-stop должен быть близок к нулю.

В данном случае нагрузка явно ненормальная :)

Также co-stop вырастет, если для активных ядер одной ВМ используются треды на одном физическом ядре сервера со включенным hyper-treading. Такая ситуация может возникнуть, например, если у ВМ больше ядер, чем физически есть на сервере, где она работает, или если для ВМ включена настройка "preferHT". Про эту настройку можно прочитать здесь.

Чтобы избежать проблем с производительностью ВМ из-за высокого Co-stop, выбирайте размер ВМ в соответствии с рекомендациями производителя ПО, которое работает на этой ВМ, и с возможностями физического сервера, где работает ВМ.

Не добавляйте ядра про запас, это может вызвать проблемы с производительностью не только самой ВМ, но и ее соседей по серверу.

Другие полезные метрики CPU

Run – сколько времени (мс) за период измерения vCPU находился в состоянии RUN, то есть собственно выполнял полезную работу.

Idle – сколько времени (мс) за период измерения vCPU находился в состоянии бездействия. Высокие значения Idle – это не проблема, просто vCPU было "нечего делать".

Wait – сколько времени (мс) за период измерения vCPU находился в состоянии Wait. Так как в данный счетчик включается IDLE, высокие значения Wait также не говорят о наличии проблемы. А вот если при высоком Wait IDLE низкий, значит ВМ ждала завершения операций ввода/вывода, а это, в свою очередь, может говорить о наличии проблемы с производительностью жесткого диска или каких-либо виртуальных устройств ВМ.

Max limited – сколько времени (мс) за период измерения vCPU находился в состоянии Ready из-за установленного лимита по ресурсам. Если производительность необъяснимо низкая, то полезно проверить значение данного счетчика и лимит по CPU в настройках ВМ. У ВМ действительно могут оказаться выставлены лимиты, о которых вы не знаете. Например, так происходит, когда ВМ была склонирована из шаблона, на котором был установлен лимит по CPU.

Swap wait – сколько времени за период измерения vCPU ждал операции с VMkernel Swap. Если значения данного счетчика выше нуля, то у ВМ точно есть проблемы с производительностью. Подробнее про SWAP поговорим в статье про счетчики оперативной памяти.

ESXTOP

Если счетчики производительности в vCenter хороши для анализа исторических данных, то оперативный анализ проблемы лучше производить в ESXTOP. Здесь все значения представлены в готовом виде (не нужно ничего переводить), а минимальный период измерения 2 секунды.

Экран ESXTOP по CPU вызывается клавишей "c" и выглядит следующим образом:

Для удобства можно оставить только процессы виртуальных машин, нажав Shift-V.

Чтобы посмотреть метрики по отдельным ядрам ВМ, нажмите "e" и вбейте GID интересующей ВМ (30919 на скриншоте ниже):

Кратко пройдусь по столбцам, которые представлены по умолчанию. Дополнительные столбцы можно добавить, нажав "f".

NWLD (Number of Worlds) – количество процессов в группе. Чтобы раскрыть группу и увидеть метрики для каждого процесса (например, для каждого ядра многоядерной ВМ), нажмите “e”. Если в группе больше одного процесса, то значения метрик для группы равны сумме метрик для отдельных процессов.

%USED – сколько циклов CPU сервера использует процесс или группа процессов.

%RUN – сколько времени за период измерения процесс находился в состоянии RUN, т.е. выполнял полезную работу. Отличается от %USED тем, что не учитывает hyper-threading, frequency scaling и время, затраченное на системные задачи (%SYS).

%SYS – время, затраченное на системные задачи, например: обработку прерываний, ввода/вывода, работу сети и пр. Значение может быть высоким, если на ВМ большой ввод/вывод.

%OVRLP – сколько времени физическое ядро, на котором выполняется процесс ВМ, потратило на задачи других процессов.

Данные метрики соотносятся между собой следующим образом:

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

Обычно метрика %USED является более информативной.

%WAIT – сколько времени за период измерения процесс находился в состоянии Wait. Включает IDLE.

%IDLE – cколько времени за период измерения процесс находился в состоянии IDLE.

%SWPWT – сколько времени за период измерения vCPU ждал операции с VMkernel Swap.

%VMWAIT – сколько времени за период измерения vCPU находилось в состояния ожидания события (обычно ввода/вывода). Аналогичного счетчика нет в vCenter. Высокие значения говорят о проблемах с вводом/выводом на ВМ.

%WAIT = %VMWAIT + %IDLE + %SWPWT.

Если ВМ не использует VMkernel Swap, то при анализе проблем с производительностью целесообразно смотреть на %VMWAIT, так как данная метрика не учитывает время, когда ВМ ничего не делала (%IDLE).

%RDY – cколько времени за период измерения процесс находился в состоянии Ready.

%CSTP – cколько времени за период измерения процесс находился в состоянии Co-stop.

%MLMTD – сколько времени за период измерения vCPU находился в состоянии Ready из-за установленного лимита по ресурсам.

%WAIT + %RDY + %CSTP + %RUN = 100% – ядро ВМ все время находится в каком-то из этих четырех состояний.

CPU на гипервизоре

В vCenter есть также счетчики производительности CPU для гипервизора, но они не представляют из себя ничего интересного – это просто сумма счетчиков по всем ВМ на сервере.

Удобнее всего смотреть состояние CPU на сервере на вкладке Summary:

Для сервера, как и для виртуальной машины, есть стандартный Alarm:

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

В ESXTOP данные о загрузке CPU сервера представлены в верхней части экрана. Помимо стандартного CPU load, который малоинформативен для гипервизоров, есть еще три метрики:

CORE UTIL(%) – загрузка ядра физического сервера. Данный счетчик показывает, сколько времени за период измерения ядро выполняло работу.

PCPU UTIL(%) – если включен hyper-threading, то на каждое физическое ядро приходится два потока (PCPU). Данная метрика показывает, сколько времени каждый поток выполнял работу.

PCPU USED(%) – то же, что PCPU UTIL(%), но учитывает frequency scaling (либо снижение частоты ядра в целях энергосбережения, либо повышение частоты ядра за счет технологии Turbo Boost) и hyper-threading.

PCPU_USED% = PCPU_UTIL% * эффективную частоту ядра / номинальную частоту ядра.

На этом скриншоте для некоторых ядер из-за работы Turbo Boost’а значение USED больше 100%, так как частота ядра выше номинальной

Пара слов о том, как учитывается hyper-threading. Если процессы исполняются 100% времени на обоих потоках физического ядра сервера, при этом ядро работает на номинальной частоте, то:

CORE UTIL для ядра будет 100%,
PCPU UTIL для обоих потоков будет 100%,
PCPU USED для обоих потоков будет 50%.

Если оба потока не работали 100% времени за период измерения, то в те периоды, когда потоки работали параллельно, PCPU USED для ядер делится пополам.

В ESXTOP также есть экран с параметрами энергопотребления CPU сервера. Здесь можно посмотреть, используются ли сервером технологии энергосбережения: C-states и P-states. Вызывается клавишей "p":

Стандартные проблемы производительности CPU

Напоследок пробегусь по типичным причинам возникновения проблем с производительностью CPU ВМ и дам короткие советы их решению:

На этом про CPU у меня все. Задавайте вопросы. В следующей части расскажу про оперативную память.

Чтобы понять, что такое CPU Ready, нам нужно понять, как гипервизоры планируют виртуальные процессоры (vCPU) для физических процессоров (pCPU). Когда для виртуальной машины требуется время vCPU, ее vCPU необходимо запланировать для pCPU, чтобы команды / процессы / потоки могли работать с pCPU. В идеальном мире не бывает конфликтов ресурсов или узких мест, когда это должно произойти. Когда одной виртуальной машине vCPU необходимо запланировать время для pCPU, доступно ядро pCPU, а CPU Ready в этом идеальном мире минимален. Важно отметить, что CPU Ready всегда существует, но в идеальном мире он очень минимален и не замечен.

То, что происходило в этом сценарии, было CPU Ready. Была сформирована очередь vCPU, готовая к планированию, но нет доступного для планирования pCPU. Гипервизор остановит планирование и вызовет задержку для гостевой виртуальной машины. Это тихий убийца, который до недавних лет не было много инструментов для обнаружения. В виртуальной машине Windows загрузка может занять целую вечность, а затем, когда она, наконец, произойдет, когда вы нажмете на меню «Пуск», она будет отображаться вечно. Вы можете даже щелкнуть по нему еще раз, думая, что он не принял ваш первый щелчок, и когда он, наконец, догонит вас, вы получите двойной щелчок. В Linux ваша ВМ может загрузиться в режиме только для чтения или даже переключить файловые системы в режим только для чтения в какой-то момент позже.

Так как же мы боремся с CPU Ready? Есть несколько способов, которые могут помочь. Во-первых, это мониторинг показателей CPU Ready. В VMware не рекомендуется превышать 10%, но по личному опыту пользователи начинают замечать более 5-7% в зависимости от типа виртуальной машины и ее работы.

Ниже я буду использовать некоторые примеры из VMware ESXi 5.5, чтобы показать CPU Ready. Используя командную строку, запустите «esxtop». Нажмите «c» для просмотра процессора, и вы должны увидеть столбец «% RDY”Для CPU Ready. Вы можете нажать столицу »В»Для VM Only view.

Здесь вы можете увидеть, что% RDY несколько выше для довольно неиспользуемой среды. В этом случае на моем ESXi 5.5 работает тестовая виртуальная машина поверх VMware Fusion (гипервизор Mac), поэтому ожидается, что она будет немного более высокой, поскольку мы запускаем виртуальную машину на гипервизоре поверх другого гипервизора.

В клиенте vSphere вы можете открыть определенную виртуальную машину и перейти на вкладку «Производительность». Оттуда нажмите на «Параметры диаграммы»

В Chart Options выберите CPU, Real-time (если у вас есть vCenter, у вас могут быть другие параметры синхронизации, чем в реальном времени). Оттуда в счетчиках выберите «Готово». Возможно, вам придется отменить выбор другого счетчика, так как представление допускает только два типа данных в любой момент времени.

При покупке аппаратного обеспечения большее количество ядер помогает уменьшить влияние CPU Ready. Hyperthreading также помогает. Хотя Hyperthreading не предоставляет полное второе ядро для каждого основного ядра, обычно этого достаточно для планирования vCPU для pCPU и помощи в устранении проблемы. Хотя гипервизоры начинают переходить от рекомендации по соотношению vCPU к pCPU, вы обычно можете преуспеть в умеренно используемой среде с соотношением 4: 1 и пойти дальше. Когда вы начинаете загружать виртуальные машины, обратите внимание на задержку ЦП, готовность ЦП, общее ощущение и производительность. Если у вас есть несколько сильных виртуальных машин, вы можете разделить их на другие кластеры и использовать более низкое соотношение и сохранять их легкими. С другой стороны, для виртуальных машин, где производительность не является ключевой, и для них нормально работать вяло, вы можете переподписаться намного выше.

Правильный выбор размера виртуальных машин также является огромным инструментом для борьбы с CPU Ready. Многие поставщики рекомендуют спецификации по тому, что может понадобиться виртуальной машине. Традиционно больше процессоров и больше ядер = больше мощности. Проблема в виртуальной среде заключается в том, что гипервизор должен планировать все виртуальные ЦП на одном блоке примерно в одно и то же время, и блокировка этих ЦП может быть проблематичной. Если у вас виртуальная машина с 8 виртуальными ЦП, вам необходимо заблокировать 8 виртуальных ЦП, чтобы они могли планировать одновременно. Если ваша виртуальная машина vCPU использует только 10% от общего количества виртуальных ЦП в любой момент времени, лучше уменьшить число виртуальных ЦП до 2 или 4. Лучше запустить виртуальную машину с 50-80% ЦП с меньшим количеством виртуальных ЦП, чем 10% при больше vCPU. Эта проблема отчасти связана с тем, что планировщик ЦП операционной системы рассчитан на использование максимально возможного количества ядер, тогда как, если он был обучен максимально использовать ядра перед использованием большего количества, это может быть меньшей проблемой. Большая виртуальная машина может работать хорошо, но может быть «шумным соседом» для других виртуальных машин, поэтому обычно это процесс, в котором вам нужно пройти через все виртуальные машины в кластере, чтобы «подобрать правильный размер» их, чтобы увидеть некоторое повышение производительности.

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

Наконец, ваш гипервизор может поддерживать резервирование и ограничения для виртуальной машины. Иногда тезисы устанавливаются случайно. Агрессивные настройки на них могут привести к готовности процессора, когда на самом деле для него доступны базовые ресурсы. Обычно лучше всего использовать оговорки и ограничения экономно и только тогда, когда это абсолютно необходимо. По большей части кластер надлежащего размера будет соответствующим образом сбалансировать ресурсы, и они, как правило, не нужны.

Одна из причин деградации скорости работы сервиса — это падение производительности процессора. При использовании локальных вычислительных систем без виртуализации их падение влияет только на сам сервер и запущенные на нем приложения. Установленный гипервизор, например от VMware, делит ресурсы физического процессора на все виртуальные машины, и аномальная нагрузка на одну из них может привести к критическому падению производительности на других.

Так же, как и в локальных средах, администратор виртуальной инфраструктуры должен уметь быстро определить причину падения производительности CPU в среде vSphere, используя наиболее информативные метрики.

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

Топ-6 проблем с производительностью CPU

Проблема с этим параметром заключается в том, что виртуальная машина ожидает запуска в состоянии полной готовности, но не может быть запущена, так как гипервизор не находит для нее ресурсов физического процессора. Необходимо, чтобы Ready Time был меньше 10%, иначе повышается вероятность зависания гостевой операционной системы и сбоев в работе. Хотя некоторые приложения не так чувствительны к этому параметру и работают нормально, но лучше не допускать больше 10%.

Параметр Co-stoptime показывает, что виртуальных процессоров vCPU больше, чем необходимо. Как это ни парадоксально, порой большое число vCPU снижает, а не увеличивает производительность виртуальной машины.

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

Параметр, который отслеживает загрузку процессора хоста. Когда средняя загрузка будет более 75% или пиковая достигнет 90%, узел vSphere решит, что ресурсов CPU не хватает, как результат — остановка виртуальных машин или проблемы с запуском.

Показывает перегрузку виртуального процессора. Если запущенное на виртуальной машине приложение «ест» больше 90% ресурсов процессора, производительность будет деградировать. Решение: добавить еще vCPU или разобраться с приложением — может, оно работает нестабильно или просто зависло.

Вот этот параметр как раз поможет определить некорректную настройку приложения или нехватку других ресурсов сервера (память, диск), когда добавление vCPU не решает проблему.

Имитируем загрузку CPU и изучаем особенности

Чтобы проверить корректность работы виртуального сервера, необходимо в тестовой среде запустить скрипт загрузки CPU и проанализировать поведение машины. Для этого в VMware vSphere Power CLI запускаем скрипт Start CPU Test.

Скрипт запускает две виртуальные машины и показывает их удаленные рабочие столы. На машинах PERF-WORKER-01A и PERF-WORKER-01B имитируется сильная нагрузка на vCPU и отображается производительность в режиме реального времени. В нашем случае она составляет около 15 000.

Теперь необходимо в окне vSphere зайти на вкладку мониторинга производительности виртуальной машины PERF-WORKER-01A и для отображения расширенных параметров включить опцию Advanced –> Chart Options.

Теперь мы можем выбрать те счетчики, которые позволят нам отследить производительность процессора и выявить проблемы.

Мы рекомендуем обратить внимание на следующие счетчики:

Demand — показывает число CPU, необходимых (требуемых) для работы.
Ready — показывает время, за которое машина может запуститься, но не делает этого из-за нехватки физических ресурсов.
Usage — показывает число CPU, которое разрешено использовать машине в настоящий момент.

Выявление проблем путем анализа показателей счетчиков

В процессе тестирования обратим внимание на то, сколько ресурсов необходимо потреблять виртуальной машине и сколько она использует фактически.

На скриншоте мы видим, что значение счетчика Demand (потребление) сильно больше, чем значение счетчика Use (использование). А показатель Ready Time равен 9977 ms. Чтобы перевести значение из миллисекунд в проценты для режима реального времени (real-time), необходимо показатель Ready Time разделить на 200 — в случае одного используемого vCPU. Или воспользоваться калькулятором. Для нашего теста получилось значение 49,89%, что в значительной мере превышает рекомендуемые 10%, а значит, наблюдается серьезная проблема с производительностью.

Также рекомендуем посмотреть статистику CPU на уровне хоста. Для этого выбрать нужный узел на вкладке Monitor-Performance и включить опцию Advanced — теперь станут видны счетчики производительности хоста.

Отследим статистику нагрузки CPU на уровне физического хоста.

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

Чтобы решить эту проблему, проверим правильность конфигураций тестовых виртуальных машин.

Проверка параметров виртуальных машин

Для проверки параметров виртуальной машины VMPERF-WORKER-01A выбираем в меню Actions команду Edit Settings.

Теперь проверим параметр CPU affinity, который может быть причиной возникновения такой аномалии.

В нашем случае его значение равно единице — это означает, что данной виртуальной машине назначен только один физический процессор и другие она использовать не может, даже в случае 100% нагрузки. Для правильной балансировки нагрузки между физическими процессорами хоста необходимо очистить это значение (оставить параметр пустым) и нажать «ОК». Те же манипуляции необходимо проделать и с настройками виртуальной машины PERF-WORKER-01B.

Мы не рекомендуем для виртуальных машин в среде VMware вручную выставлять значение affinity. Платформа vSphere отлично справляется с автоматической балансировкой нагрузки виртуальных машин между физическими процессорами. Также заданный вручную параметр affinity не позволяет воспользоваться технологией vMotion, что уменьшает функциональность виртуальной инфраструктуры.

Заключение

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

Мы рассмотрели проблемы, связанные с производительностью CPU, и рассказали, как с помощью тестов и счетчиков обнаружить слабые места виртуальной инфраструктуры. На виртуальную инфраструктуру надейся, но и сам за всем следи!

Читайте также: