Достаточно часто, когда речь идет о свопе виртуальной машины, многие понимают файл подкачки Windows или SWAP раздел Linux, но эти понятия стоит разделять.

Для того что бы разобраться в вопросе, предлагаю вспомнить принципы работы с памятью в VMware ESXi.

Дисклеймер: Этот текст содержит информацию о базовых принципах которая предназначена для начинающих в данной теме. Многие детали преднамеренно не упомянуты для упрощения материала.

В момент создания виртуальной машины, ей назначается определенное количество Virtual RAM, которое будет видеть гостевая ОС внутри виртуальной машины (например 4 ГБ). Это значение называется Configured vRAM.

Не смотря на то, что гостевая ОС видит 4 ГБ памяти, совсем необязательно данная память является 100% выделенной физической памятью, которая доступна виртуальной машине в любой момент времени. Таким образом, на физическом ESXi хосте, с объемом памяти в 16 ГБ, мы можем создать и запустить даже 10 виртуальных машин по 4 ГБ или даже по 8 ГБ оперативной памяти.

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

При этом каждая виртуальная машина аллоцирует память небольшими блоками по мере необходимости и освобождает во время ненадобности (если в ОС есть такие механизмы). Однако, если в какой-то момент, общее потребление памяти всеми виртуальными машинами на хосте превысит объем доступной физической памяти 16 ГБ и какая-то из виртуальных машин потребует еще несколько блоков в рамках своих законных сконфигурированных 4 ГБ, то гипервизор виделит эти несколько блоков из свопа на диске.

Для этого и предназначен .vswp файл виртуальной машины, о котором я упоминал здесь.

Размер файла равняется объему не зарезервированной оперативной памяти виртуальной машины (по-умолчанию вся память не зарезервирована) и создается в момент включения ВМ.

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

Возьмем для примера файл подкачки Windows: винда помещает туда наименее востребованные блоки памяти, и старается заранее «доставать» их оттуда в случае необходимости. Таким образом, использование файла подкачки Windows это вполне нормальное явление, которое не имеет критического влияния на производительность.

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

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

Данная ситуация для виртуальной машины сравнима катастрофе, поэтому общая рекомендация — не допускать использование .vswp файлов, путем минимизации Memory-overcommitment а для критичных виртуальных машин использования Memory Reservation.

Надеюсь было доступно и полезно ;)