Досить часто, коли мова йде про своп віртуальної машини, багато хто розуміє файл підкачки Windows або SWAP розділ Linux, але ці поняття варто розділяти.
Для того щоб розібратися в питанні, пропоную згадати принципи роботи з пам'яттю в VMware ESXi.
Дисклеймер: Цей текст містить інформацію про базові принципи яка призначена для початківців в даній темі. Багато деталей навмисно не згадані для спрощення матеріалу.
У момент створення віртуальної машини, їй призначається певна кількість Virtual RAM, яке буде бачити гостьова ОС всередині віртуальної машини (наприклад 4 ГБ). Це значення називається Configured vRAM.
Не дивлячись на те, що гостьова ОС бачить 4 ГБ пам'яті, зовсім необов'язково дана пам'ять є 100% виділеної фізичною пам'яттю, яка доступна віртуальній машині в будь-який момент часу. Таким чином, на фізичному ESXi хості, з об'ємом пам'яті в 16 ГБ, ми можемо створити і запустити навіть 10 віртуальних машин по 4 ГБ або навіть по 8 ГБ оперативної пам'яті.
Це засновано на припущенні, що всі віртуальні машини не захочуть використовувати всі 100% своєї пам'яті в один момент часу і зможуть ділитися невикористаної пам'яттю під час роботи.
При цьому кожна віртуальна машина аллоцірует пам'ять невеликими блоками по мірі необхідності і звільняє під час непотрібності (якщо в ОС є такі механізми). Однак, якщо в якийсь момент, загальне споживання пам'яті всіма віртуальними машинами на хості перевищить обсяг доступної фізичної пам'яті 16 ГБ і якась із віртуальних машин зажадає ще кілька блоків в рамках своїх законних сконфигурированних 4 ГБ, то гипервизор бачили ці кілька блоків з свопу на диску.
Для цього і призначений .vswp файл віртуальної машини, про який я згадував тут.
Розмір файлу дорівнює об'ємом не зарезервованої оперативної пам'яті віртуальної машини (за замовчуванням вся пам'ять не зарезервована) і створюється в момент включення ВМ.
В принципі, до цього моменту все виглядає дуже схожим на звичний нам своп, але тут є один дуже підступний момент.
Візьмемо для прикладу файл підкачки Windows: Windows поміщає туди найменш затребувані блоки пам'яті, і намагається заздалегідь «діставати» їх звідти в разі потреби. Таким чином, використання файлу підкачки Windows це цілком нормальне явище, яке не має критичного впливу на продуктивність.
На відміну від Windows, гипервизор не має ні найменшого поняття, які блоки пам'яті критичні для віртуальної машини, а які не дуже затребувані і поміщає туди все підряд. Іронія в тому, що найчастіше це виявляються найбільш затребувані блоки.
У цій ситуації, операційна система думає що вона спілкується з блоками в оперативній пам'яті і чекає швидкої відповіді, але по факту, ці блоки зчитуються і записуються на диск, який по швидкості в кілька десятків (сотень?) Раз поступається. На практиці, віртуальна машина починає «безбожно тупить».
Дана ситуація для віртуальної машини можна порівняти катастрофи, тому загальна рекомендація - не допускати використання .vswp файлів, шляхом мінімізації Memory-overcommitment а для критичних віртуальних машин використання Memory Reservation.
Сподіваюся було доступно і корисно;)