Vmware лагает виртуальная машина
Обновлено: 04.07.2024
Скорее всего, вы выбрали VMware vSphere в качестве решения для виртуализации из-за его репутации надежного и производительного продукта; однако без должного внимания и оптимизации вы не сможете полностью использовать возможности платформы. Существует множество оптимизаций, которые можно сделать, чтобы ваша установка vSphere работала на оптимальном уровне. В этой статье рассматриваются 30 советов и рекомендаций, которые обеспечат наилучшую производительность VMware vSphere, а некоторые даже применимы к другим продуктам виртуализации.
30 полезных лайфхаков в VMware для админа
Используйте только совместимое с VMware оборудование
У VMware существует список совместимого оборудования для каждой версии платформы vSphere. Перед покупкой или эксплуатацией оборудования необходимо удостовериться, что все компоненты совместимы и поддерживаются. Также нужно проверить соответствие оборудования минимальным требованиям для правильной установки и эксплуатации.
Старайтесь использовать новейшее оборудование с аппаратной виртуализацией
Последние процессоры AMD и Intel поддерживают функции оборудования по содействию виртуализации VMware. Эти функции бывают двух видов: процессорная виртуализация и виртуализация управления памятью.
Проведите стресс-тест или проверку оборудования перед вводом в эксплуатацию
Собирая или покупая новую систему полезно провести глубокий стресс-тест или проверку системы. Существует множество программ для этого и многие из них доступны для загрузки с CD-диска для запуска системы в любом состоянии. Это поможет найти неисправные компоненты и обеспечит надёжность платформы во время работы.
Выберите подходящее приложению внутреннее хранилище
Существует множество различных систем внутренних хранилищ и выбор может обеспечить огромное влияние на производительность вашей системы. Дисковый ввод/вывод является одним из главных препятствий в сфере компьютерного оборудования и имеет один из самых низких показателей роста. Выбор устройства внутреннего хранилища и его конфигурация зависит от типа используемого приложения. Например, продукты SATA сами по себе не могут обеспечить высокую скорость записи на диск больших объёмов данных в научном оборудовании. При необходимости высокой скорости или большого объёма хранилища стоит посмотреть на более надёжные и эффективные носители информации, такие как iSCSI или NFS . Для корректной работы ваше хранилище должно поддерживать требуемый объём данных или скорость чтения/записи для ваших приложений, в том числе требования для работы операционной системы хоста и самой платформы vSphere.
Используйте сетевые карты серверного сегмента
Не все сетевые карты одинаковы; встроенные адаптеры больше подходят для нужд рядовых пользователей. Для корпоративных серверов стоит использовать серверные NIC (сетевые карты), поддерживающие контрольные суммы разгрузки, сегментной разгрузки TCP, обработку 64-битных DMA адресов, способность рассеивать и собирать элементы, встречающиеся множество раз в одном кадре и Jumbo-кадре. Эти функции позволяют vSphere использовать встроенную продвинутую поддержку сети.
Оптимизируйте настройки BIOS серверов
Производители материнских плат поставляют свои продукты с BIOS для работы с различными конфигурациями, поэтому они не способны оптимизировать материнскую плату для работы с конкретно вашей конфигурацией. Следует постоянно обновлять BIOS до последней версии и включать используемую vSphere аппаратную поддержку, например, Hyperthreading, “Turbo Mode”, VT-x, AMD-V, EPT, RVI и другие. Также следует отключить энергосбережение, чтобы исключить негативное влияние на производительность сервера.
Обеспечить виртуальные среды только требуемыми ресурсами
Это может показаться нелогичным, но наличие лишних ресурсов для виртуальных машин в системах виртуализации накладывает ограничения на их производительность. Так, VMware хорошо справляется с системами, перегруженными количеством виртуальных машин, и хуже с машинами с избыточным количеством ресурсов. При запуске системы используйте рекомендуемые настройки или настройки по умолчанию для памяти, хранилищ и остального, далее изменяйте их лишь при необходимости. Консоль управления сообщит о проблемах с ресурсами, и вы сможете реагировать на предупреждения при необходимости.
Отключайте неиспользуемое и ненужное виртуальное или физическое оборудование от VM
Отключая устройства, вы освобождаете ресурсы прерывания. Также повышается производительность после отключения устройств, потребляющих дополнительные ресурсы из-за запросов, такие как USB адаптеры и PCI устройства, которые резервируют блоки памяти под свои операции. Используя гостевой режим Windows, убедитесь, что оптические приводы отключены, потому что Windows постоянно запрашивает их, что может вызвать проблемы, особенно при множестве гостей (гостевых ОС), работающих одновременно.
Следите за потреблением CPU в среде хоста
Постоянно следите с помощью консоли за потреблением CPU всей системой виртуализации, это позволит заметить перегрузку системы. В этом случае вы можете переместить VM другому хосту в вашей системе, перенести ресурсы на менее загруженный хост или выключить неиспользуемую или ненужную VM. Основное правило использования VMware гласит: если средняя загрузка системы равна количеству физических процессоров в системе, то вы выделяете лишние ресурсы, а на вашем сервере находится слишком много гостей.
Ограничьте использование виртуальных процессоров (CPU) приложениями
Если вы используете однопоточные или приложения плохо спроектированные для многопоточной работы и параллелизма, то использование виртуальных процессоров (CPU) бесполезно. Неиспользуемые виртуальные процессоры (CPU) продолжают использовать ресурсы даже когда не используются системой.
Включите Hyper-Threading, если он поддерживается оборудованием
Hyper-Threading это технология, разработанная для обеспечения непрерывного потока инструкций, подаваемых на процессор. Множество процессоров позволяет множеству инструкций быть обработанным одновременно, а HT уменьшает время простоя процессора и предоставляет больший объём работы на каждый такт. Не существует определённого быстрого правила для повышения производительности, используя HT, но это может увеличивать производительность некоторых приложений более чем в два раза.
Обеспечьте хосту объём памяти, необходимый для работы с гостями и консолью
Чтобы выбрать количество физической памяти для хоста системы и количества гостей, необходимо посчитать общее количество памяти, необходимой каждой VM. Также нужно добавить память в буффер для расхода самой VM и потребления vSphere. Чтобы исключить ошибку с нехваткой памяти, следует добавить чуть больше физической памяти, чем этого требуется.
Выбирайте подходящие приложениям файловые системы и типы виртуальных дисков
Типы виртуальных дисков и файловых систем предлагают различные профили производительности, поэтому стоит выбирать на основе потребностей ввода/вывода отдельных ваших приложений. Для приложения, которое постоянно записывает данные на диск, лучшим выбором будет оптимизированная под запись файловая система и соответствующий виртуальный диск.
Минимизируйте потребление приложениями, постоянно открывающими и закрывающими файлы, или создайте расписание для снижения нагрузки от ввода/вывода на диск
Чтение и запись являются наиболее дорогими операциями в вычислениях. Для наиболее эффективного использования ресурсов следует распределить отложенные задачи и сложные операции ввода/вывода на периоды низкой загруженности системы и сети. Осуществление программного ввода/вывода во время пиковых нагрузок влечёт за собой многочисленные и серьёзные падения производительности.
Распределите операции ввода/вывода между адаптерами и путями хранилищ
При наличии множества адаптеров хранилищ или путей хранилищ (в одной сети) следует распределять нагрузку между ними во избежание перегрузки слоя ввода/вывода. Ввод/вывод является одной из наиболее важных частей системы и влияет на производительность. Поскольку устройства и контроллеры хранилищ неидеальны и последними пользуются достижениями технологий, то следует использовать все возможные пути для повышения производительности.
Объединения сетевых интерфейсных карт повышают отказоустойчивость
Объединённые сетевые интерфейсные карты позволяют сетевым адаптерам работать сообща, что обеспечивает более стабильное соединение и лучшую отказоустойчивость. При отказе сетевого интерфейса или возникновении проблемы другие соединённые сетевые интерфейсы автоматически устранят дыру в системе и обеспечат плавное возвращение к нормальной работе.
Группируйте системы, взаимодействующие друг с другом на одном свитче
Размещая системы, взаимодействующие друг с другом на постоянной основе, вы избежите возникновение перегрузок в системе. Если же системы находятся на разных виртуальных свитчах, то для взаимодействия друг с другом трафик должен выйти из системы, покинуть текущий свитч и потом пройти по сети, чтобы достигнуть другой системы.
Используйте только те гостевые операционные системы, которые поддерживаются vSphere
VMware оптимизирует свои хост платформы для работы с определёнными операционными системами и использование несертифицированных операционных систем может повлечь проблемы с поддержкой и производительностью в рабочей среде.
Установите и используйте новейшие версии VMware Tools на каждой гостевой операционной системе
VMware Tools обновляет драйвера и добавляет улучшения, отсутствующие на стоковых драйверах гостевых операционных систем. Важно обновлять программное обеспечение хоста при каждом обновлении VMware Tools.
Дополнительные компоненты, особенно графические, лишь пожирают ресурсы и зачастую не приносят пользы в серверной среде, а иногда создают уязвимости в защите системы. При отсутствии необходимости использования на сервере графических приложений рекомендуется отключать заставки, оконные системы, оконные анимации и прочее.
Используйте NTP для учёта гостевого времени
Это не самый важный совет по производительности, но использование временного сетевого протокола ( NTP ) обеспечивает надёжное ведение системных журналов и поможет при возникновении проблем с безопасностью и производительностью.
Убедитесь, что гостевые разделы выравнены
Большинство дисковых файловых систем теряют производительность, если дисковые разделы не выравнены. Процедура выравнивания различается от производителя к производителю.
Используйте VMXNET3 в виртуальных сетевых адаптерах на гостях, которые это поддерживают
VMXNET3 снижает затраты на передачу траффика между виртуальной машиной и физической сетью. Они известны как паравиртуализированные сетевые адаптеры и могут обеспечить значительное повышение производительности для большей части рабочих нагрузок.
Группируйте виртуальные машины в пул ресурсов тогда, когда это применимо
Группируя виртуальные машины в один логический набор, вы можете повысить приоритет на выделение ресурсов группам, а не отдельным машинам. Это также позволит гостям в группе совместно использовать ресурсы и поможет сбалансировать нагрузку.
Отключайте пользователей vSphere от vCenter, если они больше не нужны
Множество подключённых к VMware vCenter пользователей понижает производительность, что можно увидеть на консоли. В любом случае, vSphere продолжит работу даже при превышении количества рекомендованных/поддерживаемых пользователей, но со значительным падением производительности.
Группируйте схожие виртуальные машины при использовании VMware Distributed Resource Scheduler (для распределения ресурсов CPU и памяти)
Группировка машин со схожими конфигурациями процессоров (CPU) и памяти позволит определять машины как одно целое и это облегчит работу vSphere по поддержанию стабильной работы.
Отключайте неиспользуемые виртуальные машины
Даже неиспользуемые виртуальные машины потребляют ресурсы. Это не обеспечит огромный прирост производительности, но окажет своё влияние. Вы всегда можете перезапустить гостя, когда появится необходимость в системе.
Используйте поддерживающие wake-on-LAN хосты для облегчения контроля питанием
Если ваши сетевые адаптеры поддерживают wake-on-LAN, то рассмотрите возможность использования этой функции, она позволит vSphere помогать в управлении питанием.
Включайте Fault Tolerance, только если вы собираетесь использовать эту функцию
Выключите Fault Tolerance , функцию vSphere направленную на работу с гостями, если не будете использовать её, так как для работы она требует значительное количество памяти, потребление процессора (CPU) и операций ввода/вывода на диске.
Используйте хотя бы гигабитную сетевую инфраструктуру
Сейчас сетевое оборудование и кабели к нему стоят дёшево, поэтому нет смысла в использовании сетевых инфраструктур с пропускной способностью ниже гигабита. Если вы можете позволить это или испытываете особую потребность в этом, то вы можете предпочесть более высокоскоростные волоконно-оптические технологии передачи и носителей данных, чтобы обеспечить быструю и надёжную работу с возможностью для роста и потенциала.
Заключение
Все эти советы являются лишь верхушкой айсберга. Я настоятельно рекомендую изучить советы по вашим потребностям, прочитав официальную документацию VMware. Также заглядывайте в наш раздел по виртуализации , там много полезных материалов.
Проблемы с производительностью виртуальной машины на ESX/ESXi могут быть вызваны по различным причинам, например, ограничения в работе CPU, излишний объём памяти, задержкой в работе хранилищ или сети. Если одна или более из ваших виртуальных машин показывает высокое время ответа, то проверьте каждую из возможных причин, чтобы выявить слабое место системы.
- Сервисы на гостевых виртуальных машинах работают медленно
- Приложения на гостевых виртуальных машинах отвечают с задержкой
- Гостевая виртуальная машина работает медленно или не отвечает
Решение
Каждый нижестоящий шаг содержит инструкции и ссылки на соответствующие документы. Шаги выстроены в наиболее удобном порядке для выявления и решения проблемы. Такая последовательность также обеспечивает наименьшую потерю данных.
Замечание: после завершения каждого шага отмечайте сохраниться ли проблема с производительностью. Не пропускайте шаги и выполняйте их в указанном порядке.
Статья включает в себя 4 основных части:
- Ограничения в работе CPU
- Излишний объём памяти
- Задержка в работе хранилища
- Сетевые задержки
Ограничения в работе 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.
Перегрузка памяти
Чтобы определить является ли причиной низкой производительности перегрузка памяти необходимо:
- Ввести команду 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 не вызваны неправильно заданным объёмом памяти. Если объём памяти задан неверно, то его следует переназначить
Задержки в работе хранилища
Чтобы определить являются ли задержки в работе хранилища причиной низкой производительности: Проверьте связаны ли проблемы с локальным хранилищем. Перенесите виртуальные машины в другое хранилище.
- Уменьшите количество виртуальных машин на 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.
Сетвые задержки
Производительность сети тесно связана с производительностью CPU. Поэтому сначала необходимо проверить работу CPU и после этого переходить к поиску проблем в сети. Для определения проблем с производительностью сети:
Проверьте максимальную пропускную способность от виртуальной машины с помощью Iperf .
Замечание: VMware не поддерживает и не рекомендует какую-либо конкретную стороннюю программу.
Во время использования Iperf измените размер окна TCP до 64 K. Это также влияет на производительность. Для изменения размера окна TCP:
В данной статье мы рассмотрим несколько способов повышения производительности виртуальной машины VMware Workstation, Oracle VirtualBox, Microsoft Hyper-V или любой другой. Виртуальные машины довольно требовательны к характеристикам компьютера, ведь во время их работы на ПК одновременно запущено несколько операционных систем. Как результат, виртуальная машина может быть значительно медленнее основной операционной системы или вообще работать с притормаживанием.
В данной статье мы рассмотрим несколько способов повышения производительности виртуальной машины VMware Workstation , Oracle VirtualBox, Microsoft Hyper-V или любой другой.
Динамический или фиксированный виртуальный жесткий диск?
Создавая виртуальную машину, можно создать два разных типа виртуальных жестких дисков. По умолчанию виртуальная машина использует динамический диск, который занимает необходимое место на физическом носителе информации и увеличивается лишь по мере заполнения.
Например, создавая виртуальную машину с динамическим диском в 30 ГБ, он не займёт сразу же 30 ГБ жесткого диска компьютера. После установки операционной системы и необходимых программ его размер будет порядка 10-15 ГБ. Лишь по мере добавления данных, он может увеличиться до 30 ГБ.
Это удобно с той точки зрения, что виртуальная машина будет занимать на жестком диске место, которое пропорционально объёму хранимых на ней данных. Но, работа динамического жесткого диска медленнее фиксированного (иногда также называют распределённым).
Создавая фиксированный диск, все 30 ГБ на жестком диске компьютера будут выделены под диск виртуальной машины сразу же, независимо от объёма хранимых на нём данных. То есть, фиксированный жесткий диск виртуальной машины занимает больше места жесткого диска компьютера, но сохранение или копирование файлов и данных на нём происходит быстрее. Он не так сильно подвержен фрагментации, так как пространство под него выделяется максимально большим блоком, вместо того, чтобы добавляться маленькими частями.
Установка пакета инструментов виртуальной машины
После установки на виртуальную машину гостевой операционной системы, первое, что необходимо сделать – это установить пакет инструментов или драйверов вашей виртуальной машины, например: VirtualBox Guest Additions или VMware Tools. Такие пакеты содержат драйвера, которые помогут гостевой операционной системе работать быстрее.
Установить их просто. В VirtualBox, загрузите гостевую операционную систему и выберите Устройства / Подключить образ диска Дополнительной гостевой ОС… После чего запустите установщик, который появится как отдельный диск в папке «Этот компьютер» гостевой операционной системы.
В VMware Workstation, выберите меню Виртуальная машина / Установить паке VMware Tools… После чего запустите установщик, который появится как отдельный диск в папке «Этот компьютер» гостевой операционной системы.
Добавьте папку с виртуальной машиной в исключения вашей антивирусной программы
Антивирусная программа кроме прочих, также сканирует файлы виртуальной машины, что снижает её производительность. Но дело в том, что антивирусная программа не имеет доступа к файлам внутри гостевой операционной системы виртуальной машины. Поэтому такое сканирование бессмысленно.
Чтобы избавится от снижения производительности виртуальной машины, можно добавить папку с ней в исключения антивирусной программы. Антивирус будет игнорировать все файлы такой папки.
Активация Intel VT-x или AMD-V
Intel VT-x и AMD-V – это специальные технологии виртуализации, которые предназначены для обеспечения большей производительности виртуальных машин. Современные процессоры Intel и AMD, как правило обладают такой функцией. Но на некоторых компьютерах она автоматически не активирована. Чтобы её включить, необходимо перейти в BIOS компьютера и активировать её вручную.
AMD-V часто уже активирована на ПК, если поддерживается. А Intel VT-x чаще всего отключена. Поэтому, убедитесь в том, что указанные функции виртуализации уже активированы в BIOS, после чего включите их в виртуальной машине.
Больше оперативной памяти
Виртуальные машины требовательны к объёму доступной оперативной памяти. Каждая виртуальная машина включает полноценную операционную систему. Поэтому необходимо разделить операционную систему вашего ПК на две отдельные системы.
Microsoft рекомендует минимум 2 ГБ оперативной памяти для своих операционных систем. Соответственно, такие требования актуальны и для гостевой операционной системы виртуальной машины с Windows. А если планируется использование на виртуальной машине стороннего требовательного программного обеспечения, то для её нормальной работы оперативной памяти потребуется ещё больше.
В случае, если уже после создания виртуальной машины оказалось, что оперативной памяти для её нормальной работы недостаточно, то её можно добавить в настройках виртуальной машины.
Прежде чем делать это, убедитесь, что виртуальная машина отключена. Также, не рекомендуется предоставлять виртуальной машине более чем 50% физически присутствующей на компьютере виртуальной памяти.
Если, выделив для виртуальной машины 50% памяти вашего компьютера выяснилось, что она не стала работать достаточно комфортно, то возможно для нормальной работы с виртуальными машинами вашему компьютеру недостаточно оперативной памяти. Для нормальной работы любой виртуальной машины будет достаточно 8 ГБ оперативной памяти, установленной на основном ПК.
Выделить больше CPU
Основная нагрузка при работе виртуальной машины, приходится на центральный процессор. Таким образом, чем больше мощности центрального процессора виртуальная машина может занять, тем лучше (быстрее) она будет работать.
Если виртуальная машина установлена на компьютере с мульти-ядерным процессором, то в настройках виртуальной машины для неё можно выделить несколько ядер для её работы. Виртуальная машина на двух и более ядрах центрального процессора будет работать ощутимо быстрее чем на одном.
Установка виртуальной машины на компьютере с одноядерным процессором нежелательна. Работать такая виртуальная машина будет медленно и выполнение ею каких-либо задач будет не эффективным.
Правильные настройки видео
На скорость работы виртуальной машины могут также влиять настройки видео. Например, включение 2D или 3D-ускорения видео в VirtualBox, позволяет работать некоторым приложениям значительно быстрее. То же касается и возможности увеличения видеопамяти.
Но, как и в случае с оперативной памятью, многое зависит от видеоадаптера, который установлен на основном компьютере.
Виртуальная машина и SSD диск
Первым и лучшим усовершенствованием компьютера на сегодняшний день является установка на него SSD диска. Это ощутимо ускорит работу компьютера, а соответственно и установленной на нём виртуальной машины.
Некоторые пользователи устанавливают виртуальные машины на другой (HDD) диск своего компьютера, оставляя на SSD диске лишь основную операционную систему. Это делает работу виртуальной машины медленнее. Освободите место на SSD диске и перенесите виртуальную машину на него. Разница в скорости работы почувствуется с первых минут.
По возможности, не размещайте диски виртуальных машин на внешних носителях информации. Они работают ещё медленнее чем встроенный HDD диск. Возможны варианты с подключением виртуальной машины через USB 3.0, но о USB 2.0 и речи быть не может – виртуальная машина будет работать очень медленно.
Приостановка вместо закрытия
Когда вы закончили работать с виртуальной машиной, её можно приостановить вместо полного выключения.
Запуская приложение для работы с виртуальными машинами следующий раз, вы можете включить виртуальную машину таким же способом как обычно. Но она загрузится значительно быстрее и именно в том состоянии и с того места, на котором вы закончили работать прошлый раз.
Приостановка гостевой операционной системы очень похожа на использование гибернации вместо выключения ПК.
Улучшение производительности внутри виртуальной машины
Всегда необходимо помнить, что установленная на виртуальную машину операционная система мало чем отличается от той, которая работает на основном компьютере. Её работу можно ускорить, следуя тем же принципам и используя те же методы, которые актуальны для любой другой операционной системы.
Например, производительность системы увеличится если закрыть фоновые программы или те, которые автоматически запускаются при старте системы. На производительность системы влияет необходимость осуществления дефрагментации диска (если виртуальная машина расположена на HDD диске), и так далее.
Программы для работы с виртуальными машинами
Одни пользователи уверяют, что Oracle VirtualBox самый быстрый инструмент для работы с виртуальной машиной, для других – VMware Workstation или Microsoft Hyper-V . Но то, как быстро будет работать виртуальная машина на конкретном компьютере зависит от множества факторов: это и версия гостевой операционной системы, её тип, настройки системы и виртуальной машины, производительность самого компьютера, и пр. В любом случае, всегда можно испробовать другую программу.
- VMware Technology Network
- :
- Global
- :
- Russian
- :
- Russian Discussions
- :
- ESXi - CPU usage низкая, виртуальные машины сильно.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Email to a Friend
Есть ESXi 6.0 на несерверном железе - i5, 8gb, SATA. Проблема в том, что, видимо для экономии электричества, хост сильно снижает производительность, гостевые ОС чудовищно виснут. У хоста Summary - Resources - CPU usage показывает 200 мегагерц при Capacity 3092 GHz.
IT_pilot- Mark as New
- Bookmark
- Subscribe
- Mute
- Email to a Friend
Если бы ВМ не хватало процессора, то хост разогнался бы до номинальной мощности.
Вы ничего не пишите про память. Но,скорее всего, дело в " SATA".
Какие у вас задержки на диск (read/write latenc) в целом по хосту и в разрезе ВМ?
Finikiez- Mark as New
- Bookmark
- Subscribe
- Mute
- Email to a Friend
Опишите полную картину, сколько у вас запущено виртуальных машин и какая у них конфгурация по CPU, RAM и какие там операционные системы запущены
С учетом того, что у вас всего 8 Гб оперативной памяти и SATA диск, то рассчитывать вам на многое не получится
Seshil- Mark as New
- Bookmark
- Subscribe
- Mute
- Email to a Friend
Спасибо за отзывы. Сегодня на вопросы по конкретному серверу ответить не смогу, т.к. он используется сейчас не как esxi.
Но и вопросы не совсем в тему. Описанная мною ситуация типичная, много лет ее наблюдаю. Просто увидел место, где можно вопрос задать, решил воспользоваться.
Итак, есть хороший ПК - i5, 8Gb DDR3, диски SATA без RAID. Важно для понимания - если на этом ПК в хостовой винде запустить три виртуальных винды или линуксов на VMWARE Workstation или VirtualBox, то производительность просядет, будет притормаживать. Но просто притормаживать, а не вставать колом. Процессор будет молотить на полную мощность, оператива будет хорошо занята, как раз по объему выделенной оперативы на виртуальных ОС.
В ситуации с ESXi ситуация совсем другая. Если одновременно устанавливать три гостевых ОС с такими же объемами выделенной для них оперативы (остальные настройки по дефолту), то ВО ВРЕМЯ УСТАНОВКИ и память, и процессор хоста будут заняты по полной. CPU usage хоста будет на всю доступную частоту ЦП. (Кстати мысль появилась - во время установки еще не установлены дополнения к гостевым ОС.) Сразу после установки гостевые ОС просто притормаживают, CPU usage хоста прыгает возле максимума.
Если же потом включать хост и гостевые системы на нем, то включается какой-то механизм экономии, CPU usage на минимуме, прыгает вокруг 90-200 мегагерц, графические интерфейсы гостевых дичайше тормозят (через VMware viclient или web client) . Отклик мыши можно несколько минут ждать.
При этом серверные функции гостевых ОС не тормозят, для них ESXi выделяет нормальные ресурсы, балансирует. Передача файлов по гигабитной сети на честный гигабит. На двух гостевых 2008R2 одного и того же хоста по десять и больше юзеров могли работать в специальном ПО и по RDP вообще без тормозов на прошлой работе. И железо, и дистрибутив ESXi были точно такие же.
Если вы администрируете виртуальную инфраструктуру на базе VMware vSphere (или любого другого стека технологий), то наверняка часто слышите от пользователей жалобы: «Виртуальная машина работает медленно!». В этом цикле статей разберу метрики производительности и расскажу, что и почему «тормозит» и как сделать так, чтобы не «тормозило».
Буду рассматривать следующие аспекты производительности виртуальных машин:
Для анализа производительности нам понадобятся:
Немного теории
В ESXi за работу каждого vCPU (ядра виртуальной машины) отвечает отдельный процесс – world в терминологии VMware. Также есть служебные процессы, но с точки зрения анализа производительности ВМ они менее интересны.
Процесс в ESXi может находиться в одном из четырех состояний:
- Run – процесс выполняет какую-то полезную работу.
- Wait – процесс не выполняет никакой работы (idle) либо ждет ввода/вывода.
- Costop – состояние, которое возникает в многоядерных виртуальных машинах. Оно возникает, когда планировщик CPU гипервизора (ESXi CPU Scheduler) не может запланировать одновременное исполнение на физических ядрах сервера всех активных ядер виртуальной машины. В физическом мире все ядра процессора работают параллельно, гостевая ОС внутри ВМ рассчитывает на аналогичное поведение, поэтому гипервизору приходится замедлять ядра ВМ, у которых есть возможность закончить такт быстрее. В современных версиях ESXi планировщик CPU использует механизм, который называется relaxed co-scheduling: гипервизор считает разрыв между самым «быстрым» и самым “медленным" ядром виртуальной машины (skew). Если разрыв превышает определенный порог, «быстрое» ядро переходит в состояние costop. Если ядра ВМ проводят много времени в этом состоянии, это может вызвать проблемы с производительностью.
- Ready – процесс переходит в данное состояние, когда у гипервизора нет возможности выделить ресурсы для его исполнения. Высокие значения ready могут вызвать проблемы с производительностью ВМ.
Основные счетчики производительности CPU виртуальной машины
CPU Usage, %. Показывает процент использования CPU за заданный период.
Как анализировать? Если ВМ стабильно использует CPU на 90% или есть пики до 100%, то у нас проблемы. Проблемы могут выражаться не только в «медленной» работе приложения внутри ВМ, но и в недоступности ВМ по сети. Если система мониторинга показывает, что ВМ периодически отваливается, обратите внимание на пики на графике CPU Usage.
Есть стандартный Аlarm, который показывает загрузку CPU виртуальной машины:
Что делать? Если у ВМ постоянно зашкаливает CPU Usage, то можно задуматься об увеличении количества vCPU (к сожалению, это не всегда помогает) или переносе ВМ на сервер с более производительными процессорами.
CPU Usage in Mhz
В графиках на vCenter Usage в % можно посмотреть только по всей виртуальной машине, графиков по отдельным ядрам нет (в Esxtop значения в % по ядрам есть). По каждому ядру можно посмотреть Usage in MHz.
Как анализировать? Бывает, что приложение не оптимизировано под многоядерную архитектуру: использует на 100% только одно ядро, а остальные простаивают без нагрузки. Например, при дефолтных настройках бэкапа MS SQL запускает процесс только на одном ядре. В итоге резервное копирование тормозит не из-за медленной скорости дисков (именно на это изначально пожаловался пользователь), а из-за того, что не справляется процессор. Проблема была решена изменением параметров: резервное копирование стало запускаться параллельно в несколько файлов (соответственно, в несколько процессов).
Пример неравномерной нагрузки ядер.
Также бывает ситуация (как на графике выше), когда ядра нагружены неравномерно и на некоторых из них есть пики в 100%. Как и при загрузке только одного ядра, alarm по CPU Usage не сработает (он по всей ВМ), но проблемы с производительностью будут.
Что делать? Если ПО в виртуальной машине нагружает ядра неравномерно (использует только одно ядро или часть ядер), нет смысла увеличивать их количество. В таком случае лучше переместить ВМ на сервер с более производительными процессорами.
Также можно попробовать проверить настройки энергопотребления в BIOS сервера. Многие администраторы включают в BIOS режим High Performance и тем самым отключают технологии энергосбережения C-states и P-states. В современных процессорах Intel используется технология Turbo Boost, которая увеличивает частоту отдельных ядер процессора за счет других ядер. Но она работает только при включенных технологиях энергосбережения. Если мы их отключаем, то процессор не может уменьшить энергопотребление ядер, которые не нагружены.
VMware рекомендует не отключать технологии энергосбережения на серверах, а выбирать режимы, которые максимально отдают управление энергопотреблением гипервизору. При этом в настройках энергопотребления гипервизора нужно выбрать High Performance.
Если у вас в инфраструктуре отдельные ВМ (или ядра ВМ) требуют повышенную частоту CPU, корректная настройка энергопотребления может значительно улучшить их производительность.
CPU Ready (Readiness)
Если ядро ВМ (vCPU) находится в состоянии Ready, оно не выполняет полезную работу. Такое состояние возникает, когда гипервизор не находит свободное физическое ядро, на которое можно назначить процесс vCPU виртуальной машины.
Как анализировать? Обычно если ядра виртуальной машины находятся в состоянии Ready больше 10% времени, то вы заметите проблемы с производительностью. Проще говоря, больше 10% времени ВМ ждет доступности физических ресурсов.
В vCenter можно посмотреть 2 счетчика, связанных с CPU Ready:
Значения счетчика Ready можно посмотреть также в исторической перспективе. Это полезно для установления закономерностей и для более глубокого анализа проблемы. Например, если у виртуальной машины начинаются проблемы с производительностью в какое-то определенное время, можно сопоставить интервалы повешенного значения CPU Ready с общей нагрузкой на сервер, где данная ВМ работает, и принять меры по снижению нагрузки (если DRS не справился).
Ready в отличие от Readiness показывается не в процентах, а миллисекундах. Это счетчик типа Summation, то есть он показывает, сколько времени за период измерения ядро ВМ находилось в состоянии Ready. Перевести данное значение в проценты можно по несложной формуле:
(CPU ready summation value / (chart default update interval in seconds * 1000)) * 100 = CPU ready %
Например, для ВМ на графике ниже пиковое значение Ready на всю виртуальную машину получится следующим:
При подсчете значения Ready в процентах стоит обращать внимание на два момента:
- Значение Ready по всей ВМ – это сумма Ready по ядрам.
- Интервал измерения. Для Real-time – это 20 секунд, а, например, на дневных графиках – это 300 секунд.
Рассчитаем Ready на основе данных из графика ниже. (324474/(20*1000))*100 = 1622% на всю ВМ. Если смотреть по ядрам получится уже не так страшно: 1622/64 = 25% на ядро. В данном случае обнаружить подвох довольно просто: значение Ready нереалистичное. Но если речь идет о 10–20% на всю ВМ с несколькими ядрами, то по каждому ядру значение может быть в пределах нормы.
Что делать? Высокое значение Ready говорит о том, что серверу не хватает ресурсов процессора для нормальной работы виртуальных машин. В такой ситуации остается только уменьшить переподписку по процессору (vCPU:pCPU). Очевидно, этого можно добиться, уменьшив параметры существующих ВМ или путем миграции части ВМ на другие серверы.
Co-stop
Как анализировать? Данный счетчик также имеет тип Summation и переводится в проценты аналогично Ready:
(CPU co-stop summation value / (chart default update interval in seconds * 1000)) * 100 = CPU co-stop %
Здесь также нужно обращать внимание на количество ядер на ВМ и на интервал измерения.
В состоянии сostop ядро не выполняет полезную работу. При правильном подборе размера ВМ и нормальной нагрузке на сервер счетчик со-stop должен быть близок к нулю.
В данном случае нагрузка явно ненормальная:)
Также co-stop вырастет, если для активных ядер одной ВМ используются треды на одном физическом ядре сервера со включенным hyper-treading. Такая ситуация может возникнуть, например, если у ВМ больше ядер, чем физически есть на сервере, где она работает, или если для ВМ включена настройка «preferHT». Про эту настройку можно прочитать здесь.
Чтобы избежать проблем с производительностью ВМ из-за высокого сo-stop, выбирайте размер ВМ в соответствии с рекомендациями производителя ПО, которое работает на этой ВМ, и с возможностями физического сервера, где работает ВМ.
Не добавляйте ядра про запас, это может вызвать проблемы с производительностью не только самой ВМ, но и ее соседей по серверу.
Другие полезные метрики CPU
Run – сколько времени (мс) за период измерения vCPU находился в состоянии RUN, то есть собственно выполнял полезную работу.
Idle – сколько времени (мс) за период измерения vCPU находился в состоянии бездействия. Высокие значения Idle – это не проблема, просто vCPU было «нечего делать».
Wait – сколько времени (мс) за период измерения vCPU находился в состоянии Wait. Так как в данный счетчик включается IDLE, высокие значения Wait также не говорят о наличии проблемы. А вот если при высоком Wait IDLE низкий, значит ВМ ждала завершения операций ввода/вывода, а это, в свою очередь, может говорить о наличии проблемы с производительностью жесткого диска или каких-либо виртуальных устройств ВМ.
Max limited – сколько времени (мс) за период измерения vCPU находился в состоянии Ready из-за установленного лимита по ресурсам. Если производительность необъяснимо низкая, то полезно проверить значение данного счетчика и лимит по CPU в настройках ВМ. У ВМ действительно могут оказаться выставлены лимиты, о которых вы не знаете. Например, так происходит, когда ВМ была склонирована из шаблона, на котором был установлен лимит по CPU.
Swap wait – сколько времени за период измерения vCPU ждал операции с VMkernel Swap. Если значения данного счетчика выше нуля, то у ВМ точно есть проблемы с производительностью. Подробнее про SWAP поговорим в статье про счетчики оперативной памяти.
ESXTOP
Если счетчики производительности в vCenter хороши для анализа исторических данных, то оперативный анализ проблемы лучше производить в ESXTOP. Здесь все значения представлены в готовом виде (не нужно ничего переводить), а минимальный период измерения 2 секунды.
Экран ESXTOP по CPU вызывается клавишей «c» и выглядит следующим образом:
Для удобства можно оставить только процессы виртуальных машин, нажав Shift-V.
Чтобы посмотреть метрики по отдельным ядрам ВМ, нажмите «e» и вбейте GID интересующей ВМ (30919 на скриншоте ниже):
Кратко пройдусь по столбцам, которые представлены по умолчанию. Дополнительные столбцы можно добавить, нажав «f».
NWLD (Number of Worlds) – количество процессов в группе. Чтобы раскрыть группу и увидеть метрики для каждого процесса (например, для каждого ядра многоядерной ВМ), нажмите “e”. Если в группе больше одного процесса, то значения метрик для группы равны сумме метрик для отдельных процессов.
%USED – сколько циклов CPU сервера использует процесс или группа процессов.
%RUN – сколько времени за период измерения процесс находился в состоянии RUN, т.е. выполнял полезную работу. Отличается от %USED тем, что не учитывает hyper-threading, frequency scaling и время, затраченное на системные задачи (%SYS).
%SYS – время, затраченное на системные задачи, например: обработку прерываний, ввода/вывода, работу сети и пр. Значение может быть высоким, если на ВМ большой ввод/вывод.
%OVRLP – сколько времени физическое ядро, на котором выполняется процесс ВМ, потратило на задачи других процессов.
Данные метрики соотносятся между собой следующим образом:
%USED = %RUN + %SYS — %OVRLP.
Обычно метрика %USED является более информативной.
%WAIT – сколько времени за период измерения процесс находился в состоянии Wait. Включает IDLE.
%IDLE – сколько времени за период измерения процесс находился в состоянии IDLE.
%SWPWT – сколько времени за период измерения vCPU ждал операции с VMkernel Swap.
%VMWAIT – сколько времени за период измерения vCPU находилось в состояния ожидания события (обычно ввода/вывода). Аналогичного счетчика нет в vCenter. Высокие значения говорят о проблемах с вводом/выводом на ВМ.
%WAIT = %VMWAIT + %IDLE + %SWPWT.
Если ВМ не использует VMkernel Swap, то при анализе проблем с производительностью целесообразно смотреть на %VMWAIT, так как данная метрика не учитывает время, когда ВМ ничего не делала (%IDLE).
%RDY – сколько времени за период измерения процесс находился в состоянии Ready.
%CSTP – сколько времени за период измерения процесс находился в состоянии сostop.
%MLMTD – сколько времени за период измерения vCPU находился в состоянии Ready из-за установленного лимита по ресурсам.
%WAIT + %RDY + %CSTP + %RUN = 100% – ядро ВМ все время находится в каком-то из этих четырех состояний.
CPU на гипервизоре
В vCenter есть также счетчики производительности CPU для гипервизора, но они не представляют из себя ничего интересного – это просто сумма счетчиков по всем ВМ на сервере.
Удобнее всего смотреть состояние CPU на сервере на вкладке Summary:
Для сервера, как и для виртуальной машины, есть стандартный Alarm:
При высокой нагрузке на CPU сервера у ВМ, работающих на нем, начинаются проблемы с производительностью.
В ESXTOP данные о загрузке CPU сервера представлены в верхней части экрана. Помимо стандартного CPU load, который малоинформативен для гипервизоров, есть еще три метрики:
CORE UTIL(%) – загрузка ядра физического сервера. Данный счетчик показывает, сколько времени за период измерения ядро выполняло работу.
PCPU UTIL(%) – если включен hyper-threading, то на каждое физическое ядро приходится два потока (PCPU). Данная метрика показывает, сколько времени каждый поток выполнял работу.
PCPU USED(%) – то же, что PCPU UTIL(%), но учитывает frequency scaling (либо снижение частоты ядра в целях энергосбережения, либо повышение частоты ядра за счет технологии Turbo Boost) и hyper-threading.
PCPU_USED% = PCPU_UTIL% * эффективную частоту ядра / номинальную частоту ядра.
На этом скриншоте для некоторых ядер из-за работы Turbo Boost’а значение USED больше 100%, так как частота ядра выше номинальной.
Пара слов о том, как учитывается hyper-threading. Если процессы исполняются 100% времени на обоих потоках физического ядра сервера, при этом ядро работает на номинальной частоте, то:
- CORE UTIL для ядра будет 100%,
- PCPU UTIL для обоих потоков будет 100%,
- PCPU USED для обоих потоков будет 50%.
В ESXTOP также есть экран с параметрами энергопотребления CPU сервера. Здесь можно посмотреть, используются ли сервером технологии энергосбережения: C-states и P-states. Вызывается клавишей «p»:
Стандартные проблемы производительности CPU
Напоследок пробегусь по типичным причинам возникновения проблем с производительностью CPU ВМ и дам короткие советы их решению:
Не хватает тактовой частоты ядра. Если нет возможности перевести ВМ на более производительные ядра, можно попробовать изменить настройки энергопотребления, чтобы Turbo Boost работал эффективнее.
Неправильный сайзинг ВМ (слишком много/мало ядер). Если поставить мало ядер, будет высокая загрузка CPU ВМ. Если много, словите высокий co-stop.
Неправильная NUMA-топология на больших ВМ. NUMA-топология, которую видит ВМ (vNUMA), должна соответствовать NUMA-топологии сервера (pNUMA). Про диагностику и возможные варианты решения данной проблемы написано, например, в книге «VMware vSphere 6.5 Host Resources Deep Dive». Если не хотите углубляться и у вас нет лицензионных ограничений по ОС, установленной на ВМ, делайте на ВМ много виртуальных сокетов по одному ядру. Много не потеряете :)
На этом про CPU у меня все. Задавайте вопросы. В следующей части расскажу про оперативную память.
Читайте также: