Cpu core average что это
CPU Load: когда начинать волноваться?
Аналогия транспортного потока
Так Вы говорите, 1.00 — идеальное значание load average?
Что насчет многопроцессорных систем? Мой сервер показывает загрузку 3.00 и все ОК!
У Вас четырехпроцессорная система? Все в порядке, если load average равен 3.00.
В мультипроцессорных системах загрузка вычисляется относительно количества доступных процессорных ядер. 100% загрузка обозначается числом 1.00 для одноядерной машины, числом 2.00 для двуядерной, 4.00 для четырехъядерной и т.д.
Если вернуться к нашей аналогии с мостом, 1.00 означает «одну полностью загруженную полосу движения». Если на мосту всего одна полоса, 1.00 означает, что мост загружен на 100%, если же в наличии две полосы, он загружен всего на 50%.
То же самое с процессорами. 1.00 означает 100% загрузки одноядерного процессора. 2.00 — 100% загрузки двуядерного и т.д.
Многоядерность vs. многопроцессорность
Сведем все вместе
Давайте посмотрим на средние значения загрузки с помощью команды uptime :
Здесь представлены показатели для системы с четырехъядерным процессором и мы видим, что имеется большой запас по нагрузке. Я даже не буду задумываться о ней, пока load average не превысит 3.70.
Какое среднее значение мне следует контролировать? Для одной, пяти или 15 минут?
Количество ядер важно для правильно понимания load average. Как мне его узнать?
Команда cat /proc/cpuinfo выводит информацию обо всех процессорах в вашей системе. Чтобы узнать количество ядер, «скормите» ее вывод утилите grep :
Примечания переводчика
Выше представлен перевод самой статьи. Также много интересной информации можно почерпнуть из комментариев к ней. Так, один из комментаторов говорит о том, что не для каждой системы важно иметь запас по производтельности и не допускать значения загрузки выше 0.70 — иногда нам нужно чтобы сервер работал «на всю катушку» и в таких случаях load average = 1.00 — то, что доктор прописал.
Хабраюзер dukelion добавил в комментариях ценное замечание, что в некоторых сценариях, для достижения максимального КПД «железа», стоит держать значение load average несколько выше 1.00 в ущерб эффективности работы каждого отдельного процесса.
Хабраюзер enemo в комментариях добавил замечание о том, что высокий показатель load average может быть вызван большим количеством процессов, выполняющих в данный момент операции чтения/записи. То есть, load average > 1.00 на одноядерной машине не всегда говорит о том, что в Вашей системе отсутствует запас по загрузке процессора. Требуется более внимательное изучение причин такого показателя. Кстати, это хорошая тема для нового поста на Хабре 🙂
Разбираемся в обозначениях процессоров: что они могут сообщить о характеристиках
Большинство индексов или цифр имеют вполне конкретное значение. Обратите на них внимание, когда будете выбирать процессор!
Если вы хотите подобрать оптимальный процессор в свою сборку, то не спешите копаться в технических характеристиках. Много полезной информации скрывается в наименовании ЦПУ. Если знать, что означают все эти буквы и цифры, то можно сэкономить много время. Разобраться в этой теме не сложно, достаточно понимать ключевые моменты. О них и поговорим.
Маркировка процессоров Intel
За всю историю компания Intel выпустила огромное количество разных моделей процессоров, и, разумеется, многие из них сегодня уже устарели. На данный момент актуальными остаются только четыре линейки. Каждая из них имеет свою направленность.
Поскольку Intel Core охватывает большую часть рынка, разберем на её примере как линейка делится на классы.
После классификации процессор в названии имеет числовое обозначение. Первая цифра всегда означает поколение. На данный момент самым актуальным является 10-е. У каждого поколения имеется кодовое название. Например:
Как вы заметили, после поколения следуют ещё три цифры. Как правило, они отображают уровень производительности модели относительно других процессоров в одном поколении. Например:
В наименовании модели после цифр может быть расположена буква, которая указывает на отличительную характеристику процессора. Они могут комбинироваться различными способами.
Новые мобильные процессоры Intel Core 11-го поколения, а также некоторые 10-го поколения, имеют непривычную маркировку. К примеру, Intel Core i7-1165G7, где цифра после G обозначает класс мобильной графики: G7 — ее максимальная производительность, G4 — средний уровень производительности, а G1 — базовый.
Стоит упомянуть, что многие модели встречаются в двух вариантах исполнения: BOX и OEM. Первый имеет увеличенную гарантию, а также подразумевает наличие кулера в комплекте. Второй продается дешевле, но в комплект поставки ничего не входит. Кстати, процессоры с разблокированным множителем поставляются без кулера и его нужно будет покупать отдельно.
Маркировка процессоров AMD
Говоря про обозначения ЦПУ, следует понимать, что для каждой линейки применяются уникальные правила маркировки, которые не являются универсальными. Поэтому всё, что написано ниже применимо только для ныне актуальных процессоров.
Linux: CPU Load – когда пора волноваться или что значит Load Average
load average: 0.09, 0.05, 0.01
Большинство людей знают, что обозначают эти цифры: они отображают среднюю нагрузку за определённое время (1, 5 и 15 минут), и знают, что чем меньшее значение – тем лучше. Большие же значения означают какие-то проблемы с нагрузкой на процессор. Но – какой порог? как выглядит “хорошее” и “плохое” значение Load Average? Когда начинать беспокоиться – а когда пора уже паниковать и срочно фиксить проблему?
Для начала – давайте рассмотрим, что именно обозначает Load Average. Начнём с простого примера – машина с одноядерным процессором.
Пример с движением по дороге
Одноядерный процессор можно представить себе как дорогу с однополосным движением. Представьте себе, что вы – оператор моста, по которому проходит эта дорога. Иногда движение по ней такое интенсивное, что машины выстраиваются в очередь для переезда. Вы хотите, что бы водители знали – какова скорость прохождения машин по вашему мосту. Самое простое решение – определить, сколько машин уже ожидают очереди на переезд моста: если машин в очереди нет – то водители будут знать, что могут проехать без проблем, а если машины скапливаются в очереди на подъезде к мосту – водители будут видеть, что им придётся простоять в этой очереди.
И так, оператор – какую систему измерения вы выберете? Как на счёт такой:
= load of 0.50
= load of 1.00
= load of 1.70
Это пример того, чем является загрузка процессора. “Машины” тут – процессы, занимающие процессорное время (“переезжают мост“), или стоящие в очереди на подъезде к нему. UNIX считает загрузку, как “длина в очереди на выполнение“: сумма процессов, которые в настоящие момент выполняются + количество процессов в очереди на обработку:
Как оператор моста, вы бы хотели, что бы машины (процессы) никогда не стояли в очереди. Так же и ваш процессор, в идеале, должен оставаться ниже 1.00. Так же, вы можете быть спокойны, если иногда возникают пики немного выше 1.00 – но вы должны начинать волноваться, если это происходит постоянно.
Так что – Load Average 1.00 является идеальным показателем?
Не совсем. Проблема нагрузки 1.00 в том, что у вас не остаётся “просвета” (запаса). На практике, многие системные администраторы придерживаются оптимального значения в 0.70:
А как на счёт многоядерных процессоров? У меня Load Average 3.00 – но всё работает отлично!
У вас четырёхъядерный процессор? Тогда – Load Average в 3.00 совершенно нормальное значение.
На многоядерных процессорах значение LA взаимосвязано с количеством процессоров. Использование на 100% отображается как 1.00 на одноядерной системе, 2.00 на двухъядерной, 4.00 на четырёх и так далее.
Если мы вернёмся к аналогии с мостом, то 1.00 значит, что одна полоса движения на мосту полностью занята. На мосту с одной полосой – это и будет 100% его “пропускной способности”. На двухполосном мосту – это уже 50%, т.к. только одна полоса занята полностью – но есть ещё одна, полностью свободная.
То же самое и с процессором – нагрузка в 1.00 будет 100% на одноядерной системе, а на двухъядерной – значение 2.00 будет 100% нагрузки.
Многоядерность vs многопроцессорность
Раз уж мы затронули эту тему – давайте поговорим о разнице между многоядерными и многопроцессорными системами. С точки зрения производительности – равна ли машина с одним двухъядерным процессоров – машине с двумя процессорами по одному ядру? Грубо говоря – да. Есть много тонкостей, связанных с кешированием, передачей процессов между процессорами и так далее. Несмотря на это, в целях вычисления итоговой нагрузки на процессор(ы) – важно общее количество ядер, независимо от того, на сколько физических процессоров они распределены.
Это приводит нас к ещё двум правилам:
Подведём итог
Давайте посмотрим на Load Average в выводе утилиты uptime :
Это двухъядерный процессор, значит у нас имеется большой запас производительности, и можно даже не задумываться о нагрузке, пока значение не достигнет хотя бы 1.7.
Далее, как на счёт остальных значений? 0.65 значит нагрузку за последнюю минуту, 0.42 – за последние 5 минут и 0.36 – за прошедшие 15 минут. Это приводит нас к вопросу:
За каким именно значением наблюдать? 1, 5 или 15 минут?
Помня правила, которые мы обсудили (1.00 == “Пора исправлять это“) – вам необходимо обращать внимание на значения 5 и 15 минут. Т.е., если на вашей машине бывают пики нагрузки за 1 минуту – это нормально. Если же значение 15-ти минут поднимается выше 1.00 и остаётся таким – пора заняться этим вопросом (конечно, учитывая момент, касающийся количества ядер в системе).
Значит, количество ядер в системе важный вопрос для выяснения реальной нагрузки. Как мне узнать – сколько ядер в моей системе?
так вы получите полную информацию о процессоре(ах).
А что бы получить просто число, без другой информации – выполните:
Оригинал статьи взят отсюда>>>. Замечания/предложения к переводу категорически приветствуются.
Сообщество InfoboxCloud
Администрирование
Категории
Прямой эфир
fadich 11 ноября 2015, 17:09
trukhinyuri 4 августа 2015, 04:41
trukhinyuri 23 января 2015, 14:46
trukhinyuri 30 октября 2014, 23:31
dimasmagadan 25 августа 2014, 09:12
trukhinyuri 15 января 2014, 12:06
trukhinyuri 21 ноября 2013, 23:29
Блоги
Что такое CPU Load Average в Linux и когда стоит волноваться? Какое облако обеспечит максимальную производительность?
Вероятно вы уже видели параметр Load Average. Это 3 числа, показываемых при выполнении команд uptime и top.
Большинство пользователей знают, что load average, это 3 числа, отражающих среднюю нагрузку за периоды времени в одну минуту, 5 минут и 15 минут. При этом меньшие числа лучше. Большие числа — либо есть проблема либо машина перегружена. Однако что является порогом, какие числа хороши а какие плохи? Когда следует предпринимать меры?
В конце статьи мы сравним облачные платформы InfoboxCloud по способности обеспечивать максимальную производительность (это всегда компромисс между производительностью и стоимостью).
Аналогия: трафик на дороге
Давайте начнем с простейшего случая, когда у сервера только один процессор, а далее разберем и более сложные случаи.
Одноядерный процессор похож на одну полосу с трафиком. При этом:
0.00 означает, что на этой полосе трафика нет вовсе. Фактически значение между 0.00 и 1.00 означает, что машина свободно проедет по полосе без притормаживаний.
1.00 означает, что вся полоса занята, но пробок нет.
Более 1.00 означает, что в полосу не все влезли и ждут в пробке.
Так идеальная загрузка 1.00?
Не совсем. С загрузкой 1.00 у вас нет запаса ресурса CPU.
Если загрузка более 0.70 — время подумать об увеличении ресурса CPU.
Если загрузка более 1.00 — нужно найти и исправить проблему, в противном случае будет выстраиваться очередь.
Если загрузка 5.0 и более — у вас серьезные проблемы и приложение или сайт будут явно тормозить.
Многопроцессорные системы. Загрузка 3.00 и ОК
Используется четырехядерный процессор? С загрузкой 3.00 действительно все ОК.
На многопроцессорных системах загрузка относительна числу доступных ядер. На 4х ядерном процессоре 100% загрузка: 4.00 — 4 полосы движения занято.
На какой из 3х параметров Load Average лучше смотреть?
Если загрузка 1.0 на первом минутном интервале — все в порядке. Если такая загрузка продолжается в течение 15 минут — повод задуматься об увеличении мощности CPU: добавлении ядер или частоты.
Причины для высокого Load Average при неизменной нагрузке
Высокий Load Average может быть следствием нехватки процессорного времени (или выставленных параметров CPU limit) или пропускной способности дисковой подсистемы (или низкого приоритета дисковой подсистемы).
Все виртуальные машины одинаковые?
Например, в облаке Virtuozzo Infrastructure скорость дисковой подсистемы программно не ограничена, а на VPS приоритет дисковой подсистемы понижен по сравнению с облаком (но VPS и дешевле).
В облаке Azure Pack Infrastructure гарантируется выделение от 25% до 90% CPU или 90% CPU (самый дорогой вариант, но и самый надежный) в зависимости от пожелания клиента (a ресурсы памяти и диска всегда гарантированы); на Virtuozzo Infrastructure гарантии выделения CPU нет (хотя есть внутренние регламенты по обеспечению процессорного времени CPU на Virtuozzo, обеспечивающие высокий уровень производительности, но программная гарантия есть только на Azure Pack Infrastructure).
Какой сервис выбрать? Если задача требует максимальной предсказуемости бизнес-приложений, нужно использовать Azure Pack Infrastructure (а еще на эту платформу при регистрации сейчас действует скидка 50% на первые 6 месяцев). Для веб-сайтов лучше всего себя показывает Virtuozzo Infrastructure, сочетая высокую производительность, гибкость и возможности автомасштабирования. Если цель: максимальная экономия, нужно использовать VPS от Infobox.
Анализ производительности виртуальной машины в VMware vSphere. Часть 1: CPU
Если вы администрируете виртуальную инфраструктуру на базе VMware vSphere (или любого другого стека технологий), то наверняка часто слышите от пользователей жалобы: «Виртуальная машина работает медленно!». В этом цикле статей разберу метрики производительности и расскажу, что и почему «тормозит» и как сделать так, чтобы не «тормозило».
Буду рассматривать следующие аспекты производительности виртуальных машин:
Для анализа производительности нам понадобятся:
Немного теории
В ESXi за работу каждого vCPU (ядра виртуальной машины) отвечает отдельный процесс – world в терминологии VMware. Также есть служебные процессы, но с точки зрения анализа производительности ВМ они менее интересны.
Процесс в ESXi может находиться в одном из четырех состояний:
Основные счетчики производительности 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 на основе данных из графика ниже. (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 должен быть близок к нулю.
В данном случае нагрузка явно ненормальная:)
Что делать? Если на одном гипервизоре работают несколько ВМ с большим количеством ядер и есть переподписка по CPU, то счетчик co-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% времени на обоих потоках физического ядра сервера, при этом ядро работает на номинальной частоте, то:
В ESXTOP также есть экран с параметрами энергопотребления CPU сервера. Здесь можно посмотреть, используются ли сервером технологии энергосбережения: C-states и P-states. Вызывается клавишей «p»:
Стандартные проблемы производительности CPU
Напоследок пробегусь по типичным причинам возникновения проблем с производительностью CPU ВМ и дам короткие советы их решению:
Не хватает тактовой частоты ядра. Если нет возможности перевести ВМ на более производительные ядра, можно попробовать изменить настройки энергопотребления, чтобы Turbo Boost работал эффективнее.
Неправильный сайзинг ВМ (слишком много/мало ядер). Если поставить мало ядер, будет высокая загрузка CPU ВМ. Если много, словите высокий co-stop.
Большая переподписка по CPU на сервере. Если на ВМ высокий Ready, снизьте переподписку по CPU.
Неправильная NUMA-топология на больших ВМ. NUMA-топология, которую видит ВМ (vNUMA), должна соответствовать NUMA-топологии сервера (pNUMA). Про диагностику и возможные варианты решения данной проблемы написано, например, в книге «VMware vSphere 6.5 Host Resources Deep Dive». Если не хотите углубляться и у вас нет лицензионных ограничений по ОС, установленной на ВМ, делайте на ВМ много виртуальных сокетов по одному ядру. Много не потеряете 🙂
На этом про CPU у меня все. Задавайте вопросы. В следующей части расскажу про оперативную память.