Vswp vmware что это

Обновлено: 02.07.2024

Начнём с того, что есть два типа свапинга, которые могут происходить на ESXi хосте. Их очень часто путают, поэтому давайте условно будем называть их Тип 1 и Тип 2.

Расположение данных VMware ESXi по умолчанию

Тип 1. VMX swapping (vSwap)

Это самый простой тип свапинга для описания. Память выделяется не только для виртуальных машин, а также и для различных компонент хоста, к примеру, для монитора виртуальных машин (VMM) и виртуальных устройств. Такая память может быть свапирована для того, чтобы выделить более нуждающимся виртуальным машинам больше физической памяти. По словам VMware эта возможность может высвободить от 50MB до 10MB памяти, для каждой виртуальной машины без существенного ухудшения производительности.

Тип 2. Guest OS Swapping

ESXi Host swapping

vSwap (Тип 1) по умолчанию сохраняется в .vswp файл в папке с виртуальной машиной. NetApp рекомендует сохранять vSwap (Тип 1) на выделенный датастор.

Такой файл существует только для запущенных виртуальных машин – при запуске гипервизор создаёт этот файл и удаляет при выключении виртуальной машины. Обратите внимание на размер этого файла — он равен разнице между сконфигурированной памятью для виртуальной машины и резервом физической памяти за этой машиной. Таким образом обеспечивается наличие заданного пространства памяти, когда виртуальная машина стартует (не зависимо от того, какая память используется — настоящая физическая или vSwap). Резерв заботится о том, чтобы виртуальная машина получила нужное пространство всегда в физической памяти хоста. А разница между резервом и настроенной памятью виртуальной машины сохраняется в vswp файл.

Ниже пример запуска виртуальной машины с 4GB памяти и резервом 2GB. Помните, что vSwap удаляется после выключения? А если в этот момент датастор хранящий эту виртуальную машину заполнится и останется свободного 1.8GB пространства, что произойдёт?

Что можно с этим сделать? Конечно же можно высвободить пространство на датасторе или расположить vSwap (Тип 1) на другом датасторе. По умолчанию он хранится в папке с виртуальной пашиной. Если это «standalone» хост: Configuration > Software > Virtual Machine Swapfile Location. Расположение vSwap файлов также можно изменить на уровне настроек каждой виртуальной машины. Откройте настройки виртуальной машины и выберите вкладку Options:

Если этот хост часть кластера, загляните в настройки кластера Store the swapfile in the datastore specified by the host

Далее выберите датастор где будет храниться vSwap (Тип 1).

Зачем располагать свап на отдельный датастор?

Рекомендуемая схема расположения Swap'а для NetApp FAS

Во-первых стоит отметить что общее правило VMware гласит по возможности располагать vSwap (Тип 1) в папке с виртуальной машиной, так как вынесение на отдельный датастор может замедлить vMotion. Но в частном случае VMware + NetApp FAS вступает другая рекомендация. NetApp рекомендует хранить vSwap (Тип 1) на отдельном выделенном, одном для всех виртуальных машин датасторе, так как в этом случае разница при миграции vMotion практически нивелирована. VMware рекомендует, чтобы пространство под vSwap (Тип 1) было больше или равно разнице сконфигурированной и зарезервированной для виртуальной машины памяти. Иначе виртуальные машины могут не стартовать. Пример: у нас есть 5 виртуальных машин с размером памяти 4GB и резервацией для каждой 3GB.

Минимальный размер датастора для vSwap Тип 1:
5VM * (4 GB — 3GB )= 5GB

Если на хосте нет свободных физических 5VM * 3GB = 15 GB памяти, машины могут не стартовать, выводя ошибку:
The host does not have sufficient memory resources to satisfy the reservation

И в то же время будет создан Event log

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

В-третьих это снепшоты и дедубликация на уровне хранилища. Так как у нетапа снепшоты не влияют на производительность, они являются нормой жизни, выполняются постоянно и являются частью парадигмы резервного копирования NetApp для систем FAS. Свап это абсолютно бесполезная информация при резервном копировании и восстановлении. Если он интенсивно используется, а снепшоты часто снимаются, в снепшотах будет «захвачена» и храниться, все время жизни снепшота, эта бесполезная информация. А так как свап постоянно меняется, а спепшот захватывает только новые изменённые данные, в каждом таком снепшоте будет храниться эти новые изменённые данные из свапа, беспощадно поедая полезное пространство под бесполезные данные на хранилище. Дедублицировать свап нет никакого резона, ведь данные в свапе не нужны при восстановлении и никогда не будут считаны. В этом смысле удобно выносить свапы на отдельный датастор. NetApp рекомендует располагать свап на отдельный датастор с выключенными снепшотами и дедубликацией, так мы можем ещё сильнее уменьшить оверхед в снепшотах и на репликации.

NetApp не рекомендует использовать локальные диски (стр 76-78, DEC11) на хосте, для хранения vSwap (Тип 1) потому, что такая конфигурация имеет негативное влияние на скорость выполнения операции vMotion.

Стоит ли выносить Тип 2 Swap?

Размещение временных данных, таких как Swap и Pagefile.sys на выделенный датастор (создав выделенный виртуальный диск для этой цели) позволяет не дедублицировать и не бэкапировать эти данные также как и vSwap (Тип 1). Очень важно не забыть указать этот диск как Independent, чтобы агент VSC не заставлял FAS снимать снепшоты с раздела хранящего Swap файлы (Тип 2).

У NetApp нет рекомендаций относительно Swap Тип 2, вынесение этих данных является опциональным дизайном, у которого есть свои плюсы и минусы:

В дополнение к вынесенному vSwap Тип 1, вынесение Swap Тип 2 ещё сильнее уменьшит оверхед на снепшотах, и как следствие увеличит пропускную способность для репликации. В ACB для DR решений наличие Swap'а (оба типа) не нисет никакой смысловой нагрузки, ведь он не используется при старте системы. Если мы перестанем хранить Swap (Тип 2) в снепшотах и резервных копиях, при локальном восстановлении это не должно вызывать каких-либо проблем, так как восстанавливаемый .vmx config файл будет содержать ссылку на VMDK файл хранящий раздел со Swap'ом, ведь тот будет находиться на том же месте. Но это добавит дополнительные шаги при восстановлении на удалённой площадке, в таких конфигурациях как SRM , SnapProtect и других DR решений.

Опциональная схема расположения данных на NetApp FAS

Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.

VMware Technology Network
:
Global
:
Russian
:
Russian Discussions
:
Большой размер файла vswp. Как уменьшить?

alokey

Mark as New
Bookmark
Subscribe
Mute
Email to a Friend

Очень сильно вырос объем файла подкачки vswp, как уменьшить? И что за виртуальные диски создались sql-000001.vmdk и sql-000002.vmdk?

Подскажите, что делать с этим? Объем свободного пространства на исходе.

VTsukanov

Mark as New
Bookmark
Subscribe
Mute
Email to a Friend

> Очень сильно вырос объем файла подкачки vswp, как уменьшить?

Разбираться с количеством памяти на хосте и в виртуалке, в частности посмотрите в документации на reservation memory и на влияние ее на vswp size

> И что за виртуальные диски создались sql-000001.vmdk и sql-000002.vmdk?

Похоже на снапшоты. Что говорит snapshot manager?

А вообще если это MS SQL оставлять его без выставленного ограничния памяти в настройках не правильно. Память ему идет в прок только до каких то разумных пределов

urbas

Mark as New
Bookmark
Subscribe
Mute
Email to a Friend

объём vswp - объем оперативной памяти, сконфигурированный для ВМ минус колличество зарезервированной памяти для этой ВМ. То есть, уменьшить vswp можно путем увеличения резервации памяти для ВМ, но надо учитывать, что зарезервированная память уже не будет доступна другим ВМ и повлияет на работу HA. Так же можно лучше вынести файл vswp в другое место.

sql-000001.vmdk и sql-000002.vmdk - это снапшоты и, судя по размеру, сделанные давно и вряд-ли пригодятся. Их просто удалить через Snapshot Manager, с местом сразу по-проще станет

alokey

Mark as New
Bookmark
Subscribe
Mute
Email to a Friend

а можно не через Snapshot Manager , а вручную эти файлы удалить??

VTsukanov

Mark as New
Bookmark
Subscribe
Mute
Email to a Friend

А что мешает посмотерть snapshot manager?

alokey

Mark as New
Bookmark
Subscribe
Mute
Email to a Friend

удалил один снапшот в менеджере а в datastore browser ни один не исчез.. Сегодня даже еще один создался sql-000003.vmdk. Он уже весит 3 ГБ.

EGarbuzov

Mark as New
Bookmark
Subscribe
Mute
Email to a Friend

Можете дать скриншот текущего состояния окна snapshot manager по этой машине, если там что-то есть?

Что у вас с резервным копированием данной ВМ?

GSergey

Mark as New
Bookmark
Subscribe
Mute
Email to a Friend

Sladky

Mark as New
Bookmark
Subscribe
Mute
Email to a Friend

Бэкапные снапшоты обычно кривые названия имеют. А эти похожи на ручные.

alokey

Mark as New
Bookmark
Subscribe
Mute
Email to a Friend

Быкапы делаю при помощи veeamzip.

VTsukanov

Mark as New
Bookmark
Subscribe
Mute
Email to a Friend

Такое (лишние снапшот файлы) бывает, наиболее правильно сделать Delete All из Snapshot Manager и начинать жить с чистого листа

Альтернатива (не рекомендованная) : через консоль пройтись по vmdk файлам описаниям, найти лишние снапшот файлы.

Текущие используемые можно посмотреть так

ls -l /vmfs/devices/deltadisks

alokey

Mark as New
Bookmark
Subscribe
Mute
Email to a Friend

после delete all все vmdk файлы исчезли. Сейчас на диске свободного места достаточно.
Будет ли дальше расти vswp файл? Где выставить настройки резервации памяти?

Если здесь, то какие значения выставлять?

VTsukanov

Mark as New
Bookmark
Subscribe
Mute
Email to a Friend

> Будет ли дальше расти vswp файл?

Зависит от значений Reservation & от того насколько глубоко в swap будет лезть VM. Еще раз напомню, что имеет смысл ограничить использование памяти в самом SQL, если это MSSQL и у него в качестве Maximum server memory (in MB) стоит 2147483647 то рано или поздно SQL начнет использовать swap а hypervisor растить файл vswp. Поэтому если вы хотите макимально уменьшить размер файла vswp нужно выставить в reservation то количество памяти которое вы отдали VM и установить некое разумное значение для Maximum server memory

Сложность только в одном, для всех остальных виртуалок на хосте ESXi количество доступной памяти окажется равным (Общая память хоста - Reservation), вам нужно будет проконтролировать чтобы памяти хватило

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

В этой статье поговорим про счетчики производительности оперативной памяти (RAM) в vSphere.

Немного теории

Оперативная память виртуальных машин берется из памяти сервера, на которых работают ВМ. Это вполне очевидно:). Если оперативной памяти сервера не хватает для всех желающих, ESXi начинает применять техники оптимизации потребления оперативной памяти (memory reclamation techniques). В противном случае операционные системы ВМ падали бы с ошибками доступа к ОЗУ. Какие техники применять ESXi решает в зависимости от загруженности оперативной памяти:

Состояние памяти	Граница	Действия
High	400% от minFree	После достижения верхней границы, большие страницы памяти разбиваются на маленькие (TPS работает в стандартном режиме).
Clear	100% от minFree	Большие страницы памяти разбиваются на маленькие, TPS работает принудительно.
Soft	64% от minFree	TPS + Balloon
Hard	32% от minFree	TPS + Compress + Swap
Low	16% от minFree	Compress + Swap + Block

minFree — это оперативная память, необходимая для работы гипервизора.

До ESXi 4.1 включительно minFree по умолчанию было фиксированным — 6% от объема оперативной памяти сервера (процент можно было поменять через опцию Mem.MinFreePct на ESXi). В более поздних версиях из-за роста объемов памяти на серверах minFree стало рассчитываться исходя из объема памяти хоста, а не как фиксированное процентное значение. Значение minFree (по умолчанию) считается следующим образом:

Процент памяти, резервируемый для minFree	Диапазон памяти
6%	0-4 Гбайт
4%	4-12 Гбайт
2%	12-28 Гбайт
1%	Оставшаяся память

Например, для сервера со 128 Гбайт RAM значение MinFree будет таким:
MinFree = 245,76 + 327,68 + 327,68 + 1024 = 1925,12 Мбайт = 1,88 Гбайт

Фактическое значение может отличаться на пару сотен МБайт, это зависит от сервера и оперативной памяти.

Процент памяти, резервируемый для minFree	Диапазон памяти	Значение для 128 Гбайт
6%	0-4 Гбайт	245,76 Мбайт
4%	4-12 Гбайт	327,68 Мбайт
2%	12-28 Гбайт	327,68 Мбайт
1%	Оставшаяся память (100 Гбайт)	1024 Мбайт

Обычно для продуктивных стендов нормальным можно считать только состояние High. Для стендов для тестирования и разработки приемлемыми могут быть состояния Clear/Soft. Если оперативной памяти на хосте осталось менее 64% MinFree, то у ВМ, работающих на нем, точно наблюдаются проблемы с производительностью.

В каждом состоянии применяются определенные memory reclamation techniques начиная с TPS, практически не влияющего на производительность ВМ, заканчивая Swapping’ом. Расскажу про них подробнее.

Transparent Page Sharing (TPS). TPS — это, грубо говоря, дедупликация страниц оперативной памяти виртуальных машин на сервере.

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

Источник

По умолчанию ESXi выделяет память большим страницам. Разбивание больших страниц на маленькие начинается при достижении порога состояния High и происходит принудительно, когда достигается состояние Clear (см. таблицу состояний гипервизора).

Если же вы хотите, чтобы TPS начинал работу, не дожидаясь заполнения оперативной памяти хоста, в Advanced Options ESXi нужно установить значение “Mem.AllocGuestLargePage” в 0 (по умолчанию 1). Тогда выделение больших страниц памяти для виртуальных машин будет отключено.

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

Политика TPS контролируется через advanced option “Mem.ShareForceSalting” на ESXi:

0 — Inter-VM TPS. TPS работает для страниц разных ВМ;

1 – TPS для ВМ с одинаковым значением “sched.mem.pshare.salt” в VMX;

2 (по умолчанию) – Intra-VM TPS. TPS работает для страниц внутри ВМ.

Однозначно имеет смысл выключать большие страницы и включать Inter-VM TPS на тестовых стендах. Также это можно использовать для стендов с большим количеством однотипных ВМ. Например, на стендах с VDI экономия физической памяти может достигать десятков процентов.

Memory Ballooning. Ballooning уже не такая безобидная и прозрачная для операционной системы ВМ техника, как TPS. Но при грамотном применении с Ballooning’ом можно жить и даже работать.

Вместе с Vmware Tools на ВМ устанавливается специальный драйвер, называемый Balloon Driver (он же vmmemctl). Когда гипервизору начинает не хватать физической памяти и он переходит в состояние Soft, ESXi просит ВМ вернуть неиспользуемую оперативную память через этот Balloon Driver. Драйвер в свою очередь работает на уровне операционной системы и запрашивает свободную память у нее. Гипервизор видит, какие страницы физической памяти занял Balloon Driver, забирает память у виртуальной машины и возвращает хосту. Проблем с работой ОС не возникает, так как на уровне ОС память занята Balloon Driver’ом. По умолчанию Balloon Driver может забрать до 65% памяти ВМ.

Если на ВМ не установлены VMware Tools или отключен Ballooning (не рекомендую, но есть KB:), гипервизор сразу переходит к более жестким техникам отъема памяти. Вывод: следите, чтобы VMware Tools на ВМ были.

Работу Balloon Driver’а можно проверить из ОС через VMware Tools

Memory Compression. Данная техника применяется, когда ESXi доходит до состояния Hard. Как следует из названия, ESXi пытается сжать 4 Кбайт страницы оперативной памяти до 2 Кбайт и таким образом освободить немного места в физической памяти сервера. Данная техника значительно увеличивает время доступа к содержимому страниц оперативной памяти ВМ, так как страницу надо предварительно разжать. Иногда не все страницы удается сжать и сам процесс занимает некоторое время. Поэтому данная техника на практике не очень эффективна.

Memory Swapping. После недолгой фазы Memory Compression ESXi практически неизбежно (если ВМ не уехали на другие хосты или не выключились) переходит к Swapping’у. А если памяти осталось совсем мало (состояние Low), то гипервизор также перестает выделять ВМ страницы памяти, что может вызвать проблемы в гостевых ОС ВМ.

Вот как работает Swapping. При включении виртуальной машины для нее создается файл с расширением .vswp. По размеру он равен незарезервированной оперативной памяти ВМ: это разница между сконфигурированной и зарезервированной памятью. При работе Swapping’а ESXi выгружает страницы памяти виртуальной машины в этот файл и начинает работать с ним вместо физической памяти сервера. Разумеется, такая такая “оперативная” память на несколько порядков медленнее настоящей, даже если .vswp лежит на быстром хранилище.

В отличие от Ballooning’а, когда у ВМ отбираются неиспользуемые страницы, при Swapping’e на диск могут переехать страницы, которые активно используются ОС или приложениями внутри ВМ. В результате производительность ВМ падает вплоть до подвисания. ВМ формально работает и ее как минимум можно правильно отключить из ОС. Если вы будете терпеливы ;)

Если ВМ ушли в Swap — это нештатная ситуация, которую по возможности лучше не допускать.

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

Вот мы и добрались до главного. Для мониторинга состояния памяти в ВМ есть следующие счетчики:

Active — показывает объем оперативной памяти (Кбайт), к которому ВМ получила доступ в предыдущий период измерения.

Usage — то же, что Active, но в процентах от сконфигурированной оперативной памяти ВМ. Рассчитывается по следующей формуле: active ÷ virtual machine configured memory size.

Высокий Usage и Active, соответственно, не всегда является показателем проблем производительности ВМ. Если ВМ агрессивно использует память (как минимум, получает к ней доступ), это не значит, что памяти не хватает. Скорее это повод посмотреть, что происходит в ОС.

Есть стандартный Alarm по Memory Usage для ВМ:

Shared — объем оперативной памяти ВМ, дедуплицированной с помощью TPS (внутри ВМ или между ВМ).

Granted — объем физической памяти хоста (Кбайт), который был отдан ВМ. Включает Shared.

Consumed (Granted — Shared) — объем физической памяти (Кбайт), которую ВМ потребляет с хоста. Не включает Shared.

Если часть памяти ВМ отдается не из физической памяти хоста, а из swap-файла или память отобрана у ВМ через Balloon Driver, данный объем не учитывается в Granted и Consumed.

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

Zero — объем оперативной памяти ВМ (Кбайт), который содержит нули. Такая память считается гипервизором свободной и может быть отдана другим виртуальным машинам. После того, как гостевая ОС получила записала что-либо в зануленную память, она переходит в Consumed и обратно уже не возвращается.

Reserved Overhead — объем оперативной памяти ВМ, (Кбайт) зарезервированный гипервизором для работы ВМ. Это небольшой объем, но он обязательно должен быть в наличии на хосте, иначе ВМ не запустится.

Balloon — объем оперативной памяти (Кбайт), изъятой у ВМ с помощью Balloon Driver.

Compressed — объем оперативной памяти (Кбайт), которую удалось сжать.

Swapped — объем оперативной памяти (Кбайт), которая за неимением физической памяти на сервере переехала на диск.

Balloon и остальные счетчики memory reclamation techniques равны нулю.

Вот так выглядит график со счетчиками Memory нормально работающей ВМ со 150 ГБ оперативной памяти.

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

ESXTOP

Как и с CPU, если хотим оперативно оценить ситуацию на хосте, а также ее динамику с интервалом до 2 секунд, стоит воспользоваться ESXTOP.

Экран ESXTOP по Memory вызывается клавишей «m» и выглядит следующим образом (выбраны поля B,D,H,J,K,L,O):

Интересными для нас будут следующие параметры:

Mem overcommit avg — среднее значение переподписки по памяти на хосте за 1, 5 и 15 минут. Если выше нуля, то это повод посмотреть, что происходит, но не всегда показатель наличия проблем.

В строках PMEM/MB и VMKMEM/MB — информация о физической памяти сервера и памяти доступной VMkernel. Из интересного здесь можно увидеть значение minfree (в МБайт), состояние хоста по памяти (в нашем случае, high).

В строке NUMA/MB можно увидеть распределение оперативной памяти по NUMA-нодам (сокетам). В данном примере распределение неравномерное, что в принципе не очень хорошо.

Далее идет общая статистика по серверу по memory reclamation techniques:

PSHARE/MB — это статистика TPS;

SWAP/MB — статистика использования Swap;

ZIP/MB — статистика компрессии страниц памяти;

MEMCTL/MB — статистика использования Balloon Driver.

По отдельным ВМ нас может заинтересовать следующая информация. Имена ВМ я скрыл, чтобы не смущать аудиторию:). Если метрика ESXTOP аналогична счетчику в vSphere, привожу соответствующий счетчик.

MEMSZ — объем памяти, сконфигурированный на ВМ (МБ).

MEMSZ = GRANT + MCTLSZ + SWCUR + untouched.

GRANT — Granted в МБайт.

TCHD — Active в МБайт.

MCTL? — установлен ли на ВМ Balloon Driver.

MCTLSZ — Balloon в МБайт.

MCTLGT — объем оперативной памяти (МБайт), который ESXi хочет изъять у ВМ через Balloon Driver (Memctl Target).

MCTLMAX — максимальный объем оперативной памяти (МБайт), который ESXi может изъять у ВМ через Balloon Driver.

SWCUR — текущий объем оперативной памяти (МБайт), отданный ВМ из Swap-файла.

SWGT — объем оперативной памяти (МБайт), который ESXi хочет отдавать ВМ из Swap-файла (Swap Target).

Также через ESXTOP можно посмотреть более подробную информацию про NUMA-топологию ВМ. Для этого нужно выбрать поля D,G:

NHN – NUMA узлы, на которых расположена ВМ. Здесь можно сразу заметить wide vm, которые не помещаются на один NUMA узел.

NRMEM – сколько мегабайт памяти ВМ берет с удаленного NUMA узла.

NLMEM – сколько мегабайт памяти ВМ берет с локального NUMA узла.

N%L – процент памяти ВМ на локальном NUMA узле (если меньше 80% — могут возникнуть проблемы с производительностью).

Memory на гипервизоре

Если счетчики CPU по гипервизору обычно не представляют особого интереса, то с памятью ситуация обратная. Высокий Memory Usage на ВМ не всегда говорит о наличие проблемы с производительностью, а вот высокий Memory Usage на гипервизоре, как раз запускает работу техник управления памятью и вызывает проблемы с производительностью ВМ. За алармами Host Memory Usage надо следить и не допускать попадания ВМ в Swap.

Unswap

Если ВМ попала в Swap, ее производительность сильно снижается. Следы Ballooning’а и компрессии быстро исчезают после появления свободной оперативной памяти на хосте, а вот возвращаться из Swap в оперативную память сервера виртуальная машина совсем не торопится.

До версии ESXi 6.0 единственным надежным и быстрым способ вывода ВМ из Swap была перезагрузка (если точнее выключение/включение контейнера). Начиная с ESXi 6.0 появился хотя и не совсем официальный, но рабочий и надежный способ вывести ВМ из Swap. На одной из конференций мне удалось пообщаться с одним из инженеров VMware, отвечающим за CPU Scheduler. Он подтвердил, что способ вполне рабочий и безопасный. В нашем опыте проблем с ним также замечено не было.

Собственно команды для вывода ВМ из Swap описал Duncan Epping. Не буду повторять подробное описание, просто приведу пример ее использования. Как видно на скриншоте, через некоторое время после выполнения указанной команд Swap на ВМ исчезает.

Советы по управлению оперативной памятью на ESXi

Напоследок приведу несколько советов, которые помогут вам избежать проблем с производительностью ВМ из-за оперативной памяти:

На этом про оперативную память у меня все. Ниже статьи по теме для тех, кто хочет углубиться в детали. В следующей статье будет посвящена стораджу.

Для создания новой виртуальной машины в гипервизоре VMware ESXi версии 5.1 a необходимо подключиться через vSphere Client к серверу, на котором установлен ESXi. Выбрать в левом поле сервер, к которому вы подключены и кликнуть по нему правой кнопкой мыши. В выпадающем меню выбрать пункт New Virtula Machine.

На этом шаге задаем имя виртуальной машины, как мы ее здесь назовем она и будет отображаться в vSphere Client, а в дальнейшем и в vCenter Server.

Задаем месторасположение файлов виртуальной машины. В данном случае мне доступны только локальные диски сервера он обозначается в VMware ESXi, как datastore1. Его скромные характеристики мы тоже видим на картинке. Если бы у нас были подключены дополнительные LUN-ы с систем храния данных или другие локальные RAID array, то выбор был бы богаче.

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

А вот какие операционные системы семейства Linux могут быть официально запущены в виртуальной среде платформы VMware. Также не должно скрыться от внимания то, что есть пунк Other 2.6.x Linux , это значит если вашего линукса нет в списке, но вы точно знаете, что он работает на соответствующей версии ядра, то его тоже можно установить и работать.

Во вкладке Other, видим список поддерживаемых ОС других семейств. VMware vSphere поддерживает такие операционные системы, как Apple MAC OS X, FreeBSD, IBM OS/2, NetWare, Solaris и др.

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

Выделение оперативной памяти для виртуальной машины, необходимо установить оптимальное значение. Если памяти будет выделено мало, то начнется swap памяти на диск, что приведет к резкому снижению работоспособности всех виртуальных машин на хосте или LUN-е.

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

Создаем жесткий диск. Это может быть новый HDD, это может быть существующий HDD диск, это может быть RDM диск, который напрямую подключается с системы хранения.

Выбираем к какому адаптеру будет подключен диск, по умолчанию это IDE. Также можно настроить режим работы "быстрый" или "безопасный"

Добрались до кнопки Finish. Просматриваем, все, что выбрали и жмем на нее. Любые настройки, можно будет изменить позднее, возможно для этого потребуется выключить виртуальную машину.

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

.vmx – текстовый конфигурационный файл, содержит информацию настройках ВМ, а именно, объем оперативной памяти, количество и конфигурация сетевых адаптеров, информация о жестких дисках, параллельных портах, настройки включения/выключения.
.vswp – файл подкачки, создается вместе с виртуальной машиной, но начинает использоваться только в том случае, когда оперативная память ВМ заканчивается.
.nvram – BIOS файл, хранит конфигурацию биоса виртуальной машины.
.log – лог файл, используется администраторами для решения сложных проблем, поиска неисправностей, о которых обычные средства мониторинга не сообщают
.vmdk – текстовый файл дескриптор, несет информацию о геометрии и размере виртуального жесткого диска
.flat-vmdk – файл виртуального жесткого диска
-delta.vmdk – файл мгновенного снимка (snapshot)
-rdm.vmdk – файл создается, когда ВМ использует raw device, т.е. напрямую использует LUN

Читайте также: