Memory Ballooning в VMware ESX - некоторые аспекты работы техник Overcommit. 16/06/2010 Реклама: Пост:

Многим пользователям платформы виртуализации VMware vSphere / ESX известен такой механизм оптимизации работы виртуальных машин с оперативной памятью как Memory Ballooning (о нем хорошо написано в документе "Understanding Memory Resource Management in VMware ESX Server"). Если вкратце - то это техника гипервизора по работе с оперативной памятью, которая позволяет запустить на хосте ESX виртуальные машины, совокупная выделенная память которых больше суммарной памяти хоста.

Достигается это за счет использования драйвера vmmemctl.sys, поставляемого вместе с VMware Tools. Он позволяет "надуть" шар внутри гостевой ОС (balloon), который захватывает физическую память, выделенную этой ОС, и отдает ее другим гостевым операционным системам, которые в ней нуждаются. Этот balloon не позволяет гостевой ОС производить работу приложений с данной областью памяти, поэтому если им потребуется дополнительная память - она будет уходить в гостевой своп. Это более правильный подход, чем свопировать гостевую ОС в файл подкачки vswp на томе VMFS, поскольку операционная система сама лучше разбирается, что и когда ей класть и доставать из свопа (соответственно, быстродействие выше).

Недавно у известного блоггера Дункана Эппинга спросили вот про такой интересный случай. Пользователь запустил команду esxtop на странице с показателями памяти для виртуальных машин и получил вот такой результат:

Собственно, какова ситуация, если смотреть по счетчикам на картинке:

Глобальные статистики:

• 1393 Free -> Сейчас 1393 МБ физической памяти хоста доступно
• High State -> Состояние, в котором считается, что хост не испытывает проблем с памятью
• SWAP /MB 146 Cur -> 146 МБ находится в свопе
• SWAP /MB 83 Target -> Целевой объем памяти, который должен быть в свопе - 83 МБ
• 0.00 r/s -> Из свопа ничего не читается
• 0.00 w/s -> В своп ничего не пишется

Статистики виртуальной машины (обведено красным):

• MCTLSZ 1307.27 -> Объем физической памяти гостевой системы, заполненной balloon-драйвером - 1307.27 МБ
• MCTLTGT 1307.27 -> Объем физической памяти гостевой системы, который будет сохарнен balloon-драйвером - 1307.27 МБ
• SWCUR 146.61 -> В свопе находится 146.61 МБ данных.
• SWTGT 83.75 -> Целевой объем памяти, который который должен быть в свопе - 83.75 МБ

С одной стороны хост ESX выглядит типично overcommited, то есть balloon-драйвер раздулся. С другой же стороны, сервер VMware ESX находится в состоянии High State, что означает, что свободно более 6% памяти и проблем с ней нет (кроме того, ничего не пишется и не читается из файла подкачки). Казалось бы, здесь есть некоторое противоречие - если у хоста нет проблем с памятью, то почему balloon до сих пор надут и не сдувается?

Посмотрим на соотношение свободной памяти хоста ESX и размер области, занятой balloon'ом: 1393 МБ и 1307.27 МБ, соответственно. Они приблизительно равны. Это означает, что при сдутии balloon'а гостевая ОС, в которой он был надут, начнет отъедать физическую память хоста ESX (да и еще выгружать своп). Это приведет к тому, что объем доступной памяти хоста ESX упадет и он снова окажется в ситуации, когда необходимо снова надувать balloon.

То есть VMware ESX (и драйвер vmmemctl) не делают резких движений, растут и сдуваются постепенно, делая оглядку на то, какая ситуация может получиться.