При администрировании гостевых ВМ, запущенных на хостах виртуализации (будь то 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. Итак, разберем такую ситуацию:
Чтобы понять, что происходит с памятью, нужно воспользоваться утилитой RamMap Марка Русиновича (в одних из прошлых кейсов я показывал, как использовать эту утилиту для диагностики проблемы с системным кэшем файловой системы ). Качаем утилиту с сайта Microsoft (https://technet.microsoft.com/en-us/library/ff700229.aspx) и запускаем с правами администратора. После этого, на вкладке Use Counts видим, что большая часть памяти (5,4 Гб) используется объектом Driver Locked .
Это и есть та память, которую «отъел» гипервизор и перераспределил другим виртуальным машинам через balloon-драйвер в гостевой ОС. Т.е. на хосте гипервизора не хватает памяти, либо администратор гипервизора принудительно «зарезал» ресурсы для данной ВМ.
Текущий расклад по памяти в ВМ на Hyper-V могут дать счетчики отдельные производительности в Performance Monitor:
Чтобы отключить такое поведение, администратор гипервизора должен отключить в настройках ВМ Hyper-V опцию Enable Dynamic Memor y (или увеличить значение минимальной резервации).
Если используется хост VMWare ESXi – можно в настройках выделения ресурсов ( Resource Settings ) зарезервировать для данной машины больше памяти, либо сразу зарезервировать всю память – Reserve all guest memory (All locked).
Как менялся логотип Apple на протяжении многих лет. Логотип Apple — это не просто символ,…
Security Boot Fail при загрузке Acer — решение проблемы При загрузке ноутбука Acer с флешки,…
Ноутбук не включается — варианты решения Если при попытке включить ноутбук вы обнаруживаете, что он…
The AC power adapter wattage and type cannot be determined — причины и решение При…
Свистит или звенит блок питания компьютера — причины и решения Некоторые владельцы ПК могут обратить…
Мигает Caps Lock на ноутбуке HP — почему и что делать? При включении ноутбука HP…