Тормозит виртуальная машина vmware workstation

Как ускорить работу виртуальной машины

Тем не менее, грамотная оптимизация BM позволит вам увеличить производительность последней без оказания существенного влияние на хостовой компьютер.

Фиксированный размер диска

Используйте фиксированный размер виртуального диска.

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

Используйте дополнения гостевой ОС

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

Особенности использования антивирусов

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

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

Проверьте настройки виртуальной машины вручную

Что касается установленных по умолчанию параметров виртуальной машины, здесь нужно действовать по принципу «доверяй, но проверяй».

Зайдите в настройки вашей ВМ и и проверьте эти параметры:

Оперативная память

Увеличьте, если возможно, объем выделенной ОЗУ до 2 Гб.

Процессор

Выделите максимально допустимое количество ядер процессора и убедитесь, что в пункте PAE/NX стоит галочка. Если в вашей системе виртуализации доступны функции Nested VT-х/AMD-v, включите их, они улучшают виртуализацию.

Дисплей

Выделите виртуальной машине максимальный объем видеопамяти и включите, если выключено, ускорение 2D и 3D.

Установка виртуальной машины на SSD

Файл подкачки и автозагрузка

Не стоит пренебрегать и внутренней оптимизацией. Для увеличения производительности виртуальной машины используйте внутри нее файл подкачки, особенно на популярных Linux-системах. Размер файла свопа в данном случае определяется общими правилами.

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

Источник

Тормозит виртуальная машина vmware workstation

Если бы ВМ не хватало процессора, то хост разогнался бы до номинальной мощности.

Вы ничего не пишите про память. Но,скорее всего, дело в » SATA».

Какие у вас задержки на диск (read/write latenc) в целом по хосту и в разрезе ВМ?

Опишите полную картину, сколько у вас запущено виртуальных машин и какая у них конфгурация по CPU, RAM и какие там операционные системы запущены

С учетом того, что у вас всего 8 Гб оперативной памяти и SATA диск, то рассчитывать вам на многое не получится

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

Но и вопросы не совсем в тему. Описанная мною ситуация типичная, много лет ее наблюдаю. Просто увидел место, где можно вопрос задать, решил воспользоваться.

При этом серверные функции гостевых ОС не тормозят, для них ESXi выделяет нормальные ресурсы, балансирует. Передача файлов по гигабитной сети на честный гигабит. На двух гостевых 2008R2 одного и того же хоста по десять и больше юзеров могли работать в специальном ПО и по RDP вообще без тормозов на прошлой работе. И железо, и дистрибутив ESXi были точно такие же.

Источник

sidadm

записки SAP Basis консультанта

Полезное

понедельник, 1 ноября 2021 г.

Настройка максимальной производительности в VMware Workstation

В этом году я прошёл обучение, а затем успешно сдал сертификационный экзамен, по администрированию среды виртуализации VMware. Наверное, этот факт как-то повлиял на моё мировоззрение. Я решил, после стольких лет использования VirtualBox для своих личных проектов, на персональной рабочей станции попробовать перейти на решение от VMware.

Вы наверное знаете, что среды виртуализации можно разделить на 2 типа:

Примером гипервизора первого типа является VMware ESXi. Эта среда виртуализации, включающая в себя гипервизор со своей операционной системой, устанавливается напрямую на физический сервер. SAP системы в той или иной степени поддерживают это решение от VMware и про это у меня уже была пара постов (ссылка 1 и ссылка 2).

Ко второму типу гипервизоров относятся решения Oracle VirtualBox и VMware Workstation. Для их разворачивания требуется операционная система, предварительно установленная на целевой сервер или компьютер (host server). Поддерживаются распространённые операционные системы: MS Windows, Linux или MacOS. Данный тип гипервизора выбирают для небольших проектов. Обычно разработчики программного обеспечения используют их для тестирования своих разработок в разных операционных системах.

VMware Workstation поставляется в двух версиях :

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

Перейдя на VMware Workstation, как взрослый администратор :), я поставил себе задачу получить максимальную производительность виртуальных машин, работающих на моём рабочем ноутбуке. Собранной в процессе решения задачи информацией решил поделиться с вами.

В третьих, можно проверить, что в BIOS отключены различные энергосберегающие опции, а вместо этого везде выбрана максимальная производительность.

При конфигурировании количества ядер для виртуальных машин, можно руководствоваться правилом: общее количество ядер всех виртуальных машин плюс запас для основной машины не должно превышать двойного количества физических ядер процессора (без учёта Hyper-threading ). Например, если ваш процессор имеет 4 физических ядра, то можно создать максимум 3 виртуальные машины, каждой отдав по 2 ядра, а 2 ядра оставить основному компьютеру. В идеале, конечно, вы должны распределять только имеющиеся ядра, не допуская overhead. Но так как мы говорим про персональные компьютеры (или даже ноутбуки), а не про сервера, то ядер у нас обычно не так много. Исходим из того, что имеем, поэтому максимум двойной overhead.

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

Рис. 1. Настройки типа и версии гостевой операционной системы.

Вот по этой ссылке на официальном сайте можно посмотреть список поддерживаемых гостевых операционных систем.

Первое правило виртуализации: оперативной памяти много не бывает. Оперативная память, для гипервизора, как и для БД SAP HANA, основной ресурс.

У нас же стоит обратная задача: получить максимальную производительность при работе виртуальных машин. Обеспечить это можно, как ни странно, отключив по максимуму механизмы оптимизации. 🙂

Рис. 2. Опции памяти для всех виртуальных машин.

Рис. 3. Настройка памяти для отдельной виртуальной машины.

Во-первых, постарайтесь разместить виртуальные машины на дисках с хорошей скоростью чтения-записи. Раньше рекомендовалось использовать RAID массив на достаточном количестве дисков. Сейчас прекрасным вариантом будет SSD диск. К примеру в VMware Workstation для гостевой операционной системы MS Windows 10 рекомендуется использовать тип диска «NVMe» (рис. 4).

Рис. 4. Рекомендуемый тип диска виртуальной машины.

Драйвер такого типа виртуального диска (из пакета VMware Tools ) показывает хорошую скорость в тестах (рис. 5). Но только если на нижнем уровне находится быстрый SSD диск. В данном примере это даже не NVMe диск, а SSD через интерфейс SATA.

Рис. 5. Тестирование скорости диска в виртуальной машине.

Вариант с максимальной производительностью это толстый диск, хранящийся в одном большом файле (рис. 6).

Рис. 6. Параметры виртуального жесткого диска для максимальной производительности.

Рис. 8. Информация о виртуальном диске и дополнительные утилиты для работы с ним.

Рис. 10. Отключение виртуальной звуковой карты.

Рис. 11. Отключения автозапуска CD/DVD устройства в виртуальной машине.

Ну и так как 3D-графику в виртуальной машине мы тоже обычно не используем, то рекомендуется отключить и её. Читал сообщения, что в предыдущих релизах VMware Workstation включение её очень сильно тормозило интерфейс гостевой операционной системы. Для отключения в настройках виртуальной машины установите курсор мыши на пункт «Display» и снимите галочку напротив пункта «Accelerate 3D graphics» (рис. 12).

Рис. 12. Отключение 3D графики в виртуальной машине.

Говорят, что в свежих релизах VMware Workstation производительность что в оконном режиме, что в полноэкранном одинакова, но «осадочек» остался. 🙂

Рис. 13. Выключение сбора трассировочной информации для виртуальной машины.

Рис. 14. Настройки быстродействия интерфейса MS Windows.

Дополнительно отключите Screen Saver. В виртуальной машине он ни к чему, а ресурсы может расходовать прилично.

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

В четвёртых, пару слов про сеть. Помните, что работа виртуальной машины в режиме соединения с сетью типа «Bridged», требует меньше всего процессорных ресурсов основного компьютера (рис. 15).

Рис. 15. Настройка типа сетевого соединения виртуальной машины.

Надеюсь мои изыскания, будут кому-то полезны. Если есть дополнения, пишите в комментариях.

Источник

Как ускорить работу виртуальных машин VMware Workstation

10 способов, как можно ускорить работу с виртуальными машинами в среде гипервизора VMware Workstation.

VMware Workstation – один из лучших гипервизоров для Windows. Это не самая производительная, но самая стабильная программа, с помощью которой можно виртуально исследовать различные операционные системы (ОС). VMware не конфликтует с другими гипервизорами (как Microsoft Hyper-V), в ней всегда работают дополнения гостевых ОС и прочие функции (в отличие от нестабильной VirtualBox), она функциональная и настраиваемая. Ну а что касается производительности, то здесь можно кое-что предпринять. Как ускорить работу виртуальных машин (ВМ) VMware?

1. Аппаратная часть

При использовании любого гипервизора, как и в случае с физическим компьютером, аппаратная оптимизация первична, программная – вторична. Для работы с VMware не принципиально, но желательно иметь на борту физического компьютера четырёхъядерный процессор, чтобы двое ядер оставались хост-системе (основной ОС), а двое могли бы быть задействованы ВМ.

Для базовых целей типа исследования ОС и тестирования несложного софта будет достаточно 2 Гб оперативной памяти. Разве что гостевым Windows 8.1 и 10 можно выделить 3 Гб, если у физического компьютера имеется 6 или 8 Гб. Выделять больший объём без конкретных целей использования памяти нет надобности.

ВМ, размещённая на одном и том же HDD, где установлена хост-система, будет тормозить даже при мощном процессоре и отсутствии недостатка оперативной памяти. HDD – слабое звено в конфигурации и физических, и виртуальных компьютеров из-за медленной скорости чтения и записи данных. Если в наличии нет SSD, для размещения ВМ желательно выделить отдельный HDD – жёсткий диск, к которому не будет обращаться хост-система. Ну или пойти путём универсального аппаратного апгрейда – реализовать RAID 0 (как минимум). Без последнего задействовать два HDD в работе ВМ можно, если разбросать её файлы по разным дискам.

2. Файлы ВМ на разных HDD

При использовании ВМ и по завершении работы с ней происходит запись данных во все эти файлы. За исключением снапшотов, если они не задействуются. Чтобы распределить нагрузку, можно файл виртуального диска VMDK (или VHD) хранить на одном HDD, а файлы конфигурации ВМ – на другом HDD, в частности, на том же, где размещается хост-система. Для всех ВМ указываем расположение по умолчанию – каталог на одном HDD.

При создании же каждой отдельной ВМ используем выборочную настройку.

И на этапе задания параметров виртуального диска указываем его месторасположение на разделе другого HDD.

Применить такую схему к уже имеющихся ВМ можно путём удаления используемого виртуального диска в параметрах машины. А затем добавления этого же диска по-новому, когда его файл VMDK (или VHD) уже будет перемещён на другой HDD.

3. Фиксированные виртуальные диски

Немного ускорить работу ВМ на HDD можно путём работы с фиксированными, а не назначенными по умолчанию в VMware динамическими виртуальными дисками. Для этого при создании ВМ на этапе указания размера диска необходимо выбрать его сохранение в одном файле и установить галочку опции выделения всего места.

При таком раскладе будет создан виртуальный диск фиксированного типа. Его файл со старта займёт указанный объём, и ресурс HDD при непосредственной работе с ВМ не будет распыляться ещё и на операцию по выделению места на физическом диске.

4. Дефрагментация HDD

Ускорить работу ВМ на HDD можно традиционным методом оптимизации этого типа жёстких дисков – дефрагментацией. В среде хост-системы Windows желательно время от времени проводить эту процедуру с использованием эффективных сторонних программ.

5. Тормоза после приостановки ВМ

Работающие с VMware наверняка замечали, что в большинстве случаев после приостановки одной ВМ сразу же оперативно запустить другую нереально. Нужно немного подождать. Естественно, речь идёт о случаях расположения ВМ на HDD. Как только мы приостанавливаем ВМ, сразу же начинается активная запись данных на диск с его загрузкой вплоть до 100%. И так может длиться несколько минут. При приостановке ВМ содержимое оперативной памяти гостевой ОС каждый раз записывается в файл «.vmem». Он находится в числе прочих файлов конфигурации ВМ и планировано занимает столько места на диске, сколько машине выделено «оперативки». По факту же размер файла варьируется в зависимости от записанных в него в последний раз данных.

Активная запись в файл «.vmem» сильно нагружает HDD. Назначение такой операции – запуск гостевой ОС в сохранённом состоянии при возможных сбоях в работе ВМ. Нужна ли эта возможность такой ценой – решайте сами. Если не нужна, запись данных в файл «.vmem» можно отключить. И тем самым ускорить переключение между приостановленными ВМ. Для этого необходимо открыть в любом TXT-редакторе файл конфигурации ВМ «.vmx», дописать в конце такую строчку:
mainMem.useNamedFile = «FALSE»

6. Обрезка страничной памяти

В дополнительных параметрах ВМ есть изначально неактивная опция отключения обрезки страничной памяти. Если её активировать, фактическое выделение оперативной памяти ВМ будет происходить быстрее.

7. Плеер VMware

В состав компонентов VMware Workstation входит приложение Player. Это упрощённый вариант гипервизора, ограниченный функционально, но также и более лёгкий. Создавать и настраивать ВМ лучше, конечно же, с использованием основного компонента VMware Workstation. А вот непосредственно проводить работу с гостевыми ОС можно внутри более шустрого плеера.

8. ПО EFI

ВМ с ПО EFI эмулируют устройства, соответственно, с BIOS UEFI. Они включаются и перезапускаются немного быстрее, чем ВМ, эмулирующие устройства с обычным BIOS. Плюс к этому, EFI-машины могут быть запущены с UEFI-флешек без помощи сторонних средств.

9. Оптимизация гостевых ОС

Ускорить работу ВМ можно за счёт оптимизации гостевых Windows. В числе таковых в частности: отключение анимации, обоев, неиспользуемых служб, телеметрии, обновлений, Timeline (для версии 10). В качестве платформы для тестирования только стороннего софта можно и вовсе в качестве гостевой ОС выбрать Windows 7 или 8.1 Embedded – урезанные сборки этих версий, заточенные под работу со слабым железом.

В гостевых Windows можно смело работать с отключённым Защитником и без стороннего антивируса. За безопасность будет отвечать антивирус хост-системы. А вот для последней желательно подобрать такой антивирусный продукт, чтобы защищал, но при этом не мешал.

10. Правильный антивирус для хост-системы

Активность ВМ – это непаханое поле азарта для антивирусов. VMware Workstation, как и любой другой гипервизор, активно работает с записью данных. Причём работает с большими объёмами данных. И все эти данные антивирусы проверяют в рамках проактивной защиты. Чтобы не создавать лишней нагрузки при работе с ВМ, для хост-системы желательно подобрать хороший антивирус – эффективный в плане обнаружения реальных угроз, при этом минимально использующий аппаратные ресурсы компьютера.

Источник

Базовый траблшутинг в среде VMware vSphere или что делать, если тормозит ВМ

Что-то в последнее время технические статьи о виртуализации (да и не только о виртуализации) скатываются к формату «в новой версии ожидается такая фича». Складывается ощущение, что разбор механизмов и описание опыта, проблем и решений интересны только зарубежным экспертам. С другой стороны, есть такая проблема у экспертов — если что-то изучил, оно становится элементарным и воспринимается само собой разумеющимся, настолько, что писать об этом как-то глупо. Особенно если уже было кем-то описано где-то. Когда-то. На каком-то языке. Ниженаписанное — плод консолидации личных заметок, сначала предназначавшийся для личного упорядочивания мыслей, но наупорядочив значительный объём текста, подумал, что кому-то может пригодиться.

Типовая проблема «виртуализаторов» — владелец сервиса, заказчик или пользователь жалуется, что у него «тормозит» виртуальная машина. Так как виртуализация предполагает консолидацию большого количества ВМ на базе одного комплекта аппаратных ресурсов, переподписку (overprovision — когда мы предполагаем, что серверы не затребуют одновременно максимум своих ресурсов, а значит, например, в 40 ГБ физической памяти мы можем натолкать не 10 серверов по 4 ГБ RAM, а 15, используя Dynamic Memory), а кроме того, серверы могут тормозить и из-за ошибок в программных компонентах и их настройках, то каждый раз приходится решать за что хвататься и куда смотреть в первую очередь. Особенно, если с таким ёмким описанием проблемы, как «тормозит машина» не предоставлено никакой диагностической информации, как чаще всего и бывает. Под катом небольшое руководство для этого случая.
Конечно, всё зависит от специфичности реализации конкретной инфраструктуры, но практика показывает, что в большинстве случаев имеет смысл следующая последовательность анализа подсистем ВМ:

На практике, до 4-го этапа почти никогда не доходит, после третьего (а то и после первого) имеет смысл запускать (или запрашивать) параллельную диагностику гостевой ОС, но диски стоит проверить сразу — самая значительная часть инцидентов с жалобами на производительность связано с ними. Если, конечно, у вас не All-Flash массив.

А теперь чуть подробнее по каждому пункту.

1. Диски (подсистема хранения)

Самый ключевой тут показатель — это Latency. Задержка времени отклика. Она складывается из большого количества промежуточных элементов и зависит от большого количества факторов. Сюда входит время отклика гипервизора, время прохождения сигнала по кабелям и промежуточным устройствам (коммутаторы, адаптеры и контроллеры), время нахождения в очередях на всех этих устройствах, если нагрузка на них превышает норму и ещё некоторые нюансы, такие как повреждения оборудования. Однако, оставив нюансы для расширенной диагностики, требуемой в редких случаях, можно выделить простой общий показатель — время задержки от ВМ до дисков.

Perfomance Tab

(закладка Perfomance в vSphere Client и счетчики производительности).

Наиболее часто используемые счётчики группы Disk:

Highest Latency — норма до 10-15 мс. Если регулярно выше, надо что-то менять, хотя разовые пики не страшны;
Average write requests per second;
Average read requests per second.

Наиболее часто используемые счётчики группы Virtual Disk:

Read/Write latency;
Average number of outstanding read/write requests — количество одновременных IO-запросов (если их число держится выше 30 в сумме на датастор или на сервер, это будет приводить к дополнительным задержкам);

ESXTop

Консольная утилита ESX/ESXi. Выдаёт целую кучу диагностической информации об отдельно взятом ESXi. Базовую информацию по использованию можно получить, нажав h после запуска утилиты.

В плане диагностики дисковой подсистемы будет полезен контекст виртуальных дисков (нажать v) и контекст HBA-адаптеров (нажать d). В последнем случае стоит обратить внимание на следующие показатели:

KAVG (Kernel Latency Avg) — время отклика гипервизора (норма — до 1 мс);
DAVG (Device Latency Avg) — время отклика от HBA до дисков (норма — 10-15мс);
GAVG (Guest Latency Avg) — время отклика для гостевой системы = сумма KAVG и DAVG

Кстати, в этой же области исследований стоит сразу проверить нет ли у ВМ снапшота. А то и нескольких. Они могут стать проблемой не только паденрия производительности, но и сбоев операций резервного копирования, клонирования и миграции.

2. Процессор

Здесь аналогичный по важности дисковым задержкам показатель — CPU Ready. Также стоит обращать внимание на Used, Wait и Co-Stop. Мониторить можно также через Perfomance Tab или ESXtop.

CPU Ready (%RDY) — % времени, когда ВМ готова производить какие-то вычисления, но физические процессоры в данный момент заняты другими процессами (системными или другими ВМ) и vCPU виртуальной машины находятся в режиме ожидания. Нормой считается значение до 10%. При росте этого показателя выше 40% развивается высокая вероятность сбоев и зависаний гостевой ОС. Причиной вынужденного простоя может стать:

Wait (%WAIT) — % времени, в течение которого ВМ ждёт окончания какой-то активности VMkernel. Чаще всего это дисковая IO-активность. Высокие показатели этого счётчика могут говорить о недостаточно быстром отклике от датастора. Также проблему могут вызывать некорректная работа USB или COM-портов или виртуальный CD/DVD-приводы, в который замонтирован отсутствующий ныне ISO.

Used (%USED) — % времени, в течение которого машина реально работала. Если он около нуля, значит машина просто стоит или её пересайзили процессорами. Если он около 100 (на каждый vCPU), значит или недосайзили, или в ней что-то зациклилось (если она ещё и не откликается при этом), или сейчас там лопатится какой-то квартальный отчёт. Этот показатель стоит изучать при размышлении на тему «дать ли ВМ ещё процессоров, чтоб быстрее работала?». Если у неё 4 ядра и ни одно не задействовано более чем на 50%, то 8 ядер её скорее всего не ускорят. Возможно даже замедлят (см. CPU Ready).

Инструменты диагностики те же.

Perfomance Tab

Удобно, что можно посмотреть данные не только по машине в целом, но и по каждому ядру. Кроме того, доступна статистика за период. Однако, информация предоставляется не в процентах, а в миллисекундах. Так как данные собираются не в real-time, а за определённый интервал, отображается, сколько именно mc процессор находился в том или ином состоянии. Перевести в проценты можно разделив значение на длину интервала и умножив на 100%.

Пример: на рисунке диаграмма с интервалом 20 секунд (real-time), то есть 20 000 мс. То есть среднее CPU Ready будет 50288 / 20000 * 100% = 251.44%. Так как у машины 4 ядра, а не одно, то результат делим на 4 и получаем почти 63%. Машина очень страдает. А всё потому, что лежит на третьем уровне вложенности Resource Pools с низкими shares на каждом.

Ещё раз, формула преобразования: / / * 100%. Получается 5% на 1000 мс для одного ядра.

ESXTop

Тут значение указано сразу в %. Только оно указано сразу в сумме для всех ядер, так что не стоит пугаться чисел больше 100. Делите на количество vCPU машины.

3. Оперативная память

Базовая диагностика здесь простая — да или нет. Если есть факт balooning’а значит хосту не хватает памяти и процессы гостевых ОС страдают, потому что активно используется файл подкачки. Если есть факт свопинга на уровне гипервизора, надо срочно принимать меры — машина попавшая в своп впадает в кому в 100% случаев (по крайней мере моей практики). Вышеуказанные факты позволяют определить такие счётчики как

Balloon (MCTLSZ) — количество памяти, вытянутое baloon-драйвером из гостевых ОС.

4. Сеть

Чтобы проблемы были на уровне сети, в случае жалоб на отдельную виртуальную машину, я в своей практике помню только один случай — когда в VDI использовалась какая-то дешёвая веб-камера, гнавшая несжатый поток видео и забивавшая все 100 Мб/с.

Стоит мониторить такие счётчики:

Transmit Dropped Packets (%DRPTX) — количество (или процент в случае esxtop) отброшенных отправленных пакетов;

Receive Dropped Packets (%DRPRX) — количество (процент) отброшенных принятых пакетов.

Ненулевое их значение, возникающее на регулярной основе говорит о некорректной работе сетевых устройств или некорректной их настройке.

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

Источник