Сброс буферов SAP инстанции

В 2015-2016 годах я публиковал цикл из 5 статей про буферизацию на уровне сервера приложений SAP. Если вы ещё не читали, то рекомендую ознакомиться. Финальный пост и ссылки на предыдущие статьи серии можно найти тут. 

Буферы на уровне сервера приложений SAP (его AS ABAP части) играют важную роль в производительности системы (рис. 1). Буферы недостаточного размера могут существенно замедлять скорость выполнения транзакций и считывания данных, а также увеличивать время отклика при работе в системе. Не так давно, в постах (ссылка 1, ссылка 2) на реальном примере я показал как можно проанализировать и внести корректировки в настройки областей памяти и буферов SAP инстанции. В результатах невооружённым взглядом видно, что правильно настроенные области могут ускорить работу системы.

Рис. 1. Пример списка буферов SAP инстанции, отображаемых в транзакции ST02.

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

Решением таких проблем часто может быть рестарт SAP инстанции. Так как все буферы хранятся в оперативной памяти, то при останове инстанции они теряются. А при старте пустые наполняются данными из таблиц базы данных. Но полный рестарт инстанции не всегда возможен. Например, работает долгое фоновое задание, которое при рестарте будет остановлено и его придётся запускать заново. 

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

Данные команды я уже упоминал в этом посте, но решил вынести их в отдельный пост. Так будет легче найти их в блоге. Вот эти команды:

• /$SYNC - сброс всех буферов, кроме Program Buffer,
• /$CUA - сброс CUA buffer,
• /$TAB - сброс TABLE buffer (в зависимости от версии системы: двух или одного),
• /$TAB <table_name> - сброс буферов только для таблицы <table_name>,
• /$NAM - сброс Nametab buffer,
• /$DYN - сброс Screen buffer,
• /$ESM - сброс Exp./ Imp. Shared Memory Buffer,
• /$PXA - сброс Program Buffer (PXA),
• /$OBJ - сброс Shared Buffer.

Команды сброса надо набирать в поле ручного ввода транзакции в SAP GUI (рис. 2). Действуют они только на текущую инстанцию. 

Рис. 2. Ввод команды для сброса табличных буферов SAP инстанции.

Про последнюю команду (/$OBJ) в прошлый раз я не упоминал. Она добавилась. Дополнительное упоминание про сброс этого буфера можно найти в SAP note # 100923 - Problems during displacement in the shared buffer.

При принятии решения о сбросе буферов инстанции помните, что: 

• Сброс буферов резко снижает производительность работы данной инстанции.
• Сброс буферов (также как и рестарт инстанции) может помочь привести систему в порядок, но первопричину сбоя таким способом вы не решите. 
• Делайте сброс только понимая что вы делаете. 
• Постарайтесь выявить конкретный буфер и сбросить только его, а не все буферы сразу (/$SYNC). 

Дополнительно существует возможность сбросить буфер полномочий для пользователя. Вот в этом посте я рассказывал про то, как с помощью транзакции SU53 проанализировать каких полномочий не хватает пользователю в SAP системе. А вот тут рассказывал про буфер полномочий, который хранится в контексте пользователя. В SU53 можно сбросить этот буфер: выберете пункт меню "Значения полномочий (Authorization values) -> Сбросить буфер пользователя (Reset User Buffer)" и буфер текущего пользователя сбросится (рис. 3).

Рис. 3. Сброс буфера полномочий для пользователя.

Автор: Шиболов Вячеслав Анатольевич

P.S. Я понимаю, что я могу знать далеко не всё. Если у вас есть дополнения по этой теме, то напишите в комментарии. Спасибо.

Особенности мониторинга ресурсов виртуальных машин в VMware vSphere

В прошлый раз я писал о том, как настроить виртуальные машины, работающие в среде VMware Workstation, для обеспечения их максимальной производительности. Сегодня же хотел поговорить про решения Enterprise уровня от компании VMware. А в частности про мониторинг использования ресурсов виртуальных машин в VMware vSphere.

Если кто-то не сильно разбирается в маркетинговых названиях, поясню. У компании VMware есть гипервизор, который устанавливается на физическую машину, называется он - VMware ESXi. Для управления и мониторинга у ESXi имеется встроенная графическая web-консоль. Но, если виртуализированных хостов в дата-центре много, то управлять этим хозяйством становится сложнее. Так как для мониторинга или изменения конфигурации гипервизоров необходимо входить на web-консоль каждого ESXi. Для упрощения данной задачи (конечно, за отдельные деньги) компания предлагает решение VMware vCenter. В этом случае выделенный виртуальный сервер  предоставляет единую точку входа для мониторинга, управления и конфигурации ESXi хостов вашей организации. Помимо общей точки входа вы получаете дополнительные функции, например, vMotion (перенос работающих виртуальных машин между ESXi хостами) или HA кластер. Комплексное решение "ESXi + vCenter" и называется VMware vSphere. Достаточно подробно про эти решения я рассказывал в этом посте. 

Раз с названиями разобрались, двигаемся дальше, ближе к теме сегодняшнего поста. 

На хосте под управлением гипервизора ESXi работают виртуальные машины. Мониторинг ресурсов сервера (процессор, память, сеть и т.д.) в случае виртуализации рекомендуется выполнять не на уровне операционной системы виртуальной машины, а (если вам это доступно) на уровне гипервизора VMware.

Web-консоль VMware ESXi позволяет выполнять мониторинг виртуальных машин лишь в реальном времени: статистика по загрузке процессоров, памяти, дисков и сети собирается и хранится только за последний час (рис. 1).

Рис. 1. Пример панели мониторинга процессора виртуальной машины в ESXi.

Согласитесь, что для промышленных систем это несерьёзно. Мониторинга фактически нет. Можно отметить, что на уровне операционной системы ESXi сервера (помните, что в основе это Linux) есть утилита esxtop (я упоминал про неё тут), но она тоже показывает только текущую нагрузку в системе. 

В свою очередь VMware vCenter имеет гораздо больше возможностей по мониторингу. В его консоли отображается не только текущая картина потребления ресурсов, но и собирается база статистики за прошедшие периоды. Можно выбрать различные метрики: процессорные ресурсы (загрузка в % или в MHz), оперативная память, swap-область, дисковая подсистема (несколько метрик), сеть и так далее. Данные для каждой метрики можно выбрать из стандартного набора интервалов:

• real-time,
• last day,
• last week,
• last month,
• last year,
• или задать свой интервал через custom interval.

Режим отображения real-time похож на то, что можно найти в консоли ESXi и обладает самой высокой точностью данных. Достигается это за счёт частоты сбора. Мне кажется, данные собираются раз в секунд 15-30. А вот дальше есть интересный нюанс, ради которого я и начал писать этот пост. Все остальные интервалы отображают менее детализированные данные, так как vCenter автоматически выполняет агрегацию данных. Если войти в раздел "Configure -> Settings -> General" вашего виртуального Datacenter, то можно увидеть параметры для сбора статистики. Значения по умолчанию выглядят так (рис. 2).

Рис. 2. Настройки сбора и агрегации статистики производительности.

Обратите внимание, что для статистики сохранённой за последний день (last day) данные собираются раз в 5 минут, для последней недели (last week) раз в 30 минут, для месяца (last month) раз в 2 часа, а для года (last year) раз в день. Вы можете попробовать поменять настройки, но обнаружите, что самые глубокие доступные значения параметров для хранения статистики выглядят так (рис. 3).

Рис. 3. Максимально глубокие значения для хранимой статистики.

Подкрутить можно только первый уровень: для последних 5 дней хранить данные с частотой 1 минута. Глубину данных за более длительные периоды изменить нельзя. 

Кстати, хочу обратить внимание, что при изменении этих настроек VMware дополнительно рассчитывает требования к дисковому пространству для хранения статистики (рис. 3). Причём, вы можете подкорректировать количество хостов и виртуальных машин в вашем Datacenter для отображения более реальных значений для текущей инфраструктуры. 

Снижение глубины статистики для прошедших периодов было бы не такой большой бедой, если бы не логика работы vCenter в этой части. Снижая частоту хранимых исторических данных, он не просто отбрасывает лишние значения, а автоматически агрегирует данные, усредняя значения. То есть для статистики, хранимой за последнюю неделю, берётся среднее значение с параметров за каждый 30 минутный интервал. А для интервалов старше недели, вообще за каждые 2 часа. Такая логика работы, как я понял, жёстко зашита в vCenter и приводит к сглаживанию показателей нагрузки в зависимости от запрашиваемого интервала. 

Давайте я продемонстрирую это наглядно на одной из систем. Рассмотрим статистику по загрузке процессора виртуальной машины последовательно за разные периоды (рис. 4 - 8).

Рис. 4. Просмотр статистики загрузки CPU в реальном времени.

Рис. 5. Просмотр статистики загрузки CPU за последние сутки.

Рис. 6. Просмотр статистики загрузки CPU за последнюю неделю.

Рис. 7. Просмотр статистики загрузки CPU за последний месяц.

Рис. 8. Просмотр статистики загрузки CPU за год.

Замечаете как показатели утилизации процессора из 50-75% постепенно превращаются в 40-60%, потом опускаются ниже 50%, а в годовом разрезе вообще не поднимаются выше 15%? :) 

Рассмотрим ещё один пример. График загрузки процессора виртуальной машины за неделю показывает пиковые значения не выше 60%, и то только один раз. В остальные дни не выше 50%. Можно сделать преждевременные выводы, что процессорных ресурсов данной системе хватает.

Рис. 9. Пример статистики загрузки процессора виртуальной машины за неделю.

А при этом на интервалах real-time для данной виртуальной машины фиксировались пики до 100% (рис. 10-12).

Рис. 10. Мониторинг загрузки процессора виртуальной машины в реальном времени.

Рис. 11. Мониторинг загрузки процессора виртуальной машины в реальном времени.

Рис. 12. Мониторинг загрузки процессора виртуальной машины в реальном времени.

Если же обратиться к статистике за месяц, то опять видим ту же картину: пики едва превышают 40%. Сравните последние дни на разных графиках, где мы точно знаем, что были значения и по 100%. На графике с большим периодом отображения таких значений просто нет: они сглажены агрегацией (рис. 13). 

Рис. 13. Пример статистики загрузки процессора виртуальной машины за месяц.

Какие выводы из всего этого можно сделать? 

Во-первых, нужно учитывать эту особенность сбора и отображения статистики по загрузке ресурсов виртуальной машины в VMware. Годовой график смотреть смысла нет, статистика гораздо ниже реальной. И даже в помесячном разрезе сглаженный график ниже реального где-то на 50%. 

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

Для некоторых приложений могут быть критичны, например, процессорные ресурсы сервера. И при их нехватке (достижении утилизации в 100%), даже на короткий период, происходят события в виде отказа в обслуживании или резкого снижения производительности приложений. 

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

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

В отслеживании пиков в потреблении процессорных ресурсов может помочь настройка Alarms в vCenter. По умолчанию существует Alarm с именем "Virtual machine CPU usage", который срабатывает при потреблении больше 75% процессорных ресурсов в течении 5 минут (рис. 14).

Рис. 14. Настройки Alarm "Virtual machine CPU usage".

Возникновение этих событий для виртуальной машины в прошлом можно найти в разделе Events (рис. 15).

Рис. 15. История возникновения событий превышения утилизации процессора виртуальной машиной.

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

Все эти рассуждения справедливы так же для распределения и мониторинга других ресурсов виртуальных машин: оперативной памяти, сети, дисков.

Автор: Шиболов Вячеслав Анатольевич

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

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

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

• тип 1 - физический гипервизор (bare metal hypervisor), который устанавливается на физический сервер.
• тип 2 - гипервизор, устанавливаемый поверх операционной системы (hosted hypervisor). 

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

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

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

• VMware Workstation Pro (требует приобретения платной лицензии),
• VMware Workstation Player (распространяется бесплатно для личного пользования).

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

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

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

• процессорные ресурсы,
• оперативная память,
• жесткий диск,
• другое оборудование,
• программное обеспечение,
• другое (всё остальное).

Процессорные ресурсы

Во-первых, необходимо проверить, что ваш процессор имеет аппаратную поддержку виртуализации и в BIOS основной машины включены опции поддержки: Intel VT-x или AMD AMD-V. Если система поддерживает "Hardware-Assisted MMU Virtualization": опции Intel EPT (extended page tables) или AMD RVI (rapid virtualization indexing) или AMD NPT (nested page tables), то тоже обязательно включаем. Первый механизм в условиях виртуализации позволяет эффективнее (с меньшими накладными расходами) распределять процессор между виртуальными машинами, а второй - память.

Во-вторых, если процессор поддерживает Hyper-threading, то рекомендуется активировать  поддержку этого механизма в BIOS. Hyper-threading, когда один процессорный юнит (ядро) обрабатывает 2 очереди команд, даёт скорее большую утилизацию процессорных ресурсов, так как процессор меньше простаивает. Но при правильном использовании этой технологии можно добиться и повышения производительности всей системы. Гипервизор от VMware умеет использовать Hyper-threading.

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

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

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

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

Ещё одно важное замечание: при создании виртуальной машины всегда корректно выбирайте тип гостевой операционной системы и её версию. Гипервизор, зная особенности работы разных операционных систем, для создаваемой вами виртуальной машины применит оптимальные настройки и для процессора, выбирая поддерживаемые операционной системой механизмы  виртуализации. А это напрямую влияет на производительность. После создания виртуальной машины изменить эти настройки тоже можно. Выключив виртуальную машину, войдите в пункт меню "VM -> Settings" (или нажмите Ctrl+D), а там выберите раздел "General". Справа будут нужные вам параметры (рис. 1).

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

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

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

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

Память виртуальной машине (как и в любой операционной системе) выдаётся по требованию. При этом, как и в Enterprise решении VMware ESXi, гипервизор в VMware Workstation умеет выполнять разные финты при управлении памятью: page sharing, balooning, swapping. Все эти механизмы направлены прежде всего не на повышение производительности виртуальных машин, а на максимальную утилизацию ресурсов.  Задача механизмов оптимизации  уменьшить потребление памяти виртуальными машинами. Например, забрав свободные страницы памяти у виртуальной машины, как только они ей больше не нужны, и отдать их той виртуальной машине, которая в текущей момент требует больше памяти для своей работы. Стоит отметить, что благодаря такому подходу удаётся разместить на одной машине большее количество виртуальных машин. Гипервизор жонглирует количеством памяти меньшего объёма, чем сумма сконфигурированной памяти всех виртуальных машин, но при этом обеспечивает их одновременную работу. Существует даже термин для этого - "memory overcommitment".

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

Для этого необходимо, во-первых, перейти в пункт меню "Edit -> Preferences" (или нажать Ctrl+P). Здесь в разделе "Memory" содержатся общие настройки для всех виртуальных машин (рис. 2). Для начала укажите сколько оперативной памяти сервера может быть отдано виртуальным машинам. Так как VMware Workstation относится ко второму типу гипервизоров, то мы должны подумать и об основной машине, не оставив её без памяти. Иначе, если она начнёт уходить в swap, то работать плохо начнёт всё, включая виртуальные машины. В моём примере из 32 Гб оперативной памяти 24 Гб отдано виртуальным машинам, а 8 Гб всегда будут за операционной системой хоста.
Далее обязательно выбрать пункт "Fit all virtual machine memory into reserved host RAM". Гипервизор, работая в таком режиме, запускает виртуальные машины только при условии, если сумма сконфигурированной для них оперативной памяти умещается в выделенный для них пул основного хоста.

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

Во-вторых, для каждой виртуальной машины перейти в индивидуальные настройки через пункт меню "VM -> Settings" (или нажать Ctrl+D), перейти во вкладку "Options", а там выбрать пункт "Advanced" (рис. 3). В этом окне поставить галочку напротив пункта "Disable memory page trimming". В этом случае гипервизор не будет пытаться отнять у виртуальной машины оперативную память, используя свои механизмы оптимизации.

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

Жёсткий диск

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

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

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

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

Стоит отметить, что размещение файлов виртуальной машины на внешнем USB-носителе плохая идея. Практика показывает, что работает такая виртуальная машина очень медленно. Работать практически невозможно. Так что, если у вас возникла такая идея, лучше откажитесь от неё сразу. :)

Во-вторых, выбирайте правильные опции при создании жесткого диска виртуальной машины. VMware предлагает выбрать из следующих вариантов: 

• тонкий диск (thin provisioned) - место выделяется по мере необходимости,
• толстый диск (thick provisioned) - место выделяется сразу на весь объём виртуального диска,
• хранить виртуальный диск в одном файле,
• разбить виртуальный диск на несколько файлов.

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

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

В третьих, для максимальной производительности рекомендуется выбирать тип диска "Independent" и "Persistent". Запись на такой диск осуществляется сразу после команды ввода-вывода (рис. 7).

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

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

Существует рекомендация дефрагментировать диск внутри виртуальной машины, как и на обычном физическом компьютере. Но в наш век SSD лишние операции записи на SSD-диск не рекомендуются: снижается ресурс диска. Поэтому, наверное, этот совет уже не актуален. Но, если вы используете динамически расширяемый виртуальный диск (thin provisioned), то можно воспользоваться утилитой дефрагментации на уровне VMware Workstation (рис. 8). В данном случае VMware использует свои внутрение алгоритмы и с минимальным количеством операций записи оптимизирует виртуальный диск.

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

После дефрагментации, можно выполнить операцию сжатия файла, нажав соседнюю кнопку "Compact". VMware сожмёт образ диска до реального объёма данных. 

Дополнительно после полной подготовки виртуальной машины (установки операционной системы, программ и т.п.) можно перезалить файл-образ виртуального диска (vmdk-файл) на файловую систему, предварительно его удалив. На данном подходе я не настаиваю, может быть это и лишнее. Но мне кажется, что эта операция переложит файл образ одним непрерывным куском, что улучшит обращение к нему. Хотя опять же в век SSD это может быть уже не актуально. Но опции дефрагментации и сжатия есть, имейте это ввиду. Могут быть полезны перед перезаливкой образа-диска, если решитесь.

Дополнительно можно найти утилиты по подключению диска из виртуальной машины, как сетевого диска на основном компьютере (кнопка "Map") и увеличения размера диска (кнопка "Expand") (рис. 8). Имейте ввиду, что изменение настроек виртуального диска производится только при выключенной виртуальной машине.

Все согласятся, что в swap (paging) область уходить в виртуальной машине крайне не желательно. Но на случай использования swap области, рекомендуется вынести её на отдельный виртуальный диск, файл образ которого необходимо положить на отдельный физический диск. Опять же рекомендация со времен жестких дисков, а не SSD. А в swap лучше вообще никогда не уходить.

Внутри виртуальной машины для максимальной производительности диска можно включить кеширование записей. Например, в MS Windows одна опция включена по умолчанию, вторую можно активировать (рис. 9). Но следует иметь ввиду, что при внезапном отключении виртуальной машины, например, при сбое питания, при использовании кеша могут быть потери данных.

Рис. 9. Включение кэширования записей на диск в MS Windows.

Ну и последнее разумное правило: следить, чтобы диск, на котором размещены файлы виртуальных машин всегда имел запас по ёмкости. Если виртуальной машине вдруг не хватит места для записи логов, снепшотов или других временных файлов, то система начнёт тормозить или просто встанет.

Другое оборудование

Отключайте ненужное оборудование. Например, если у вас в виртуальной среде работает серверная операционная система, то звуковая карта вам вряд ли понадобится. Для отключения выберите пункт меню "VM -> Settings" (или нажмите Ctrl+D), слева выберите пункт "Sound Card", а справа уберите галочки напротив пунктов "Connected" и "Connected at power on". Или удалите целиком виртуальное устройство через кнопку "Remove" (рис. 10).

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

Также настоятельно рекомендуется отключать автозапуск для CD/DVD-устройств. Если вы устанавливали гостевую операционную систему через ISO-файл, то он будет постоянно контролироваться и читаться виртуальной машиной. А этот образ вам скорее всего уже не нужен. Поэтому для отключения в тех же настройках виртуальной машины установите курсор мыши на пункт с CD/DVD и уберите галочки напротив пунктов "Connected" и "Connected at power on" (рис. 11).

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

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

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

Программное обеспечение

Во-первых, обязательно устанавливайте пакет расширений VMware Tools. Данный пакет представляет собой набор драйверов для виртуального оборудования плюс ряд программных механизмов, которые напрямую влияют на производительность виртуальной машины. Помимо этого после установки VMware Tools можно будет настроить нормальное разрешение экрана, интеграцию мыши и выполнять копирование через буфер обмена между основной и виртуальной машинами. Для установки выберете пункт меню "VM -> Install VMware Tools". Для гостевой операционной системы Linux поддерживаемой альтернативой является пакет Open VM Tools. Подробности можно найти тут и тут.

Во-вторых, рекомендуется на основной машине отключить антивирус на директории с файлами виртуальных машин. Дополнительно можно включить основные типы файлов виртуальных машин (*.vmdk, *.vmx, *.vmem, *.nvram) в исключения антивируса. При работе виртуальной машины эти файлы часто меняются, так как виртуальная машина постоянно читает и пишет в них. Антивирус может вызывать излишнюю нагрузку на систему, постоянно проверяя эти файлы (особенно большие файлы образов виртуальных дисков). Тем самым будет оказываться влияние на производительность и виртуальных машин.

Другое

Во-первых, встречал рекомендацию работать в виртуальной машине в полноэкранном режиме (Full-screen). То есть когда вы находитесь в виртуальной машине в окне VMware Management Interface, то лучше работать не в оконном режиме. Иначе производительность работы интерфейса операционной системы внутри виртуальной машины будет не максимальной. Для перехода в полноэкранный режим необходимо нажать комбинацию клавиш Ctrl+Alt+Enter. Выйти можно через комбинацию клавиш Ctrl+Alt или вызвав сверху панель VMware Management Interface и свернув окно виртуальной машины.

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

Во-вторых, если ваша виртуальная машина работает без ошибок и сбоев, то для максимальной производительности можно полностью выключить Debbuging. Для этого необходимо перейти в настройки виртуальной машины через пункт меню "VM -> Settings" (или нажать Ctrl+D), открыть вкладку "Options", а там выбрать пункт "Advanced". Справа для пункта "Gather debugging information" выбрать уровень "None" (рис. 13).

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

В виртуальных машинах с операционной системой MS Windows рекомендуется по максимум отключить визуальные эффекты. Обычно эти настройки можно найти в "Панель управления -> Система и безопасность -> Система -> Дополнительные параметры системы -> Быстродействие -> Параметры". Я на всех своих рабочих местах выбираю "Обеспечить наилучшее быстродействие", включая только некоторые настройки визуализации (рис. 14).

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

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

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

В третьих, рекомендуется в гостевых операционных системах включать синхронизацию времени. Лучше всего для этого использовать NTP-сервер. Нет локального? Всегда можно использовать свободные для доступа из Интернет. В крайнем случае, можно использовать встроенную функцию синхронизации из VMware Tools. Но следите, чтобы не были активированы оба механизма.

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

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

На официальном сайте VMware можно найти документ "Performance Best Practices for VMware Workstation". К сожалению, самый свежий вариант написан для версии 7.0. Но судя по содержанию, большая часть информации актуальна и для текущих версий программы. Скачать/прочитать документ можно по этой ссылке. 

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

Автор: Шиболов Вячеслав Анатольевич