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

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

На среднем по мощности ПК эмулируемые операционные системы могут функционировать относительно стабильно, а при грамотной настройке параметров ВМ, можно выжать максимум производительности. Комфортная работа важнее всего, не так ли?

Нижеследующие несколько советов помогут это сделать, не зависимо от того, какую систему виртуализации вы выбрали. Это могут быть наиболее популярные и достаточно функциональные , VMware или, например, менее распространенные в среде обычных пользователей – Virtual PC, Parallels и т.д.

Давайте посмотрим, что мы сможем сделать для повышения производительности. Приступим?!

ВИРТУАЛЬНАЯ МАШИНА

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

Установите инструменты своей виртуальной машины . После установки операционки, первое, что вам нужно сделать, это инсталлировать Дополнения гостевой ОС, которые помогают работать оборудованию быстрее. Необходимый пункт находится в меню “Устройства” гостевой операционной системы VirtualBox. Для завершения установки следуйте инструкциям на экране.

Добавьте исключения в вашем антивирусе . Любая может проверять файлы вашей ВМ при каждом доступе, снижая при этом производительность. Это бесполезное сканирование, вирусов она не обнаружит. Чтобы ускорить процесс, вы можете добавить весь каталог виртуальной машины в список исключений антивируса.

Побеспокойтесь о включении Intel VT-x/AMD-V . VT-x и AMD-V – специальные процессорные инструменты, которые улучшают виртуализацию. Могут активироваться автоматически, а могут и вручную. Возможно, вам придется зайти в БИОС вашего компьютера и включить параметр самостоятельно. Также стоит убедиться в том, что он включен и в настройках VirtualBox.

Выделите больший объем оперативной памяти . Виртуальные машины прожорливы, вследствие чего, рекомендуется выделять им не менее 2 Гигабайт ОЗУ. Можно и больше, но желательно не менее одной трети от доступной.

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

Добавьте видеопамяти . Настройка некоторых параметров видео также может повысить скорость. Например, включение функции 2D или 3D-ускорения позволит вам использовать некоторые приложения с более разумной скоростью.

Используйте по возможности твердотельный диск . SSD – является одним из лучших мест для размещения систем виртуализации.

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

Повышение производительности внутри . Ваша виртуальная ОС может быть настроена так же, как и основная операционная система. Сократите количество фоновых приложений, а также программ в . Используйте инструмент “Оптимизация дисков” (дефрагментация) и т.д. На этом всё!

Просмотрите список всех компьютерных советов в . Ждем вашего участия в нашей группе в ФБ.

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

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

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

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

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

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

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

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

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

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

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

ВМ состоит из:

• файлов виртуального жёсткого диска (обычно это тип VMDK, но VMware также может работать с типом VHD);
• файлов конфигурации самой ВМ;
• файлов снапшотов;
• кэша (данных, участвующих в сообщении хост- и гостевой ОС).

При использовании ВМ и по завершении работы с ней происходит запись данных во все эти файлы. За исключением снапшотов, если они не задействуются. Чтобы распределить нагрузку, можно файл виртуального диска 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, как и любой другой гипервизор, активно работает с записью данных. Причём работает с большими объёмами данных. И все эти данные антивирусы проверяют в рамках проактивной защиты. Чтобы не создавать лишней нагрузки при работе с ВМ, для хост-системы желательно подобрать хороший антивирус – эффективный в плане обнаружения реальных угроз, при этом минимально использующий аппаратные ресурсы компьютера.

Метки: ,

Медленная работа Windows 10 на виртуальной машине — довольно часто обсуждаемая проблема на Интернет-форумах. Пользователи жалуются на то, что кнопка Пуск, Центр уведомлений и значки программ в панели задач реагируют на клики с большой задержкой, а процесс svchost.exe грузит процессор виртуальной машины на 100% в состоянии бездействия. При этом отклик графического интерфейса бывает настолько медленным, что работать с виртуалкой просто невозможно. Давайте разберемся, как ускорить Windows 10 на виртуальной машине Virtualbox.

Удалите вирусы и вредоносное ПО

Установите Дополнения гостевой ОС

Дополнения гостевой ОС (Guest additions) — это набор драйверов для виртуального железа. Его обязательно нужно установить сразу после установки ОС. Для пакета дополнений периодически выходят обновления, о чем вы будете уведомлены. Для установки щелкните Устройства и выберите Подключить образ диска Дополнений гостевой ОС:

После этого запустите либо вручную запустите файл VBoxWindowsAdditions.exe с виртуального DVD-привода.

Используйте настройки по умолчанию для виртуальной машины

Имеется в виду — для конкретной ОС на виртуальной машине. Естественно, при установке ОС на виртуалку необходимо правильно выбрать тип и версию операционной системы.

• Не выделяйте все физические ядра под виртуальную машину. Именно в этом случае часто наблюдается необъяснимая загрузка процессора процессом svchost.exe под 100% в состоянии простоя.
• Если у вас 4-ядерный процессор, то в большинстве случаев оптимальным будет выделить 2 ядра под виртуалку. Поэкспериментируйте с количеством ядер и понаблюдайте за тем, как ведет себя система.
• Для работы Windows 10 на Virtualbox выделите от 2 до 4 ГБ ОЗУ, в зависимости от того, сколько установлено на компьютере. Помните, что у вас должно остаться 4 ГБ для работы Windows 7, 8 или 10 на носителе (т.е. реальном компьютере).

Не изменяйте никакие настройки машины, если вы не уверены в правильности своих действий. Часто пользователи пытаются ускорить Windows 10 на Virtualbox, добавляя ядра до отказа и изменяя другие параметры, но это наоборот приводит к снижению скорости работы машины.

Переместите файл виртуального жесткого диска на SSD

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

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

Обновите Virtualbox до последней версии

Нередко устраняются баги. Особенно это касается свежих версих ОС — например, Windows 10 на данный момент. Для обновления Virtualbox на компьютере-носителе выключите все виртуальные машины и выберите Файл — Проверить обновления :

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

Включите поддержку виртуализации в UEFI / BIOS

Virtualization Technology позволяет виртуальной машине использовать дополнительные возможности железа. Если у вас в BIOS (UEFI) есть такой параметр, обязательно включите его.

Отключите визуальные эффекты Windows 10 в виртуальной машине

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

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

Типовая проблема «виртуализаторов» - владелец сервиса, заказчик или пользователь жалуется, что у него «тормозит» виртуальная машина. Так как виртуализация предполагает консолидацию большого количества ВМ на базе одного комплекта аппаратных ресурсов, переподписку (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%) обращений или собственных потребностей при диагностике и тестировании, этого достаточно.