Vmware отключить обрезку страничной памяти

Обновлено: 08.01.2025

У меня возникла проблема с VMware Fusion в течение некоторого времени, когда виртуальная машина (под управлением Windows) вначале работает нормально, но через некоторое время замедлится до излома (лучшее предположение - пару часов). Это так медленно, что даже при наборе текста происходит задержка.

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

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

Изменения (оптимизации), выполненные до настоящего времени

Обновить:

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

Исключите VMware из функции AppNap в OSX, выполнив следующие шаги:

Обновление 2:

В дополнение к вышеуказанному действию служба поддержки VMware попросила меня сделать следующее:

Хотя я не ожидал, что эти изменения будут иметь какое-либо значение (особенно при уменьшении ресурсов, выделенных для гостевой ОС), виртуальные машины, которые я пробовал до сих пор, все работали стабильно и без каких-либо реальных сбоев, даже при запуске от внешнего USB3 WD диск.

3 ответа 3

Твик: Отключить файлы подкачки памяти .vmem файлы

Твик: Выберите правильный контроллер диска и укажите SSD

Вместо новейшего контроллера SATA AHCI выберите контроллер LSI Logic SAS с диском SCSI для гостевой ОС Windows или PVSCSI для других типов ОС. К сожалению, SATA AHCI в VMware имеет наименьшую производительность из трех контроллеров и самые высокие издержки процессора (см. Ссылки в конце темы). В дополнение к выбору правильного контроллера, если ваш хост-диск является SSD, вы можете явно указать тип диска как SSD для гостевой ОС.

Твик: отключение лог файлов для ВМ

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

Твик: Оптимизация производительности ввода-вывода для других дисков и памяти

Отключить обрезку памяти:

Отключить общий доступ к странице:

Отключить уменьшение выделения памяти:

Твик: отключение снимков

Отключите снимки, если вы не используете их и предпочитаете полные резервные копии:

Твик: отключить режим единства

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

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

У меня были похожие проблемы с моей установкой под управлением OS X 10.10.2 и до того, как я обновил OS X до.

Это одинаковое поведение для Windows 7 Pro и Windows 8.1 Ent

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

Не знаю, поможет ли это вам дома, но, возможно, ваша проблема связана с экраном.

Memory management

В полете из солнечной Москвы в прохладный Баку
у меня появилось вдохновение для написания сего текста.
Лично мне он понравился.

Несколько общих слов

Memory Overcomitment

Memory Overcomitment достигается на ESX(i) за счет нескольких технологий. Перечислим их:

• выделение по запросу;
• transparent memory page sharing:
• balloon driver или его еще можно обозвать vmmemctl;
• memory compression (новинка 4.1);
• vmkernel swap.

Что это? Каково место этих технологий? Насколько они офигенны? Насколько они бесполезны? Давайте поразмышляем.

Вводная к размышлениям

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

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

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

Выделение по запросу

Насколько часто это применяется к разным группам виртуальных машин

transparent memory page sharing

Насколько часто это применяется к разным группам виртуальных машин

Сложный вопрос. Сложность во все более широко используемом механизме Large Pages. Если у вас Windows 7/2008 + Nehalem, и используются страницы памяти по 2 МБ, теория гласит что эффект от page sharing будет маленьким. Хотя в реальности там довольно сложный алгоритм:

Именно производительность негативного эффекта не испытывает. Тем более что ESX(i) знает, что такое архитектура NUMA, и если сервер у нас этой архитектуры, то дедупликация страниц памяти идет внутри каждого одного NUMA узла независимо, чтобы виртуалке не приходилось за отдельными, дедуплицированными страницами лазать в память другого процессора.

UPD. от июня 2011 - отключение Large Pages позволяет сэкономить треть ОЗУ, есть такое мнение - TPS vs. Large Pages in real life.

balloon driver / vmmemctl

Насколько часто это применяется к разным группам виртуальных машин

Итак, из чего может взяться ситуация, когда у одной ВМ память надо отнять, чтобы отдать другой? Я вижу несколько вариантов:

1. когда у нас memory overcommitment. и сразу у многих ВМ наступили пики нагрузки, что привело к загрузке сервера на 100%. Это, кстати говоря, причина пользоваться MO аккуратно. Впрочем, совсем отказываться от MO, как призывает нас делать Майкрософт, по моему мнению, тоже не стоит.
2. когда у нас ломается один из серверов кластера HA. Например, у нас 10 серверов, все загружены по памяти(днем, в будни) процентов на 70. Вы знаете, что HA все упавшие ВМ перезапустит на одномиз оставшихся серверов? Т.е. виртуалкам потребуется 140% его памяти.

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

Memory Sizing

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

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

Нужно понимать, что чем больше памяти выделено машине – тем больше накладные расходы гипервиозра на обслуживание данной памяти (overhead). Даже если гипервизор сможет высвободить часть ресурсов из виртуальной машины, уменьшить оверхед уже не получится.

Memory Overcommit Techniques

ESXi использует 5 техник для оптимизации количества потребляемой ОЗУ, в случаях, если ее становится крайне мало.

Page Sharing – в случае, если участки памяти двух виртуальных машин одинаковы, нет смысла держать два одинаковых участка и занимать двойное пространство ОЗУ, когда можно просто сослать обе машины на один участок памяти, а второй высвободить. До версии 6.0 Page Sharing работал между виртуальными машинами в рамках одного хоста, однако, с 6-й версии, по умолчанию данный метод применяется только внутри виртуальных машин в целях безопасности.

Ballooning – Модуль, который устанавливается в гостевую операционную систему вместе с пакетом VMware Tools, который может «подтолкнуть» гостевую ОС к высвобождению наименее важных страниц памяти.

Memory Compression – Тут все понятно из описания. Сжатие страниц памяти на хосте. Это, конечно, снижает скорость доступа к памяти, но все еще быстрее, чем использование swap файлов.

Swap to Host Cache – Включается своппинг на уровне хоста. Но в данном случае в кэш, если он, конечно, сконфигурирован. Swap to Host Cache позволяет выделить пространство на SSD, доступ к которому будет все еще быстрее, чем доступ к swap на обычном жестком диске.

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

Если имеется подозрение, что вышеуказанные техники начинают применяться к VM и это сказывается на ее производительности, следует проверить следующее:

1. Проверить значения параметра Ballooning у виртуальной машины в меню Monitor – Performance – Advanced в разделе Memory. Нулевое значение данного параметра обычно говорит о том, что у хоста не наблюдается проблем с переподпиской (overcommitment) и ресурсов достаточно для облуживания виртуальной машины. Стоит помнить, что данный параметр имеется только у виртуальных машин с установленным Balloon Driver, который входит в пакет VMware Tools. Небольшое количество balloon memory не всегда говорит о наличии каких-либо проблем;
2. Проверить раздел Utilization виртуальной машины. Отличные от нуля значения Swapped и Compressed могут говорить о нехватке памяти гипервизора. Обращение к данным участкам памяти будет замедленно, что скажется на производительности виртуальной машины;
3. Стоит проверить активность использования файла подкачки в виртуальной машине. Это может говорить либо об активной процедуре балунинга, либо о недостаточном количестве памяти, выделенной виртуальной машине.

Memory Page Sharing

Как уже было сказано ранее, начиная с версии 6.0, Page sharing работает по умолчанию только в рамках виртуальной машины (intra-VM sharing). При необходимости, его можно включить между виртуальными машинами (inter-VM sharing), если у них выставлено одинаковое значение «salt».

В связи с большой распространенностью страниц памяти размером 2MB (large memory pages), которые не «шарятся», даже если параметр Page Sharing включен, использование дедупликации страниц будет иметь в большинстве случаев незначительный эффект.

В инсталляциях, где используется большое количество мелких страниц памяти (например, VDI, где используется больное количество однотипных машин), Page Sharing может оказаться полезным.

По умолчанию значение «salt» для виртуальной машины это ее uuid, который всегда уникален, что ограничивает Page Sharing рамками данной VM.

Для того, чтобы включить Page Sharing на всех виртуальных машинах хоста, необходимо выставить параметр Mem.ShareForceSalting в значение 0.

Либо, для включения Page Sharing между определенной группой виртуальных машин, можно использовать параметр sched.mem.pshare.salt в конфигурационном параметре VM.

Следует ознакомиться со статьями в базе знаний VMware (1 , 2 )

Memory Swapping Optimizations

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

Далее следуют рекомендации, как этого избежать, либо минимизировать негативный эффект:

1. Не отключать Ballooning (не забывать устанавливать VMware Tools и следить за их работой в гостевой ОС), Page Sharing и Memory Compression;
2. При включении виртуальной машины ESXi создает swap файл для данной VM, который равен размеру памяти машины за вычетом зарезервированной для нее ОЗУ. Следовательно, дисковых ресурсов на хранилище должно быть достаточно для размещения swap файлов машин;
3. Если на хосте имеется SSD диск, не будет лишним задействовать его под кэш (Swatp to the Host Cache). Этот кэш доступен всем виртуальным машинам, располагаемым на хосте. Хороший вариант для SSD небольших размеров;
4. Хорошим выбором будет размещение swap файлов виртуальных машин на самых скоростных доступных дисках. Лучший выбор – локальный для хоста SSD. Если объема SSD недостаточно для хранения swap файлов машин, лучше его задействовать под Host Cache;
5. Если локальных SSD нет, следует размещать файлы на наиболее быстром доступном хранилище, подключенном, например, по Fibre Channel. К примеру, All-Flash массив;
6. Независимо от типа используемого хранилища для лучшей производительности и избегания потенциальной ситуации, связанной с нехваткой доступного дискового пространства, не следует размещать файлы подкачки на thin-provisioned хранилище.

По умолчанию swap файл создается там же, где хранится vmx файл виртуальной машины, изменить данный параметр можно в Advanced секции настроек VM.

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

Хорошая идея – зарезервировать для виртуальной машины тот объем памяти, с которым она регулярно работает.

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

Memory Overhead

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

1. Как уже было сказано часть памяти используется непосредственно гипервизором и его службами (hostd, vpxa и т.п.). ESXi может использовать системный swap файл и уменьшить потребление ОЗУ до 1GB, в ситуациях когда памяти перестает хватать для работы виртуальных машин. Для использования данной возможности необходимо создать swap файл самостоятельно. esxcli sched swap system set -d true -n <datastore name>. Создается файл объемом 1GB на указанном хранилище;
2. Дополнительная память используется для каждой запущенной виртуальной машины. Часть памяти резервируется для VMX процесса, часть для процесса VMM. Память резервируется также для виртуальных устройств (мышь, клавиатура, USB). Объем резервируемой оперативной памяти зависит от многих факторов, например, от количества vCPU, сконфигурированного объема памяти, 32-bit или 64-bit гостевая операционная система и т.п.

2MB Large Memory Pages

В дополнение к стандартным размерам страниц памяти в 4KB, ESXi так же может работать со страницами размером в 2MB (Large Pages).

ESXi назначает 2MB страницы гостевой ОС всегда, когда это возможно, даже если гостевая ОС их не запрашивает. Использование Large Pages снижает значения TLB miss, увеличивает производительность многих приложений, особенно, активно работающих с большими объемами памяти, так же уменьшаются служебные затраты ОЗУ на виртуальную машину.

ESXi не использует Page Sharing с большими страницами (скорее всего потому что найти пару двух одинаковых страниц достаточно тяжело). Однако, в случае нехватки оперативной памяти на хосте, большие страницы начинают дробиться на мелкие (4KB), задействуя при этом механизм Page Sharing.

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

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

Оперативная память виртуальных машин берется из памяти сервера, на которых работают ВМ. Это вполне очевидно:). Если оперативной памяти сервера не хватает для всех желающих, 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

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

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

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

  
• Замена экрана ноутбука красноярск
  
• Как получить нож xbox в murder mystery
  
• Read usb как переводится
  
• Как установить царский вк на айфон через компьютер
  
• Как делегировать поддомен на другие dns сервера