Кто съел память?

[dil]

Занимательная задачка из практики:

Виртуальная машина с линуксом в VMWare. 25 гигов памяти (в виртуалке). Внезапно мониторинг заорал, что память кончается. Пошли смотреть. Натурально, съедено гигов 20.

Сначала грешили на джаву, на которой там крутится пара десятков процессов. Погасили все. Не помогло, всё равно 16 гигов кто-то занимает.

А кто — загадка… Если просуммировать виртуальную память, занятую всеми процессами, набирается всего гигабайта четыре, а на самом деле ещё меньше, поскольку часть её делится на несколько процессов. Сегментов shared memory всего два, по 4 байта каждый. Под буфера занято мегабайт сорок.

А 16 гигов кто-то пожрал. Кто?!

Upd: дисковый кэш тоже ни при чём, он побольше, чем буфера, но всё равно в пределах нескольких десятков мегабайт.

tmpfs не используется.

Оригинал этой записи в личном блоге.

Comments

[coolcold.livejournal.com]

ну там в /proc/meminfo , slabtop посмотреть?

[dil]

meminfo показывает то же самое, 25 гигов памяти, 16 занято, 9 свободно.
slabtop не пробовал, при случае покажу, что он показывает.

[coolcold.livejournal.com]

Ну т.е. из meminfo не становится ясно в какую конкретно область применения ушла память?

[dil]

Дык. Если б стало ясно, я бы и не спрашивал :)

На самом деле, у нас никто так и не угадал правильного ответа. Он обнаружился только после того, как начали поштучно перезапускать всё запущенное, и в некоторый момент поняли, чтО это было.

[coolcold.livejournal.com]

Я загадку понял так - кто знает куда надо было посмотреть чтобы понять :)

[dil]

Ну тут некоторые угадали, даже никуда не посмотрев :)

[pash7ka.livejournal.com]

Может это дисковый кэш так вырос?

[dil]

Не, там тоже несколько десятков мегабайт, чуть побольше, чем в буферах, но не принципиально.

[3apa3a-b-ta3e.livejournal.com]

Memory balloon, я прозреваю.

[dil]

Кто-кто?

[3apa3a-b-ta3e.livejournal.com]

специальный драйвер в vm-tools, который "надувает" баллон в памяти виртуалки, когда памяти не хватает на хосте, заставляя гостевую ос своппиться.

[dil]

Ага, он самый. Век живи - век учись, я даже не знал, что это так называется.
В данном случае до свопинга не дошло, там ещё оперативной памяти достаточно оставалось, видимо потому никто и не вспомнил про такую фичу.

[3apa3a-b-ta3e.livejournal.com]

Ключевое слово - Vmware.
На самом деле - штука очень и очень полезная, MS пытался что-то такое повторить в Hyper-V, но получилось как всегда и всем рассказали, что "да и не надо вам это".

[dil]

Полезность её сомнительна. Особенно учитывая, что в гостевой системе она может быть ограничена или вовсе отключена. Что тогда будет при нехватке физической памяти в хосте? Гостевая ОС залипнет при попытке обращения к памяти, или что?

[3apa3a-b-ta3e.livejournal.com]

Скажете тоже, залипнет, это ж не Hyper-V и не Xen-server.

У ESX`а далеко не один и даже не два способа показать всем ВМ на хосте больше памяти, чем реально есть в наличии (Memory Overcommitment). Если не работал один - сработает другой.

Balloon - это один из самых оптимальных способов, ВМ сама про себя гораздо лучше знает, как ей работать с памятью и что именно можно вытеснить в swap. Если же этот вариант недоступен (vm tools не установлены, например) - тут уже начнётся другая игра, memory compression или там tmps или ещё как-то.

[dil]

Показать-то больше можно, это понятно, но что делать хосту, когда виртуальные машины одновременно захотят всю эту память использовать, а её физически больше нет?

[3apa3a-b-ta3e.livejournal.com]

Если честно, то не знаю, не сталкивался на практике.

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

[dil]

С администратором всё ясно, но мне интересно, как поведёт себя в этом случае хостовая система.

[3apa3a-b-ta3e.livejournal.com]

Мне не очень интересно, если честно, ибо это вопрос из разряда - "а что будет, если в линуксе отключить своп и установить swappiness в 0".

[3apa3a-b-ta3e.livejournal.com]

и да, я телепат 80го уровня :-)