Virtual machine cpu usage vmware что это

Обновлено: 02.07.2024

в первую очередь, у меня два вопроса, относящихся к VMware ЦП/виртуальные машины:

как это рассчитывается?
какие номера на каких вкладках vCenter (клиент vSphere)
окно ссылается?

Пожалуйста, также уточнить, если мое понимание резюмируется ниже правильно или нет.

пожалуйста, уточните, если следующее понимание мое правильно или нет:

физический процессор, а именно соответствует 1 ядру (встроенному в сокет процессора)
виртуальная машина (или гостевая ОС) распознает/обрабатывает свои процессоры всегда на уровне виртуального процессора (виртуальный процессор отмечен как vCPU ниже).
vCPU также называют логическим процессором (или процессором), синонимом друг друга.
когда HT не включено, 1 vCPU = 1 физический процессор (или 1 ядро)
когда HT включен, 1 ядро порождает 2 потока, и 1 поток просто выглядит как / действует как vCPU видя из машина VM, в слове, 1 сердечник обеспечивает 2 vCPUs в этом случае.

расчет использования ЦП для виртуальной машины, узла или кластера узлов
просто, просто разрабатывая A / B, где A - используемое количество, B - общая мощность.

вопрос: в случае виртуальной машины, где найти информацию о
и Би? какие вкладки, какие метрики / счетчики в окне vCenter?

перечисленные ниже, возможно, соответствующих элементы (данные из реальной системы VM), пожалуйста
покажите мне, что такое A, что B:

верна ли моя следующая догадка, откуда берется информация A и B?

Спасибо за чтение длинного текста и советы.

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

нет. Физический процессор-это процессор со всеми его ядрами.
да, в то время как такие технологии, как VT, могут быть использованы для предоставления ему более прямого аппаратного доступа к нему.
логический процессор является более общим срок.
да, но HT - это отдельная технология. Можно иметь несколько ЦП на виртуальную машину и несколько ядер на сокет на виртуальную машину. Это было бы независимо от хозяина, насколько я знаю.
посмотреть 4.

вы должны решить, в каком отношении вы хотите просмотреть использование процессора. Вы хотите процент использования для хоста или гостя? В зависимости от этого ваш B изменится.

ты прав, что A и B были бы номера вам. Но можно просмотреть потребление ЦП как общее количество доступной мощности для узла или виртуальной машины. B будет Количество ядер раз максимальная частота ядра. В зависимости от того, требуется ли информация о кластере в целом или для отдельной виртуальной машины, можно использовать Количество ядер виртуальной машины или узла. Последнее может быть интересно для поиска виртуальных машин, которые вызывают наибольшую текущую нагрузку на воинство.

для отдельных виртуальных машин имеется диаграмма в разделе Monitor => Performance , который использует количество ядер на виртуальную машину. A документация доступно для каждого графика по умолчанию и некоторых используемых данных.

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

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

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

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

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

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

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

Run – процесс выполняет какую-то полезную работу.
Wait – процесс не выполняет никакой работы (idle) либо ждет ввода/вывода.
Costop – состояние, которое возникает в многоядерных виртуальных машинах. Оно возникает, когда планировщик CPU гипервизора (ESXi CPU Scheduler) не может запланировать одновременное исполнение на физических ядрах сервера всех активных ядер виртуальной машины. В физическом мире все ядра процессора работают параллельно, гостевая ОС внутри ВМ рассчитывает на аналогичное поведение, поэтому гипервизору приходится замедлять ядра ВМ, у которых есть возможность закончить такт быстрее. В современных версиях ESXi планировщик CPU использует механизм, который называется relaxed co-scheduling: гипервизор считает разрыв между самым «быстрым» и самым “медленным" ядром виртуальной машины (skew). Если разрыв превышает определенный порог, «быстрое» ядро переходит в состояние costop. Если ядра ВМ проводят много времени в этом состоянии, это может вызвать проблемы с производительностью.
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:

Значения счетчика 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 %

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

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

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

Чтобы избежать проблем с производительностью ВМ из-за высокого сo-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 – сколько времени за период измерения процесс находился в состоянии IDLE.

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

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

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

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

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

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

%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%.

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

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

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

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

Неправильный сайзинг ВМ (слишком много/мало ядер). Если поставить мало ядер, будет высокая загрузка CPU ВМ. Если много, словите высокий co-stop.

Неправильная NUMA-топология на больших ВМ. NUMA-топология, которую видит ВМ (vNUMA), должна соответствовать NUMA-топологии сервера (pNUMA). Про диагностику и возможные варианты решения данной проблемы написано, например, в книге «VMware vSphere 6.5 Host Resources Deep Dive». Если не хотите углубляться и у вас нет лицензионных ограничений по ОС, установленной на ВМ, делайте на ВМ много виртуальных сокетов по одному ядру. Много не потеряете :)

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

Предупреждения о ОЗУ и CPU

Данные предупреждения и алерты, вы можете обнаружить как в vCenter server, так и на отдельном хосте ESXI. Выглядят эти алерты вот так:

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

Если вы перейдет на вкладку "Summary", то в пункте "Resources" увидите шкалу загрузки по процессору

и оперативной памяти.

Пути решения данной ситуации такие:

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

Что плохого несут в себе эти предупреждения

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

Советую к этим моментам отнестись более детально, от себя могу порекомендовать хорошую статью, про использовании памяти виртуальными машинами VMware vSphere и не доводите до такого.

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

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

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

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

Проверка VMware Tools.

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

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

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

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

Проверка CPU Ready:

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

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

Проверка CPU Ready:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Спасибо!
Убедился в своей проблеме с производительностью (СХД).

>>Если да, мы имеем дело с перегруженным по вводу/выводу СХД. Идите в набор решений для СХД (ниже в документе).

Добавить комментарий Отменить ответ

Перейти с Порше на Жигули - такое себе решение!

Мысли в слух " а может перейти на proxmox " Что-то в последняя время ESXi не стабильно стал по обновлениям.…

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