Vmware лагает виртуальная машина
Скорее всего, вы выбрали VMware vSphere в качестве решения для виртуализации из-за его репутации надежного и производительного продукта; однако без должного внимания и оптимизации вы не сможете полностью использовать возможности платформы. Существует множество оптимизаций, которые можно сделать, чтобы ваша установка vSphere работала на оптимальном уровне. В этой статье рассматриваются 30 советов и рекомендаций, которые обеспечат наилучшую производительность VMware vSphere, а некоторые даже применимы к другим продуктам виртуализации.
Добавьте папку с виртуальной машиной в исключения вашей антивирусной программы
Антивирусная программа кроме прочих, также сканирует файлы виртуальной машины, что снижает её производительность. Но дело в том, что антивирусная программа не имеет доступа к файлам внутри гостевой операционной системы виртуальной машины. Поэтому такое сканирование бессмысленно.
Чтобы избавится от снижения производительности виртуальной машины, можно добавить папку с ней в исключения антивирусной программы. Антивирус будет игнорировать все файлы такой папки.
Установите и используйте новейшие версии VMware Tools на каждой гостевой операционной системе
VMware Tools обновляет драйвера и добавляет улучшения, отсутствующие на стоковых драйверах гостевых операционных систем. Важно обновлять программное обеспечение хоста при каждом обновлении VMware Tools.
Дополнительные компоненты, особенно графические, лишь пожирают ресурсы и зачастую не приносят пользы в серверной среде, а иногда создают уязвимости в защите системы. При отсутствии необходимости использования на сервере графических приложений рекомендуется отключать заставки, оконные системы, оконные анимации и прочее.
Используйте NTP для учёта гостевого времени
Это не самый важный совет по производительности, но использование временного сетевого протокола ( NTP ) обеспечивает надёжное ведение системных журналов и поможет при возникновении проблем с безопасностью и производительностью.
Заключение
Все эти советы являются лишь верхушкой айсберга. Я настоятельно рекомендую изучить советы по вашим потребностям, прочитав официальную документацию VMware. Также заглядывайте в наш раздел по виртуализации , там много полезных материалов.
Проблемы с производительностью виртуальной машины на ESX/ESXi могут быть вызваны по различным причинам, например, ограничения в работе CPU, излишний объём памяти, задержкой в работе хранилищ или сети. Если одна или более из ваших виртуальных машин показывает высокое время ответа, то проверьте каждую из возможных причин, чтобы выявить слабое место системы.
- Сервисы на гостевых виртуальных машинах работают медленно
- Приложения на гостевых виртуальных машинах отвечают с задержкой
- Гостевая виртуальная машина работает медленно или не отвечает
Обеспечить виртуальные среды только требуемыми ресурсами
Это может показаться нелогичным, но наличие лишних ресурсов для виртуальных машин в системах виртуализации накладывает ограничения на их производительность. Так, VMware хорошо справляется с системами, перегруженными количеством виртуальных машин, и хуже с машинами с избыточным количеством ресурсов. При запуске системы используйте рекомендуемые настройки или настройки по умолчанию для памяти, хранилищ и остального, далее изменяйте их лишь при необходимости. Консоль управления сообщит о проблемах с ресурсами, и вы сможете реагировать на предупреждения при необходимости.
Отключайте пользователей vSphere от vCenter, если они больше не нужны
Множество подключённых к VMware vCenter пользователей понижает производительность, что можно увидеть на консоли. В любом случае, vSphere продолжит работу даже при превышении количества рекомендованных/поддерживаемых пользователей, но со значительным падением производительности.
Приостановка вместо закрытия
Когда вы закончили работать с виртуальной машиной, её можно приостановить вместо полного выключения.
Запуская приложение для работы с виртуальными машинами следующий раз, вы можете включить виртуальную машину таким же способом как обычно. Но она загрузится значительно быстрее и именно в том состоянии и с того места, на котором вы закончили работать прошлый раз.
Приостановка гостевой операционной системы очень похожа на использование гибернации вместо выключения ПК.
Следите за потреблением CPU в среде хоста
Постоянно следите с помощью консоли за потреблением CPU всей системой виртуализации, это позволит заметить перегрузку системы. В этом случае вы можете переместить VM другому хосту в вашей системе, перенести ресурсы на менее загруженный хост или выключить неиспользуемую или ненужную VM. Основное правило использования VMware гласит: если средняя загрузка системы равна количеству физических процессоров в системе, то вы выделяете лишние ресурсы, а на вашем сервере находится слишком много гостей.
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). Очевидно, этого можно добиться, уменьшив параметры существующих ВМ или путем миграции части ВМ на другие серверы.
Используйте VMXNET3 в виртуальных сетевых адаптерах на гостях, которые это поддерживают
VMXNET3 снижает затраты на передачу траффика между виртуальной машиной и физической сетью. Они известны как паравиртуализированные сетевые адаптеры и могут обеспечить значительное повышение производительности для большей части рабочих нагрузок.
Виртуальная машина и SSD диск
Первым и лучшим усовершенствованием компьютера на сегодняшний день является установка на него SSD диска. Это ощутимо ускорит работу компьютера, а соответственно и установленной на нём виртуальной машины.
Некоторые пользователи устанавливают виртуальные машины на другой (HDD) диск своего компьютера, оставляя на SSD диске лишь основную операционную систему. Это делает работу виртуальной машины медленнее. Освободите место на SSD диске и перенесите виртуальную машину на него. Разница в скорости работы почувствуется с первых минут.
По возможности, не размещайте диски виртуальных машин на внешних носителях информации. Они работают ещё медленнее чем встроенный HDD диск. Возможны варианты с подключением виртуальной машины через USB 3.0, но о USB 2.0 и речи быть не может – виртуальная машина будет работать очень медленно.
Используйте только те гостевые операционные системы, которые поддерживаются vSphere
VMware оптимизирует свои хост платформы для работы с определёнными операционными системами и использование несертифицированных операционных систем может повлечь проблемы с поддержкой и производительностью в рабочей среде.
Объединения сетевых интерфейсных карт повышают отказоустойчивость
Объединённые сетевые интерфейсные карты позволяют сетевым адаптерам работать сообща, что обеспечивает более стабильное соединение и лучшую отказоустойчивость. При отказе сетевого интерфейса или возникновении проблемы другие соединённые сетевые интерфейсы автоматически устранят дыру в системе и обеспечат плавное возвращение к нормальной работе.
Основные счетчики производительности CPU виртуальной машины
CPU Usage, %. Показывает процент использования CPU за заданный период.
Как анализировать? Если ВМ стабильно использует CPU на 90% или есть пики до 100%, то у нас проблемы. Проблемы могут выражаться не только в «медленной» работе приложения внутри ВМ, но и в недоступности ВМ по сети. Если система мониторинга показывает, что ВМ периодически отваливается, обратите внимание на пики на графике CPU Usage.
Есть стандартный Аlarm, который показывает загрузку CPU виртуальной машины:
Что делать? Если у ВМ постоянно зашкаливает CPU Usage, то можно задуматься об увеличении количества vCPU (к сожалению, это не всегда помогает) или переносе ВМ на сервер с более производительными процессорами.
Перегрузка памяти
Чтобы определить является ли причиной низкой производительности перегрузка памяти необходимо:
- Ввести команду esxtop и установить перегружена ли память ESXi/ESX server. Изучите MEM overcommit avg в первой строке вывода команд. Это значение отражает соотношение требуемого объёма памяти к объёму доступной памяти, минус 1.Пример
Если виртуальной машине требуется 4 ГБ ОЗУ и хост имеет 4 ГБ ОЗУ, то соотношение равно 1:1. После вычитания 1 (из 1:1) поле MEM overcommit avg выдаст значение 0. Память не перегружена и нет необходимости в дополнительном объёме. Если виртуальной машине требуется 6 ГБ ОЗУ и хост имеет 4 ГБ ОЗУ, то соотношение равно 1.5:1. После вычитания 1 (из 1:1) поле MEM overcommit avg выдаст значение 0. Память перегружена на 50% и необходимо на 50% больше ОЗУ, чем доступно.Если память перегружена, то следует отрегулировать количество памяти хоста. Для этого необходимо:Увеличить количество физической ОЗУ хоста
Или уменьшить количество памяти, выделяемое виртуальным машинам. Для уменьшения объёма выделенной ОЗУ нужно уменьшить общее количество ОЗУ, выделенной всем виртуальным машинам хоста
Или уменьшить общее количество виртуальных машин хоста. - Определить состояние виртуальных машин: ballooning или swappingДля определения состояния:Запустите esxtop
Введите m для памяти
Введите f для полей
Выберите букву J для Memory Ballooning Statistics (MCTL)
Посмотрите на значение MCTLSZ. MCTLSZ (MB) отображает количество физической памяти гостя, переданной balloon driver.
Введите f для поля
Выберите букву для Memory Swap Statistics (SWAP STATS)
Посмотрите на значение SWCUR. SWCUR (MB) отражает текущую загрузку свопа
Для решения этой проблемы убедитесь, что ballooning или swapping не вызваны неправильно заданным объёмом памяти. Если объём памяти задан неверно, то его следует переназначить
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, корректная настройка энергопотребления может значительно улучшить их производительность.
Улучшение производительности внутри виртуальной машины
Всегда необходимо помнить, что установленная на виртуальную машину операционная система мало чем отличается от той, которая работает на основном компьютере. Её работу можно ускорить, следуя тем же принципам и используя те же методы, которые актуальны для любой другой операционной системы.
Например, производительность системы увеличится если закрыть фоновые программы или те, которые автоматически запускаются при старте системы. На производительность системы влияет необходимость осуществления дефрагментации диска (если виртуальная машина расположена на HDD диске), и так далее.
Минимизируйте потребление приложениями, постоянно открывающими и закрывающими файлы, или создайте расписание для снижения нагрузки от ввода/вывода на диск
Чтение и запись являются наиболее дорогими операциями в вычислениях. Для наиболее эффективного использования ресурсов следует распределить отложенные задачи и сложные операции ввода/вывода на периоды низкой загруженности системы и сети. Осуществление программного ввода/вывода во время пиковых нагрузок влечёт за собой многочисленные и серьёзные падения производительности.
Включите Hyper-Threading, если он поддерживается оборудованием
Hyper-Threading это технология, разработанная для обеспечения непрерывного потока инструкций, подаваемых на процессор. Множество процессоров позволяет множеству инструкций быть обработанным одновременно, а HT уменьшает время простоя процессора и предоставляет больший объём работы на каждый такт. Не существует определённого быстрого правила для повышения производительности, используя HT, но это может увеличивать производительность некоторых приложений более чем в два раза.
Используйте сетевые карты серверного сегмента
Не все сетевые карты одинаковы; встроенные адаптеры больше подходят для нужд рядовых пользователей. Для корпоративных серверов стоит использовать серверные NIC (сетевые карты), поддерживающие контрольные суммы разгрузки, сегментной разгрузки TCP, обработку 64-битных DMA адресов, способность рассеивать и собирать элементы, встречающиеся множество раз в одном кадре и Jumbo-кадре. Эти функции позволяют vSphere использовать встроенную продвинутую поддержку сети.
Установка пакета инструментов виртуальной машины
После установки на виртуальную машину гостевой операционной системы, первое, что необходимо сделать – это установить пакет инструментов или драйверов вашей виртуальной машины, например: VirtualBox Guest Additions или VMware Tools. Такие пакеты содержат драйвера, которые помогут гостевой операционной системе работать быстрее.
Установить их просто. В VirtualBox, загрузите гостевую операционную систему и выберите Устройства / Подключить образ диска Дополнительной гостевой ОС… После чего запустите установщик, который появится как отдельный диск в папке «Этот компьютер» гостевой операционной системы.
В VMware Workstation, выберите меню Виртуальная машина / Установить паке VMware Tools… После чего запустите установщик, который появится как отдельный диск в папке «Этот компьютер» гостевой операционной системы.
Задержки в работе хранилища
Чтобы определить являются ли задержки в работе хранилища причиной низкой производительности: Проверьте связаны ли проблемы с локальным хранилищем. Перенесите виртуальные машины в другое хранилище.
- Уменьшите количество виртуальных машин на LUN.
- Поищите похожие записи на Windows гостей: The device, \Device\ScsiPort0, did not respond within the timeout period
- Используя esxtop найдите высокое время задержки DAVG.
- Определите максимальную пропускную способность ввода/вывода с помощью команды iometer.
- Сравните результаты iometer, полученные на VM, с результатами физической машины с этим же хранилищем.
- Проверьте наличие конфликтов с резервированием SCSI.
- Если вы используете iSCSI хранилище и Jumbo фреймы, то следует проверить правильность конфигурации.
- При использовании iSCSI хранилища и многоканального iSCSI Software Initiator убедитесь, что всё правильно сконфигурировано.
Если вы обнаружили проблемы, связанные с хранилищем:
- Убедитесь в том, что ваша аппаратура и HBA карты сертифицированы для работы с ESX/ESXi.
- Проверьте обновления вашего физического сервера.
- Проверьте обновления прошивки вашего HBA.
- ESX верно определяет режим и политику пути для вашего SATP Storage вашего типа и PSP Path Selection.
Решение
Каждый нижестоящий шаг содержит инструкции и ссылки на соответствующие документы. Шаги выстроены в наиболее удобном порядке для выявления и решения проблемы. Такая последовательность также обеспечивает наименьшую потерю данных.
Замечание: после завершения каждого шага отмечайте сохраниться ли проблема с производительностью. Не пропускайте шаги и выполняйте их в указанном порядке.
Статья включает в себя 4 основных части:
- Ограничения в работе CPU
- Излишний объём памяти
- Задержка в работе хранилища
- Сетевые задержки
30 полезных лайфхаков в VMware для админа
Правильные настройки видео
На скорость работы виртуальной машины могут также влиять настройки видео. Например, включение 2D или 3D-ускорения видео в VirtualBox, позволяет работать некоторым приложениям значительно быстрее. То же касается и возможности увеличения видеопамяти.
Но, как и в случае с оперативной памятью, многое зависит от видеоадаптера, который установлен на основном компьютере.
Проведите стресс-тест или проверку оборудования перед вводом в эксплуатацию
Собирая или покупая новую систему полезно провести глубокий стресс-тест или проверку системы. Существует множество программ для этого и многие из них доступны для загрузки с CD-диска для запуска системы в любом состоянии. Это поможет найти неисправные компоненты и обеспечит надёжность платформы во время работы.
Выберите подходящее приложению внутреннее хранилище
Существует множество различных систем внутренних хранилищ и выбор может обеспечить огромное влияние на производительность вашей системы. Дисковый ввод/вывод является одним из главных препятствий в сфере компьютерного оборудования и имеет один из самых низких показателей роста. Выбор устройства внутреннего хранилища и его конфигурация зависит от типа используемого приложения. Например, продукты SATA сами по себе не могут обеспечить высокую скорость записи на диск больших объёмов данных в научном оборудовании. При необходимости высокой скорости или большого объёма хранилища стоит посмотреть на более надёжные и эффективные носители информации, такие как iSCSI или NFS . Для корректной работы ваше хранилище должно поддерживать требуемый объём данных или скорость чтения/записи для ваших приложений, в том числе требования для работы операционной системы хоста и самой платформы vSphere.
Распределите операции ввода/вывода между адаптерами и путями хранилищ
При наличии множества адаптеров хранилищ или путей хранилищ (в одной сети) следует распределять нагрузку между ними во избежание перегрузки слоя ввода/вывода. Ввод/вывод является одной из наиболее важных частей системы и влияет на производительность. Поскольку устройства и контроллеры хранилищ неидеальны и последними пользуются достижениями технологий, то следует использовать все возможные пути для повышения производительности.
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% – ядро ВМ все время находится в каком-то из этих четырех состояний.
Динамический или фиксированный виртуальный жесткий диск?
Создавая виртуальную машину, можно создать два разных типа виртуальных жестких дисков. По умолчанию виртуальная машина использует динамический диск, который занимает необходимое место на физическом носителе информации и увеличивается лишь по мере заполнения.
Например, создавая виртуальную машину с динамическим диском в 30 ГБ, он не займёт сразу же 30 ГБ жесткого диска компьютера. После установки операционной системы и необходимых программ его размер будет порядка 10-15 ГБ. Лишь по мере добавления данных, он может увеличиться до 30 ГБ.
Это удобно с той точки зрения, что виртуальная машина будет занимать на жестком диске место, которое пропорционально объёму хранимых на ней данных. Но, работа динамического жесткого диска медленнее фиксированного (иногда также называют распределённым).
Создавая фиксированный диск, все 30 ГБ на жестком диске компьютера будут выделены под диск виртуальной машины сразу же, независимо от объёма хранимых на нём данных. То есть, фиксированный жесткий диск виртуальной машины занимает больше места жесткого диска компьютера, но сохранение или копирование файлов и данных на нём происходит быстрее. Он не так сильно подвержен фрагментации, так как пространство под него выделяется максимально большим блоком, вместо того, чтобы добавляться маленькими частями.
Используйте поддерживающие wake-on-LAN хосты для облегчения контроля питанием
Если ваши сетевые адаптеры поддерживают wake-on-LAN, то рассмотрите возможность использования этой функции, она позволит vSphere помогать в управлении питанием.
Группируйте виртуальные машины в пул ресурсов тогда, когда это применимо
Группируя виртуальные машины в один логический набор, вы можете повысить приоритет на выделение ресурсов группам, а не отдельным машинам. Это также позволит гостям в группе совместно использовать ресурсы и поможет сбалансировать нагрузку.
Группируйте системы, взаимодействующие друг с другом на одном свитче
Размещая системы, взаимодействующие друг с другом на постоянной основе, вы избежите возникновение перегрузок в системе. Если же системы находятся на разных виртуальных свитчах, то для взаимодействия друг с другом трафик должен выйти из системы, покинуть текущий свитч и потом пройти по сети, чтобы достигнуть другой системы.
Отключайте неиспользуемое и ненужное виртуальное или физическое оборудование от VM
Отключая устройства, вы освобождаете ресурсы прерывания. Также повышается производительность после отключения устройств, потребляющих дополнительные ресурсы из-за запросов, такие как USB адаптеры и PCI устройства, которые резервируют блоки памяти под свои операции. Используя гостевой режим Windows, убедитесь, что оптические приводы отключены, потому что Windows постоянно запрашивает их, что может вызвать проблемы, особенно при множестве гостей (гостевых ОС), работающих одновременно.
Программы для работы с виртуальными машинами
Одни пользователи уверяют, что Oracle VirtualBox самый быстрый инструмент для работы с виртуальной машиной, для других – VMware Workstation или Microsoft Hyper-V . Но то, как быстро будет работать виртуальная машина на конкретном компьютере зависит от множества факторов: это и версия гостевой операционной системы, её тип, настройки системы и виртуальной машины, производительность самого компьютера, и пр. В любом случае, всегда можно испробовать другую программу.
Если вы администрируете виртуальную инфраструктуру на базе VMware vSphere (или любого другого стека технологий), то наверняка часто слышите от пользователей жалобы: «Виртуальная машина работает медленно!». В этом цикле статей разберу метрики производительности и расскажу, что и почему «тормозит» и как сделать так, чтобы не «тормозило».
Буду рассматривать следующие аспекты производительности виртуальных машин:
Для анализа производительности нам понадобятся:
Другие полезные метрики 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 поговорим в статье про счетчики оперативной памяти.
Ограничьте использование виртуальных процессоров (CPU) приложениями
Если вы используете однопоточные или приложения плохо спроектированные для многопоточной работы и параллелизма, то использование виртуальных процессоров (CPU) бесполезно. Неиспользуемые виртуальные процессоры (CPU) продолжают использовать ресурсы даже когда не используются системой.
Оптимизируйте настройки BIOS серверов
Производители материнских плат поставляют свои продукты с BIOS для работы с различными конфигурациями, поэтому они не способны оптимизировать материнскую плату для работы с конкретно вашей конфигурацией. Следует постоянно обновлять BIOS до последней версии и включать используемую vSphere аппаратную поддержку, например, Hyperthreading, “Turbo Mode”, VT-x, AMD-V, EPT, RVI и другие. Также следует отключить энергосбережение, чтобы исключить негативное влияние на производительность сервера.
Используйте только совместимое с VMware оборудование
У VMware существует список совместимого оборудования для каждой версии платформы vSphere. Перед покупкой или эксплуатацией оборудования необходимо удостовериться, что все компоненты совместимы и поддерживаются. Также нужно проверить соответствие оборудования минимальным требованиям для правильной установки и эксплуатации.
Выделить больше CPU
Основная нагрузка при работе виртуальной машины, приходится на центральный процессор. Таким образом, чем больше мощности центрального процессора виртуальная машина может занять, тем лучше (быстрее) она будет работать.
Если виртуальная машина установлена на компьютере с мульти-ядерным процессором, то в настройках виртуальной машины для неё можно выделить несколько ядер для её работы. Виртуальная машина на двух и более ядрах центрального процессора будет работать ощутимо быстрее чем на одном.
Установка виртуальной машины на компьютере с одноядерным процессором нежелательна. Работать такая виртуальная машина будет медленно и выполнение ею каких-либо задач будет не эффективным.
Убедитесь, что гостевые разделы выравнены
Большинство дисковых файловых систем теряют производительность, если дисковые разделы не выравнены. Процедура выравнивания различается от производителя к производителю.
Немного теории
В ESXi за работу каждого vCPU (ядра виртуальной машины) отвечает отдельный процесс – world в терминологии VMware. Также есть служебные процессы, но с точки зрения анализа производительности ВМ они менее интересны.
Процесс в ESXi может находиться в одном из четырех состояний:
- Run – процесс выполняет какую-то полезную работу.
- Wait – процесс не выполняет никакой работы (idle) либо ждет ввода/вывода.
- Costop – состояние, которое возникает в многоядерных виртуальных машинах. Оно возникает, когда планировщик CPU гипервизора (ESXi CPU Scheduler) не может запланировать одновременное исполнение на физических ядрах сервера всех активных ядер виртуальной машины. В физическом мире все ядра процессора работают параллельно, гостевая ОС внутри ВМ рассчитывает на аналогичное поведение, поэтому гипервизору приходится замедлять ядра ВМ, у которых есть возможность закончить такт быстрее. В современных версиях ESXi планировщик CPU использует механизм, который называется relaxed co-scheduling: гипервизор считает разрыв между самым «быстрым» и самым “медленным" ядром виртуальной машины (skew). Если разрыв превышает определенный порог, «быстрое» ядро переходит в состояние costop. Если ядра ВМ проводят много времени в этом состоянии, это может вызвать проблемы с производительностью.
- Ready – процесс переходит в данное состояние, когда у гипервизора нет возможности выделить ресурсы для его исполнения. Высокие значения ready могут вызвать проблемы с производительностью ВМ.
Отключайте неиспользуемые виртуальные машины
Даже неиспользуемые виртуальные машины потребляют ресурсы. Это не обеспечит огромный прирост производительности, но окажет своё влияние. Вы всегда можете перезапустить гостя, когда появится необходимость в системе.
Включайте Fault Tolerance, только если вы собираетесь использовать эту функцию
Выключите Fault Tolerance , функцию vSphere направленную на работу с гостями, если не будете использовать её, так как для работы она требует значительное количество памяти, потребление процессора (CPU) и операций ввода/вывода на диске.
Старайтесь использовать новейшее оборудование с аппаратной виртуализацией
Последние процессоры AMD и Intel поддерживают функции оборудования по содействию виртуализации VMware. Эти функции бывают двух видов: процессорная виртуализация и виртуализация управления памятью.
Активация Intel VT-x или AMD-V
Intel VT-x и AMD-V – это специальные технологии виртуализации, которые предназначены для обеспечения большей производительности виртуальных машин. Современные процессоры Intel и AMD, как правило обладают такой функцией. Но на некоторых компьютерах она автоматически не активирована. Чтобы её включить, необходимо перейти в BIOS компьютера и активировать её вручную.
AMD-V часто уже активирована на ПК, если поддерживается. А Intel VT-x чаще всего отключена. Поэтому, убедитесь в том, что указанные функции виртуализации уже активированы в BIOS, после чего включите их в виртуальной машине.
Группируйте схожие виртуальные машины при использовании VMware Distributed Resource Scheduler (для распределения ресурсов CPU и памяти)
Группировка машин со схожими конфигурациями процессоров (CPU) и памяти позволит определять машины как одно целое и это облегчит работу vSphere по поддержанию стабильной работы.
Сетвые задержки
Производительность сети тесно связана с производительностью CPU. Поэтому сначала необходимо проверить работу CPU и после этого переходить к поиску проблем в сети. Для определения проблем с производительностью сети:
Проверьте максимальную пропускную способность от виртуальной машины с помощью Iperf .
Во время использования Iperf измените размер окна TCP до 64 K. Это также влияет на производительность. Для изменения размера окна TCP:
В данной статье мы рассмотрим несколько способов повышения производительности виртуальной машины VMware Workstation, Oracle VirtualBox, Microsoft Hyper-V или любой другой. Виртуальные машины довольно требовательны к характеристикам компьютера, ведь во время их работы на ПК одновременно запущено несколько операционных систем. Как результат, виртуальная машина может быть значительно медленнее основной операционной системы или вообще работать с притормаживанием.
В данной статье мы рассмотрим несколько способов повышения производительности виртуальной машины VMware Workstation , Oracle VirtualBox, Microsoft Hyper-V или любой другой.
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, выбирайте размер ВМ в соответствии с рекомендациями производителя ПО, которое работает на этой ВМ, и с возможностями физического сервера, где работает ВМ.
Не добавляйте ядра про запас, это может вызвать проблемы с производительностью не только самой ВМ, но и ее соседей по серверу.
Выбирайте подходящие приложениям файловые системы и типы виртуальных дисков
Типы виртуальных дисков и файловых систем предлагают различные профили производительности, поэтому стоит выбирать на основе потребностей ввода/вывода отдельных ваших приложений. Для приложения, которое постоянно записывает данные на диск, лучшим выбором будет оптимизированная под запись файловая система и соответствующий виртуальный диск.
Используйте хотя бы гигабитную сетевую инфраструктуру
Сейчас сетевое оборудование и кабели к нему стоят дёшево, поэтому нет смысла в использовании сетевых инфраструктур с пропускной способностью ниже гигабита. Если вы можете позволить это или испытываете особую потребность в этом, то вы можете предпочесть более высокоскоростные волоконно-оптические технологии передачи и носителей данных, чтобы обеспечить быструю и надёжную работу с возможностью для роста и потенциала.
30 полезных лайфхаков в VMware для админа
Обеспечьте хосту объём памяти, необходимый для работы с гостями и консолью
Чтобы выбрать количество физической памяти для хоста системы и количества гостей, необходимо посчитать общее количество памяти, необходимой каждой VM. Также нужно добавить память в буффер для расхода самой VM и потребления vSphere. Чтобы исключить ошибку с нехваткой памяти, следует добавить чуть больше физической памяти, чем этого требуется.
Стандартные проблемы производительности CPU
Напоследок пробегусь по типичным причинам возникновения проблем с производительностью CPU ВМ и дам короткие советы их решению:
Не хватает тактовой частоты ядра. Если нет возможности перевести ВМ на более производительные ядра, можно попробовать изменить настройки энергопотребления, чтобы Turbo Boost работал эффективнее.
Неправильный сайзинг ВМ (слишком много/мало ядер). Если поставить мало ядер, будет высокая загрузка CPU ВМ. Если много, словите высокий co-stop.
Неправильная NUMA-топология на больших ВМ. NUMA-топология, которую видит ВМ (vNUMA), должна соответствовать NUMA-топологии сервера (pNUMA). Про диагностику и возможные варианты решения данной проблемы написано, например, в книге «VMware vSphere 6.5 Host Resources Deep Dive». Если не хотите углубляться и у вас нет лицензионных ограничений по ОС, установленной на ВМ, делайте на ВМ много виртуальных сокетов по одному ядру. Много не потеряете :)
На этом про CPU у меня все. Задавайте вопросы. В следующей части расскажу про оперативную память.
Практика показывает, что любой процесс, в определенной степени, всегда можно оптимизировать. Это вполне можно отнести и к виртуализации. Возможностей оптимизации тут достаточно много, и задача эта многогогранна.
В пределах данной статьи я хочу ознакомить вас с методиками сайзинга виртуальных машин, а так же о методах оптимизации их работы. Материал будет техническим и рекомендуется к ознакомлению всем специалистам по vSphere.
Для начала хотелось бы рассказать о двух технологиях, основным образом влияющих на производительность vSphere. Это технология NUMA и технология работы шедулера гипервизора ESXi.
Про NUMA существует достаточно много подробных статей, пересказывать эту информацию не вижу смысла, ограничусь лишь базовым описанием для целостности материала. Итак, NUMA – Non Uniform Memory Access. На русский язык это можно перевести как Неравноценный Доступ к Памяти.
Современные многосокетные сервера, по сути, представляют собой несколько изолированных односокетных компьютеров, объединенных на одной материнской плате. Каждый процессор монопольно владеет своими слотами оперативной памяти, и только он имеет к ней доступ. Аналогично, каждый процессор имеет свои персональные PCI-E шины, к которым подключены различные устройства материнской платы, а так же слоты расширения PCI-E. Процессоры соединены между собой высокоскоростной шиной обмена данными, по которой они получают доступ к «чужим» устройствам, делая запрос на это соответствующему процессору-хозяину. По понятным причинам, доступ процессора к «своей» памяти происходит гораздо с меньшими накладными расходами, чем к «чужой». Пока это все, что необходимо знать о данной технологии.
vSphere прекрасно знает про NUMA и старается размещать виртуальные ядра машин на тех физических процессорах, в чьей памяти сейчас находится оперативная память виртуальной машины. Но тут возникают подводные камни. Производители серверов любят включать в BIOS по умолчанию эмуляцию NUMA. То есть сервер представляется операционной системе как НЕ NUMA устройство, и vSphere не может использовать свою оптимизацию для управления данной технологией. В документации по vSphere рекомендуется отключать (Disable) данную опцию в BIOS, это позволяет vSphere самостоятельно разбираться с вопросом.
Рассмотрим потенциальные проблемы, которые могу возникнуть с NUMA. Предполагаем, что vSphere его видит и корректно с ним работает. Для примера будем рассматривать 2-процессорную систему, как самый простой вариант NUMA. Предположим, что на физическом сервере 64 GB оперативной памяти, по 32 на каждом сокете.
Хотелось бы отметить, что vSphere имеет свою четкую логику при работе с NUMA и Hyperthreading.
Если у ВМ всего 1 виртуальный сокет, то при увеличении vCPU, исполнение машины будет производиться на одном физическом процессоре исключительно на его физических ядрах без использования технологии Hyperthreading. При превышении количества vCPU над количеством физических ядер процессора, ВМ продолжит исполняться в пределах этого физического процессора, но уже с использование Hyperthreading. Если количество vCPU превысило количество ядер процессора с учетом Hyperthreading, то начнут использоваться ядра соседних NUMA нод (других физических процессоров), что приведет к потере производительности (если указать неверное количество виртуальных сокетов). В случае, когда физический процессор сильно нагружен, и свободных физических ядер не осталось, то в любом случае будет использоваться технология Hyperthreading (если иное не указано в конфигурации виртуальной машины). Если посмотреть на цифры, то в среднем ВМ теряет порядка 30-40% производительности, если она работает на чистом Hyperthreading по сравнению с чистыми физическими ядрами. Но сам физический процессор имеет общую производительность примерно на 30% больше с технологией Hyperthreading, чем без нее (используя только физические ядра). Данный показатель очень зависит от типа нагрузки и оптимизации приложений ВМ к многопоточной работе.
Если у ВМ более одного виртуального сокета, то vSphere будет оптимизировать работу такой ВМ, размещая исполняемые ядра и оперативную память на разных физических процессорах сервера.
По понятным причинам, ситуация с нагрузкой физического сервера постоянно меняется. Зачастую, возникает неравномерность нагрузки на физических процессорах сервера. vSphere следит за этим. Шедулер анализирует положение дел, вычисляет накладные расходы на перемещение ВМ или её части на другую NUMA ноду (перемещение памяти, ядер). Сравнивает эти расходы с потенциальной выгодой от перемещения и принимает решение — оставлять все как есть или же перемещать. Иными словами, при любой ситуации vSphere старается оптимизировать работу виртуальных машин. Наша задача состоит в том, чтобы упростить vSphere эту задачу и не ставить её в безвыходное положение.
О каких потерях может идти речь при неправильной конфигурации машин с NUMA нодами? Руководствуясь собственным опытом, могу сказать, что потери могут доходить до 30% общей производительности физического сервера. Много это или мало – решать вам.
Теперь, когда мы немного разобрались с NUMA и Hyperthreading, мне хотелось бы чуть подробнее рассказать о работе шедулера с ядрами виртуальных машин, vCPU.
Я не буду вдаваться в совсем уж глубины, это мало кому интересно, но постараюсь рассказать про принципы и методику работы данного механизма. Итак, основной механизм гипервизора работает следующим образом. В оперативной памяти постоянно работает процесс, обслуживающий работу виртуальных машин. Этот процесс можно представить как конвейер состояния READY и хранилище состояния WAIT. Опустим другие, менее значимые состояния виртуальных машин, они сейчас не принципиальны.
Для легкости восприятия, предлагаю воспринимать все vCPU виртуальных машин как цепочку. Каждое звено цепи – это ядро vCPU (world, в терминах vSphere). Таких world у машины столько, сколько у нее vCPU. Есть еще 2 невидимых, служебных world, сопутствующих каждой виртуальной машине. Один отвечает за обслуживание машины в целом, второй за её ввод-вывод. Реальное потребление вычислительной мощности этими служебными мирами совершенно незначительное, а потребление ими оперативной памяти можно оценить по показателю overhead у каждой виртуальной машины. Стоит отметить, что при создании ВМ размером в весь физический хост, с равным количеством виртуальных и физических ядер, могут возникнуть некоторые потери производительности. Этого момента я коснусь чуть ниже.
Конвейер READY, это «труба», в которую по очереди сброшены все такие цепочки. Таймслот – это время, в течение которого виртуальные машины исполняются физическим процессором (исполняются их vCPU). На это время виртуальная машина практически без потерь, аналогично физическому серверу, использует физические процессоры аппаратного сервера (pCPU). Максимальная величина таймслота искусственно ограничена величиной порядка 1 миллисекунды. После окончания таймслота, vCPU ВМ принудительно помещаются шедулером в очередь конвейера READY. Шедулер имеет возможность менять очередность виртуальных машин в конвейере READY, приоритет каждой машины вычисляется исходя из её текущей фактической нагрузки, её прав на ресурсы (Shares), как давно машина была на физическом процессоре и еще нескольких менее значимых параметров. Логично предположить, что если ВМ на хосте одна, то она всегда будет проходить конвейер очереди READY без задержек т.к. у нее нет конкурентов на ресурсы со стороны других ВМ.
Каким образом шедулер располагает миры виртуальных машин на физических ядрах? Представим себе таблицу, которая имеет по ширине столько столбцов, сколько ядер у нашего физического сервера (с учетом Hyperthreading). По высоте каждая строка будет соответствовать очередному такту процессора(ов) сервера. Давайте представим себе 2-процессорный сервер, по 6 физических ядер на процессор, + Hyperthreading. Всего получим 24 ядра на сервер. Предположим, что у сервера высокая нагрузка, и vSphere вынуждена использовать Hyperthreading, так будет проще считать. Допустим, у нас есть несколько виртуальных машин:
• 4 штуки по 1 ядру
• 4 штуки по 2 ядра
• 2 штуки по 8 ядер
• 1 штука по 16 ядер
Итак, наступает первый таймслот, шедулер выбирает претендентов. Пусть первой будет машина на 16 ядер. Первые 16 физических ядер (pCPU) заняты, осталось 8. Туда поместились, допустим, 4 машины по 2 ядра (причем машина на 16 ядер должна иметь 2 виртуальных сокета, чтобы корректно работать с NUMA). Всё, таймслот заполнен полностью, это идеальный вариант. Мы не теряем производительность, pCPU не простаивают. Остальные виртуальные машины в это время не работают и находятся в очереди ожидания READY. Предположим, что «счастливые» виртуальные машины получили одинаковый по величине таймслот (хотя в реальности у всех ВМ таймслот разный и зависит от множества факторов). Итак, наступает второй таймслот, и шедулеру надо его заполнить.
Остались не обслуженными машины:
• 4 штуки по 1 ядру
• 2 штуки по 8 ядер
Начинаем заполнять, 2 машины по 8 ядер, 4 машины по 1, осталось 4 свободных pCPU, можно положить туда две 2-ядерных машины, которые уже отработали в первом таймслоте. Больше мы туда уместить ничего не можем, не помещается. Таймслот опять заполнен полностью и мы не теряем мощность.
Аналогичным образом шедулер будет и далее наполнять таймслоты мирами виртуальных машин, стараясь сделать это максимально эффективно, чтобы уменьшить «дыры» в заполнении и повысить КПД виртуальной среды.
Ниже представлен негативный вариант расположения виртуальных машин на хосте. Одна большая машина размером в хост, и одна малая, с 1 vCPU. При равных правах на ресурсы и равных потребностях к производительности эти машины получат одинаковое количество таймслотов, то есть поделят между собой процессорное время. Т.к. обе машины не смогут работать одновременно (не умещаются в один таймслот), то работать они будут по очереди, причем малая машина будет работать в пустом таймслоте, где кроме нее больше никого не будет (таймслот израсходуется практически впустую). Большая машина при всем желании не сможет получить процессорное время, даже если оно этой машине необходимо. Например, при частоте центрального процессора 3 ГГц, обе эти машины смогут максимум получить по 1.5 ГГц.
Виртуализация позволяет создать на хосте несколько виртуальных машин, и может сложиться ситуация, когда суммарное количество vCPU всех машин будет больше количества pCPU физического хоста. Это вполне нормальное явление, но нужно четко осознавать, что одновременно все vCPU не смогут получить 100% от своей завяленной мощности. Иными словами, если у вас на одном хосте виртуализации находятся несколько нагруженных машин и их общее количество vCPU больше чем pCPU хоста, то с высокой долей вероятности эти машины будут мешать друг другу, что снизит их суммарную производительность.
Сейчас хотелось бы вернуться к созданию виртуальной машины величиной в весь хост. Хорошо, пусть такая ВМ заняла собой целиком первый таймслот и отработала его. Теперь вспоминаем про системные миры, сопутствующие этой машине. Их тоже надо исполнять, как надо исполнять сам гипервизор и его собственные системные процессы. То есть надо и им выдавать таймслоты и занимать в них некоторое количество pCPU. А что в это время делать нашей большой ВМ? Правильно, ожидать освобождения ВСЕХ pCPU, чтобы иметь возможность там уместиться. То есть мы гарантированно теряем производительность на служебных задачах гипервизора (таймслотах), а это плохо (вспоминаем пример выше с большой и малой машинами). Для примера, программный iSCSI инициатор под высокой нагрузкой потребляет до 6 ГГц процессорной мощности. Это было бы не так заметно в случае с малыми ВМ т.к. они работали бы параллельно служебным процессам (в этих же таймслотах). А для большой ВМ так не получится т.к. она занимает весь таймслот целиком, все его pCPU, и не может уместиться в таймслот, если хоть один его pCPU уже кем-то занят, пусть и системным процессом.
О каких потерях может идти речь при неправильном конфигурировании виртуальной инфраструктуры и размещении машин по нодам? От нуля до бесконечности (в теории). Все зависит от конкретной ситуации.
Отдельно хотелось бы озвучить главное правило при сайзинге виртуальных машин: давайте виртуальной машине МИНИМАЛЬНО возможные ресурсы, при которых она сможет выполнять свои задачи. Не нужно давать ВМ 2 ядра, если хватает одного. Не нужно давать 4, если хватает 2-х (лишние ядра занимают место в таймслоте). Аналогично с памятью, не стоит выдавать машине лишнего. Возможно, другой машине может не хватить, не говоря уже о возникающих проблемах с живой миграцией (по сути копированием объема памяти ВМ) и NUMA.
Теперь, разобравшись с механизмом размещения vCPU виртуальных машин на pCPU таймслота, давайте вспомним про NUMA и его правила размещения. Для шедулера гипервизора все эти правила имеют значение при заполнении таймслота т.к. pCPU таймслота могут относиться к разным NUMA нодам. Теперь, помимо сложностей учета NUMA при конфигурировании виртуальных машин на хосте, мы получили и ограничения, накладываемые методикой работы шедулера гипервизора с таймслотами. Если мы хотим получить хорошую производительность ВМ, нужно обращать внимание на все подводные камни и руководствоваться следующими правилами:
• Стараться не создавать машины-гиганты (по сравнению с размером хоста)
• Для больших машин надо учитывать ограничения, накладываемые технологией NUMA
• Не стоит злоупотреблять с количеством vCPU по отношению к pCPU хоста
• Несколько мелких или средних машин всегда будут иметь преимущество в гибкости и общей производительности перед огромными машинами
Напоследок хотелось бы сказать о работе шедулера гипервизора с вводом-выводом. При обращении виртуальной машины к своему виртуальному аппаратному обеспечению, гипервизор приостанавливает работу ВМ, снимает её с pCPU и ставит в хранилище WAIT. В таком состоянии машина не работает, она просто ждет. В это время гипервизор трансформирует («подделывает») команды виртуального устройства гостевой машины в реальные команды, соответствующие командам гипервизора, после чего гипервизор возвращает виртуальную машину в конвейер READY. Аналогичная «заморозка» виртуальной машины происходит и при ответе виртуального устройства машине (гипервизору необходимо снова трансформировать ответ, но уже в обратную сторону ). Чем больше команд ввода-вывода производит виртуальная машина, тем чаще она находится в «заморозке» WAIT, и тем меньше её производительность. Чем более «старые» виртуальные устройства ввода-вывода использует виртуальная машина, тем сложнее гипервизору трансформировать команды, и тем дольше ВМ находится в состоянии WAIT.
VMWare прямо и официально не рекомендует виртуализовывать приложения с гиперактивным вводом-выводом. Уменьшить негативное влияние от состояния WAIT можно с помощью использования паравиртуальных устройств для виртуальной машины. Это 10-гигабитная сетевая карта VMXNET3 и паравиртуальный SCSI контроллер жесткого диска PVSCSI. Так же уменьшению влияния WAIT и общему повышению производительности способствует применение в физических серверах аппаратных устройств, предназначенных для ускорения работы виртуальных машин. Это различные сетевые и HBA адаптеры с поддержкой аппаратного iSCSI offload, прямого доступа к памяти, сетевые карты с поддержкой виртуализации и т.д.
На этом я хотел бы остановиться. Надеюсь, информация в данной статье была вам интересна, и вы сможете более эффективно подойти к построению или эксплуатации своей виртуальной инфраструктуры.
Больше оперативной памяти
Виртуальные машины требовательны к объёму доступной оперативной памяти. Каждая виртуальная машина включает полноценную операционную систему. Поэтому необходимо разделить операционную систему вашего ПК на две отдельные системы.
Microsoft рекомендует минимум 2 ГБ оперативной памяти для своих операционных систем. Соответственно, такие требования актуальны и для гостевой операционной системы виртуальной машины с Windows. А если планируется использование на виртуальной машине стороннего требовательного программного обеспечения, то для её нормальной работы оперативной памяти потребуется ещё больше.
В случае, если уже после создания виртуальной машины оказалось, что оперативной памяти для её нормальной работы недостаточно, то её можно добавить в настройках виртуальной машины.
Прежде чем делать это, убедитесь, что виртуальная машина отключена. Также, не рекомендуется предоставлять виртуальной машине более чем 50% физически присутствующей на компьютере виртуальной памяти.
Если, выделив для виртуальной машины 50% памяти вашего компьютера выяснилось, что она не стала работать достаточно комфортно, то возможно для нормальной работы с виртуальными машинами вашему компьютеру недостаточно оперативной памяти. Для нормальной работы любой виртуальной машины будет достаточно 8 ГБ оперативной памяти, установленной на основном ПК.
Ограничения в работе CPU
Чтобы определить являются ли ограничения в работе CPU причиной низкой производительности:
- Введите команду esxtop, чтобы проверить перегружен ли ESXi/ESX server. Изучите load average в первой строке вывода команд. Средняя загрузка на уровне 1.00 означает, что физические процессоры (CPUs) машины с ESXi/ESX Server используются полностью, средняя загрузка 0.5 означает использование лишь половины ресурсов. Средняя загрузка на уровне 2.00 означает, что система перегружена.
- Изучите поле %READY, чтобы узнать долю времени, в течении которого виртуальная машина была готова, но не могла быть запланирована для запуска на физическом процессоре. При нормальных условиях эксплуатации это значение должно оставаться в пределах 5%. Если время готовности на виртуальных машинах с низкой производительностью слишком высокое, то необходимо проверить ограничения в работе процессора - убедитесь, что виртуальная машина не ограничена установленным лимитом процессора;
Проверьте не ограничена ли виртуальная машина доступным объёмом ресурсов.
Если средняя загрузка слишком высока и время, в течении которого машина готова к работе, не зависит от ограничений в работе процессора, то следует отрегулировать загрузку CPU хостa. Чтобы отрегулировать загрузку CPU хоста нужно:
- Увеличить количество физических CPU хоста
- Или уменьшить количество выделенных хосту виртуальных CPU. Чтобы уменьшить количество выделенных хосту виртуальных CPU нужно уменьшить общее количество CPU, выделенных всем запущенным виртуальным машинам на ESX хосте.
- Или уменьшить количество запущенных виртуальных машин
Если Вы используете ESX 3.5, проверьте является ли проблемой совместное использование IRQ.
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»:
Читайте также: