Определение Memory overcommit в гостевой виртуальной машине

При администрировании гостевых ВМ, запущенных на хостах виртуализации (будь то VMWare ESXi или Hyper-V), при анализе проблем с производительностью довольно часто приходится сталкивается с ситуациями, когда количество доступной памяти ОС оказывается намного меньше, чем видит (назначено) операционная система. К примеру, виртуальной машине выделено 8 Гб памяти, диспетчер задач показывает свободным 1 Гб памяти, при это суммарное потребление памяти всеми запущенными процессами не превышает 3 Гб. Куда делись оставшиеся 4 Гб?

Как правило, причиной такого поведения является использование в гипервизоре функции memory overcommit.

Memory overcommit (определения на русском я не знаю, пусть будет оверкоммит памяти) это фича гипервизора, которая позволяет выделить виртуальным машинам памяти больше, чем имеется на физическом хосте, однако без гарантии того, что в конкретный момент времени вся запрошенная память может быть выделена. Как правило, overcommit позволяет увеличить плотность размещения виртуальных машин на хосте за счет того, что память будет динамически перераспределятся между ними в зависимости от текущей нагрузки (ресурсы ненагруженных/простаивающих в данный момент ВМ могут быть перераспределены между более загруженными)

В VMWare одним их механизмов реализации memory overcommited является Memory Ballooning (вытеснение памяти, или если хочется, надувательство). В Hyper-V аналогичный функционал реализуется функцией Dynamic Memory.

В VMWare balloon реализуется за счет драйвера vmmemctl.sys (входит в VMware Tools), который в случае необходимости может захватить физическую память, надув внутри памяти фиктивный процесс-шар (baloon). Таким образом занятая память становится недоступна приложениям, а гипервизор может перераспределить высвобожденную память между другими ВМ. В случае Hyper-V Dynamic memory используется драйвер dmvsc.sys из комплекта служб интеграции (компонент Dynamic Memory VSC). Настройками overcommit управляет администратор гипервизора.

А как же определить изнутри ВМ, что ей реально доступно меньше физической памяти, чем то, которое видит операционная система?

Рассмотрим, как определить наличие и размер balloon драйвера в гостевой ОС Windows. Итак, разберем такую ситуацию:

ВМ с гостевой Windows Server 2012 R2 выделено 8 Гб оперативной памяти. Диспетчер задач показывает, что память используется на 93% (7,4 Гб памяти занято). Однако, если сложить количество памяти, которое используют все запущенные процессы, можно прийти к неожиданному выводу – реально используется только 2,5 Гб. Куда же делись 5 Гб памяти? Ни Task Manager, ни Resource Monitor ответа на этот вопрос не дадут.

Чтобы понять, что происходит с памятью, нужно воспользоваться утилитой RamMap Марка Русиновича (в одних из прошлых кейсов я показывал, как использовать эту утилиту для диагностики проблемы с системным кэшем файловой системы). Качаем утилиту с сайта Microsoft (https://technet.microsoft.com/en-us/library/ff700229.aspx) и запускаем с правами администратора. После этого, на вкладке Use Counts видим, что большая часть памяти (5,4 Гб) используется объектом Driver Locked.

Это и есть та память, которую «отъел» гипервизор и перераспределил другим виртуальным машинам через balloon-драйвер в гостевой ОС. Т.е. на хосте гипервизора не хватает памяти, либо администратор гипервизора принудительно «зарезал» ресурсы для данной ВМ.

Текущий расклад по памяти в ВМ на Hyper-V могут дать счетчики отдельные производительности в Performance Monitor:

• Hyper-V Dynamic Memory –>Guest Visible Memory
• Hyper-V Dynamic Memory –> Physical Memory

Чтобы отключить такое поведение, администратор гипервизора должен отключить в настройках ВМ Hyper-V опцию Enable Dynamic Memory (или увеличить значение минимальной резервации).

Если используется хост VMWare ESXi – можно в настройках выделения ресурсов (Resource Settings) зарезервировать для данной машины больше памяти, либо сразу зарезервировать всю память – Reserve all guest memory (All locked).