Занимательная задачка из практики:
Виртуальная машина с линуксом в VMWare. 25 гигов памяти (в виртуалке). Внезапно мониторинг заорал, что память кончается. Пошли смотреть. Натурально, съедено гигов 20.
Сначала грешили на джаву, на которой там крутится пара десятков процессов. Погасили все. Не помогло, всё равно 16 гигов кто-то занимает.
А кто — загадка… Если просуммировать виртуальную память, занятую всеми процессами, набирается всего гигабайта четыре, а на самом деле ещё меньше, поскольку часть её делится на несколько процессов. Сегментов shared memory всего два, по 4 байта каждый. Под буфера занято мегабайт сорок.
А 16 гигов кто-то пожрал. Кто?!
Upd: дисковый кэш тоже ни при чём, он побольше, чем буфера, но всё равно в пределах нескольких десятков мегабайт.
tmpfs не используется.
Оригинал этой записи в личном блоге.
no subject
no subject
У ESX`а далеко не один и даже не два способа показать всем ВМ на хосте больше памяти, чем реально есть в наличии (Memory Overcommitment). Если не работал один - сработает другой.
Balloon - это один из самых оптимальных способов, ВМ сама про себя гораздо лучше знает, как ей работать с памятью и что именно можно вытеснить в swap. Если же этот вариант недоступен (vm tools не установлены, например) - тут уже начнётся другая игра, memory compression или там tmps или ещё как-то.
no subject
no subject
Вообще, если все ВМ на хосте захотят всю память одновременно, при этом есть Memory Overcommitment и у всех ВМ выключен баллон - следующий по логике шаг администратора будет выстрел в собственную ногу.
no subject
no subject