Тормозит виртуальная машина. Виртуальная машина и советы по ускорению её работы

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

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

Согласитесь, что при таком раскладе виртуальная машина будет тормозить, по крайней мере это точно будет заметно пользователю. По это причине разработчики стараются применять определенные ухищрения, чтобы как-то ускорить процесс работы виртуальной машины – оптимизировать его. Например, разработчики из компании Parallels придумали следующее ухищрение: они стали предоставлять жесткому диску дополнительный уровень буферизации запросов, что в свою очередь позволило гостевой ОС Windows стартовать гораздо быстрее.

Не стоит делать вывод, что виртуальная машина способна исключительно тормозить работу любимых нами программ и утилит. Может показаться невероятным, но это факт, подтвержденный не одним примером, некоторые приложения работают в виртуальных машинах гораздо быстрее нежели на реальном компьютере. Вы можете сами убедиться в этом, правда для этого вам потребуется компьютер с многоядерным процессором и конечно же требовательное к системным ресурсам приложение, которое по какой-то причине не умеет правильно работать на многоядерном процессоре. Таких программа масса, найти одну из них в Интернете и скачать для эксперимента не составит никакого труда. Если запустить такое приложение в виртуальной среде, выделив для нее не четыре процессорных ядра, а скажем два или один, то оно в виртуальной машине будет работать намного быстрее и стабильнее, нежели на реальном компьютере. Помимо этого, дополнительное кэширование (о котором мы говорили выше) в хосте гостевого жесткого диска может значительно ускорить работу гостевой операционной системы. Стоит отметить, что такой способ ускорения работы виртуальной машины называется опасным, так как грозит потерей всех данных гостевой операционной системы (а возможно и разрушением ее файловой системы), если в момент работы внезапно произойдет отключение питания.

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

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

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

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

1. Диски.
2. Процессор.
3. Оперативная память.

.

На практике, до 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% развивается высокая вероятность сбоев и зависаний гостевой ОС. Причиной вынужденного простоя может стать:

• интенсивное потребление процессорных ресурсов большим количеством ВМ, причём суммарное количество vCPU существенно превышает количество логических ядер (переподписка).
• Наличие oversized ВМ (виртуальные машины с большим количеством недозагруженных vCPU, например если у машины 16 ядер, каждое из которых работает на 1-20% мощности). Проблема тут в том, что при большом количестве vCPU, планировщику гипервизора приходится синхронизировать их работу, что приводит к периодическому «замораживанию» некоторых ядер или даже всей машины, пока не освободится полное количество логических ядер, соответствующее количеству vCPU, необходимое для определённой операции. Механизм называется Co-Stop, и соответствующий счётчик будет расти в этом случае. Это главный аргумент против набивания виртуальной машины виртуальными процессорами «про запас» (второй аргумент - NUMA, но он уже за рамками статьи). Лучше 2 ядра, загруженных на 80%, чем восемь ядер по 20%. В большинстве случаев.
• Если использование CPU для виртуальной машины ограничено на уровне Resource Pool или самой машины. По достижению определённого порога, машина не получит процессорных ресурсов и будет накапливать CPU Ready. В этом случае будет увеличиваться значение счётчика Max-Limited (%ML).

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 на каждом.

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

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

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

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

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

Swapped (SWCUR) - количество памяти, помещённое в.vswp (то есть на жёский диск).

4. Сеть

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

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

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

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

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

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

В данной статье мы рассмотрим несколько способов повышения производительности виртуальной машины VMware Workstation, Oracle VirtualBox, Microsoft Hyper-V или любой другой. Виртуальные машины довольно требовательны к характеристикам компьютера, ведь во время их работы на ПК одновременно запущено несколько операционных систем. Как результат, виртуальная машина может быть значительно медленнее основной операционной системы или вообще работать с притормаживанием.

В данной статье мы рассмотрим несколько способов повышения производительности виртуальной машины , 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 или