Vmware лагает виртуальная машина
Как ускорить работу виртуальной машины
Тем не менее, грамотная оптимизация BM позволит вам увеличить производительность последней без оказания существенного влияние на хостовой компьютер.
Фиксированный размер диска
Используйте фиксированный размер виртуального диска.
Большинство систем виртуализации по умолчанию создают динамические диски, увеличивающиеся по мере «разрастания» установленной на них операционной системы. С одной стороны, использования такого типа контейнеров позволяет экономить место на физическом диске, однако установленная на динамический диск система работает медленнее, причем ее производительность падает с увеличением последнего.
Используйте дополнения гостевой ОС
Даже если вы не собираетесь пользоваться общими папками, буфером обмена и другими опциями расширения функциональности, не пренебрегайте установкой дополнений гостевой ОС, их инсталляция в систему обеспечивает более эффективное использование ресурсов хостовой машины.
Особенности использования антивирусов
Не устанавливайте в гостевую операционную систему антивирусных программ, в этом нет никакой необходимости, заботиться нужно о безопасности не виртуальной, а хостовой системы. Отключите в виртуальной ОС встроенную защиту, если не собираетесь использовать ее в рамках тестирования. Рекомендуем также добавить весь каталог с ВМ в исключения вашего антивируса.
Сканирование контейнера с ВМ не только замедляет ее работу, но и не приносит никакой пользы с точки обнаружения вредоносного ПО внутри виртуального контейнера.
Проверьте настройки виртуальной машины вручную
Что касается установленных по умолчанию параметров виртуальной машины, здесь нужно действовать по принципу «доверяй, но проверяй».
Зайдите в настройки вашей ВМ и и проверьте эти параметры:
Оперативная память
Увеличьте, если возможно, объем выделенной ОЗУ до 2 Гб.
Процессор
Выделите максимально допустимое количество ядер процессора и убедитесь, что в пункте PAE/NX стоит галочка. Если в вашей системе виртуализации доступны функции Nested VT-х/AMD-v, включите их, они улучшают виртуализацию.
Дисплей
Выделите виртуальной машине максимальный объем видеопамяти и включите, если выключено, ускорение 2D и 3D.
Установка виртуальной машины на SSD
Файл подкачки и автозагрузка
Не стоит пренебрегать и внутренней оптимизацией. Для увеличения производительности виртуальной машины используйте внутри нее файл подкачки, особенно на популярных Linux-системах. Размер файла свопа в данном случае определяется общими правилами.
К внутренней оптимизации также следует отнести отключение неиспользуемых элементов автозагрузки, визуальных эффектов, фоновых приложений, службы автоматического обновления системы и индексирования.
Vmware лагает виртуальная машина
Если бы ВМ не хватало процессора, то хост разогнался бы до номинальной мощности.
Вы ничего не пишите про память. Но,скорее всего, дело в » SATA».
Какие у вас задержки на диск (read/write latenc) в целом по хосту и в разрезе ВМ?
Опишите полную картину, сколько у вас запущено виртуальных машин и какая у них конфгурация по CPU, RAM и какие там операционные системы запущены
С учетом того, что у вас всего 8 Гб оперативной памяти и SATA диск, то рассчитывать вам на многое не получится 
Спасибо за отзывы. Сегодня на вопросы по конкретному серверу ответить не смогу, т.к. он используется сейчас не как esxi.
Но и вопросы не совсем в тему. Описанная мною ситуация типичная, много лет ее наблюдаю. Просто увидел место, где можно вопрос задать, решил воспользоваться.
При этом серверные функции гостевых ОС не тормозят, для них ESXi выделяет нормальные ресурсы, балансирует. Передача файлов по гигабитной сети на честный гигабит. На двух гостевых 2008R2 одного и того же хоста по десять и больше юзеров могли работать в специальном ПО и по RDP вообще без тормозов на прошлой работе. И железо, и дистрибутив ESXi были точно такие же.
Базовый траблшутинг в среде VMware vSphere или что делать, если тормозит ВМ
Что-то в последнее время технические статьи о виртуализации (да и не только о виртуализации) скатываются к формату «в новой версии ожидается такая фича». Складывается ощущение, что разбор механизмов и описание опыта, проблем и решений интересны только зарубежным экспертам. С другой стороны, есть такая проблема у экспертов — если что-то изучил, оно становится элементарным и воспринимается само собой разумеющимся, настолько, что писать об этом как-то глупо. Особенно если уже было кем-то описано где-то. Когда-то. На каком-то языке. Ниженаписанное — плод консолидации личных заметок, сначала предназначавшийся для личного упорядочивания мыслей, но наупорядочив значительный объём текста, подумал, что кому-то может пригодиться.
Типовая проблема «виртуализаторов» — владелец сервиса, заказчик или пользователь жалуется, что у него «тормозит» виртуальная машина. Так как виртуализация предполагает консолидацию большого количества ВМ на базе одного комплекта аппаратных ресурсов, переподписку (overprovision — когда мы предполагаем, что серверы не затребуют одновременно максимум своих ресурсов, а значит, например, в 40 ГБ физической памяти мы можем натолкать не 10 серверов по 4 ГБ RAM, а 15, используя Dynamic Memory), а кроме того, серверы могут тормозить и из-за ошибок в программных компонентах и их настройках, то каждый раз приходится решать за что хвататься и куда смотреть в первую очередь. Особенно, если с таким ёмким описанием проблемы, как «тормозит машина» не предоставлено никакой диагностической информации, как чаще всего и бывает. Под катом небольшое руководство для этого случая.
Конечно, всё зависит от специфичности реализации конкретной инфраструктуры, но практика показывает, что в большинстве случаев имеет смысл следующая последовательность анализа подсистем ВМ:
На практике, до 4-го этапа почти никогда не доходит, после третьего (а то и после первого) имеет смысл запускать (или запрашивать) параллельную диагностику гостевой ОС, но диски стоит проверить сразу — самая значительная часть инцидентов с жалобами на производительность связано с ними. Если, конечно, у вас не All-Flash массив.
А теперь чуть подробнее по каждому пункту.
1. Диски (подсистема хранения)
Самый ключевой тут показатель — это Latency. Задержка времени отклика. Она складывается из большого количества промежуточных элементов и зависит от большого количества факторов. Сюда входит время отклика гипервизора, время прохождения сигнала по кабелям и промежуточным устройствам (коммутаторы, адаптеры и контроллеры), время нахождения в очередях на всех этих устройствах, если нагрузка на них превышает норму и ещё некоторые нюансы, такие как повреждения оборудования. Однако, оставив нюансы для расширенной диагностики, требуемой в редких случаях, можно выделить простой общий показатель — время задержки от ВМ до дисков.
Perfomance Tab
(закладка Perfomance в vSphere Client и счетчики производительности).
Наиболее часто используемые счётчики группы Disk:
Highest Latency — норма до 10-15 мс. Если регулярно выше, надо что-то менять, хотя разовые пики не страшны;
Average write requests per second;
Average read requests per second.
Наиболее часто используемые счётчики группы Virtual Disk:
Read/Write latency;
Average number of outstanding read/write requests — количество одновременных IO-запросов (если их число держится выше 30 в сумме на датастор или на сервер, это будет приводить к дополнительным задержкам);
ESXTop
Консольная утилита ESX/ESXi. Выдаёт целую кучу диагностической информации об отдельно взятом ESXi. Базовую информацию по использованию можно получить, нажав h после запуска утилиты.
В плане диагностики дисковой подсистемы будет полезен контекст виртуальных дисков (нажать v) и контекст HBA-адаптеров (нажать d). В последнем случае стоит обратить внимание на следующие показатели:
KAVG (Kernel Latency Avg) — время отклика гипервизора (норма — до 1 мс);
DAVG (Device Latency Avg) — время отклика от HBA до дисков (норма — 10-15мс);
GAVG (Guest Latency Avg) — время отклика для гостевой системы = сумма KAVG и DAVG
Кстати, в этой же области исследований стоит сразу проверить нет ли у ВМ снапшота. А то и нескольких. Они могут стать проблемой не только паденрия производительности, но и сбоев операций резервного копирования, клонирования и миграции.
2. Процессор
Здесь аналогичный по важности дисковым задержкам показатель — CPU Ready. Также стоит обращать внимание на Used, Wait и Co-Stop. Мониторить можно также через Perfomance Tab или ESXtop.
CPU Ready (%RDY) — % времени, когда ВМ готова производить какие-то вычисления, но физические процессоры в данный момент заняты другими процессами (системными или другими ВМ) и vCPU виртуальной машины находятся в режиме ожидания. Нормой считается значение до 10%. При росте этого показателя выше 40% развивается высокая вероятность сбоев и зависаний гостевой ОС. Причиной вынужденного простоя может стать:
Wait (%WAIT) — % времени, в течение которого ВМ ждёт окончания какой-то активности VMkernel. Чаще всего это дисковая IO-активность. Высокие показатели этого счётчика могут говорить о недостаточно быстром отклике от датастора. Также проблему могут вызывать некорректная работа USB или COM-портов или виртуальный CD/DVD-приводы, в который замонтирован отсутствующий ныне ISO.
Used (%USED) — % времени, в течение которого машина реально работала. Если он около нуля, значит машина просто стоит или её пересайзили процессорами. Если он около 100 (на каждый vCPU), значит или недосайзили, или в ней что-то зациклилось (если она ещё и не откликается при этом), или сейчас там лопатится какой-то квартальный отчёт. Этот показатель стоит изучать при размышлении на тему «дать ли ВМ ещё процессоров, чтоб быстрее работала?». Если у неё 4 ядра и ни одно не задействовано более чем на 50%, то 8 ядер её скорее всего не ускорят. Возможно даже замедлят (см. CPU Ready).
Инструменты диагностики те же.
Perfomance Tab
Удобно, что можно посмотреть данные не только по машине в целом, но и по каждому ядру. Кроме того, доступна статистика за период. Однако, информация предоставляется не в процентах, а в миллисекундах. Так как данные собираются не в real-time, а за определённый интервал, отображается, сколько именно mc процессор находился в том или ином состоянии. Перевести в проценты можно разделив значение на длину интервала и умножив на 100%.
Пример: на рисунке диаграмма с интервалом 20 секунд (real-time), то есть 20 000 мс. То есть среднее CPU Ready будет 50288 / 20000 * 100% = 251.44%. Так как у машины 4 ядра, а не одно, то результат делим на 4 и получаем почти 63%. Машина очень страдает. А всё потому, что лежит на третьем уровне вложенности Resource Pools с низкими shares на каждом.
Ещё раз, формула преобразования: / / * 100%. Получается 5% на 1000 мс для одного ядра.
ESXTop
Тут значение указано сразу в %. Только оно указано сразу в сумме для всех ядер, так что не стоит пугаться чисел больше 100. Делите на количество vCPU машины.
3. Оперативная память
Базовая диагностика здесь простая — да или нет. Если есть факт balooning’а значит хосту не хватает памяти и процессы гостевых ОС страдают, потому что активно используется файл подкачки. Если есть факт свопинга на уровне гипервизора, надо срочно принимать меры — машина попавшая в своп впадает в кому в 100% случаев (по крайней мере моей практики). Вышеуказанные факты позволяют определить такие счётчики как
Balloon (MCTLSZ) — количество памяти, вытянутое baloon-драйвером из гостевых ОС.
4. Сеть
Чтобы проблемы были на уровне сети, в случае жалоб на отдельную виртуальную машину, я в своей практике помню только один случай — когда в VDI использовалась какая-то дешёвая веб-камера, гнавшая несжатый поток видео и забивавшая все 100 Мб/с.
Стоит мониторить такие счётчики:
Transmit Dropped Packets (%DRPTX) — количество (или процент в случае esxtop) отброшенных отправленных пакетов;
Receive Dropped Packets (%DRPRX) — количество (процент) отброшенных принятых пакетов.
Ненулевое их значение, возникающее на регулярной основе говорит о некорректной работе сетевых устройств или некорректной их настройке.
Для базовой диагностики, покрывающей более половины (пожалуй, до 90%) обращений или собственных потребностей при диагностике и тестировании, этого достаточно.
Как ускорить работу виртуальных машин VMware Workstation
10 способов, как можно ускорить работу с виртуальными машинами в среде гипервизора VMware Workstation.
VMware Workstation – один из лучших гипервизоров для Windows. Это не самая производительная, но самая стабильная программа, с помощью которой можно виртуально исследовать различные операционные системы (ОС). VMware не конфликтует с другими гипервизорами (как Microsoft Hyper-V), в ней всегда работают дополнения гостевых ОС и прочие функции (в отличие от нестабильной VirtualBox), она функциональная и настраиваемая. Ну а что касается производительности, то здесь можно кое-что предпринять. Как ускорить работу виртуальных машин (ВМ) VMware?
1. Аппаратная часть
При использовании любого гипервизора, как и в случае с физическим компьютером, аппаратная оптимизация первична, программная – вторична. Для работы с VMware не принципиально, но желательно иметь на борту физического компьютера четырёхъядерный процессор, чтобы двое ядер оставались хост-системе (основной ОС), а двое могли бы быть задействованы ВМ.
Для базовых целей типа исследования ОС и тестирования несложного софта будет достаточно 2 Гб оперативной памяти. Разве что гостевым Windows 8.1 и 10 можно выделить 3 Гб, если у физического компьютера имеется 6 или 8 Гб. Выделять больший объём без конкретных целей использования памяти нет надобности.
ВМ, размещённая на одном и том же HDD, где установлена хост-система, будет тормозить даже при мощном процессоре и отсутствии недостатка оперативной памяти. HDD – слабое звено в конфигурации и физических, и виртуальных компьютеров из-за медленной скорости чтения и записи данных. Если в наличии нет SSD, для размещения ВМ желательно выделить отдельный HDD – жёсткий диск, к которому не будет обращаться хост-система. Ну или пойти путём универсального аппаратного апгрейда – реализовать RAID 0 (как минимум). Без последнего задействовать два HDD в работе ВМ можно, если разбросать её файлы по разным дискам.
2. Файлы ВМ на разных HDD
При использовании ВМ и по завершении работы с ней происходит запись данных во все эти файлы. За исключением снапшотов, если они не задействуются. Чтобы распределить нагрузку, можно файл виртуального диска VMDK (или VHD) хранить на одном HDD, а файлы конфигурации ВМ – на другом HDD, в частности, на том же, где размещается хост-система. Для всех ВМ указываем расположение по умолчанию – каталог на одном HDD.
При создании же каждой отдельной ВМ используем выборочную настройку.
И на этапе задания параметров виртуального диска указываем его месторасположение на разделе другого HDD.
Применить такую схему к уже имеющихся ВМ можно путём удаления используемого виртуального диска в параметрах машины. А затем добавления этого же диска по-новому, когда его файл VMDK (или VHD) уже будет перемещён на другой HDD.
3. Фиксированные виртуальные диски
Немного ускорить работу ВМ на HDD можно путём работы с фиксированными, а не назначенными по умолчанию в VMware динамическими виртуальными дисками. Для этого при создании ВМ на этапе указания размера диска необходимо выбрать его сохранение в одном файле и установить галочку опции выделения всего места.
При таком раскладе будет создан виртуальный диск фиксированного типа. Его файл со старта займёт указанный объём, и ресурс HDD при непосредственной работе с ВМ не будет распыляться ещё и на операцию по выделению места на физическом диске.
4. Дефрагментация HDD
Ускорить работу ВМ на HDD можно традиционным методом оптимизации этого типа жёстких дисков – дефрагментацией. В среде хост-системы Windows желательно время от времени проводить эту процедуру с использованием эффективных сторонних программ.
5. Тормоза после приостановки ВМ
Работающие с VMware наверняка замечали, что в большинстве случаев после приостановки одной ВМ сразу же оперативно запустить другую нереально. Нужно немного подождать. Естественно, речь идёт о случаях расположения ВМ на HDD. Как только мы приостанавливаем ВМ, сразу же начинается активная запись данных на диск с его загрузкой вплоть до 100%. И так может длиться несколько минут. При приостановке ВМ содержимое оперативной памяти гостевой ОС каждый раз записывается в файл «.vmem». Он находится в числе прочих файлов конфигурации ВМ и планировано занимает столько места на диске, сколько машине выделено «оперативки». По факту же размер файла варьируется в зависимости от записанных в него в последний раз данных.
Активная запись в файл «.vmem» сильно нагружает HDD. Назначение такой операции – запуск гостевой ОС в сохранённом состоянии при возможных сбоях в работе ВМ. Нужна ли эта возможность такой ценой – решайте сами. Если не нужна, запись данных в файл «.vmem» можно отключить. И тем самым ускорить переключение между приостановленными ВМ. Для этого необходимо открыть в любом TXT-редакторе файл конфигурации ВМ «.vmx», дописать в конце такую строчку:
mainMem.useNamedFile = «FALSE»
6. Обрезка страничной памяти
В дополнительных параметрах ВМ есть изначально неактивная опция отключения обрезки страничной памяти. Если её активировать, фактическое выделение оперативной памяти ВМ будет происходить быстрее.
7. Плеер VMware
В состав компонентов VMware Workstation входит приложение Player. Это упрощённый вариант гипервизора, ограниченный функционально, но также и более лёгкий. Создавать и настраивать ВМ лучше, конечно же, с использованием основного компонента VMware Workstation. А вот непосредственно проводить работу с гостевыми ОС можно внутри более шустрого плеера.
8. ПО EFI
ВМ с ПО EFI эмулируют устройства, соответственно, с BIOS UEFI. Они включаются и перезапускаются немного быстрее, чем ВМ, эмулирующие устройства с обычным BIOS. Плюс к этому, EFI-машины могут быть запущены с UEFI-флешек без помощи сторонних средств.
9. Оптимизация гостевых ОС
Ускорить работу ВМ можно за счёт оптимизации гостевых Windows. В числе таковых в частности: отключение анимации, обоев, неиспользуемых служб, телеметрии, обновлений, Timeline (для версии 10). В качестве платформы для тестирования только стороннего софта можно и вовсе в качестве гостевой ОС выбрать Windows 7 или 8.1 Embedded – урезанные сборки этих версий, заточенные под работу со слабым железом.
В гостевых Windows можно смело работать с отключённым Защитником и без стороннего антивируса. За безопасность будет отвечать антивирус хост-системы. А вот для последней желательно подобрать такой антивирусный продукт, чтобы защищал, но при этом не мешал.
10. Правильный антивирус для хост-системы
Активность ВМ – это непаханое поле азарта для антивирусов. VMware Workstation, как и любой другой гипервизор, активно работает с записью данных. Причём работает с большими объёмами данных. И все эти данные антивирусы проверяют в рамках проактивной защиты. Чтобы не создавать лишней нагрузки при работе с ВМ, для хост-системы желательно подобрать хороший антивирус – эффективный в плане обнаружения реальных угроз, при этом минимально использующий аппаратные ресурсы компьютера.
Анализ производительности виртуальной машины в 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 у меня все. Задавайте вопросы. В следующей части расскажу про оперативную память.