Память Linux: почему мало free ещё не означает утечку
На какие показатели смотреть при нехватке памяти в Linux и как отличить файловый кэш от роста памяти приложения.
- freeСколько памяти сейчас совсем не занято
- availableСколько можно предоставить приложениям
- RSSКакие процессы держат страницы в RAM
В выводе free почти нет свободной памяти, но сервер работает нормально. Это не повод сразу искать утечку: Linux занимает свободное место файловым кэшем и при необходимости может его освободить. Посмотрим на available, RSS процессов и ограничения контейнера, а затем сравним показатели во времени.
Смотрим доступный объём
free -h
ps -eo pid,comm,rss,vsz --sort=-rss | head -n 12available оценивает объём, доступный новым приложениям без перехода к подкачке. Это полезнее, чем чтение только free, но остаётся оценкой ядра. RSS показывает резидентную память процесса, VSZ — размер виртуального адресного пространства. Большой VSZ сам по себе не доказывает расход соответствующего количества физической памяти.
Не складываем RSS без оговорок
Несколько процессов могут использовать общие страницы. Простое сложение RSS способно учитывать их повторно. Для уточнения смотрят пропорциональную долю общей памяти и сведения smaps при наличии прав. Сначала найдите процесс-кандидат и устойчивую тенденцию, а затем выбирайте более подробный инструмент.
В контейнере дополнительно важен лимит группы ресурсов. На машине может оставаться свободная память, а конкретный контейнер уже достигнет своего ограничения. Сопоставляйте показатели приложения, контейнера и хоста, сохраняя время измерений и характер нагрузки.
Проверяем гипотезу об утечке
Запишите показатели до нагрузки, после одинакового набора запросов и после периода простоя. Учитывайте прогрев кэша, число рабочих процессов и фоновые задачи. Один снимок после тяжёлого отчёта не доказывает утечку. Повторяемый рост при сопоставимой нагрузке — основание для профилирования.
Очищать файловый кэш ради красивого free не стоит: после этого серверу, вероятно, придётся снова читать данные с диска. Наблюдайте за изменениями и связывайте их с конкретным процессом, нагрузкой или лимитом контейнера. Так появится основание для решения, нужен ли перезапуск или дополнительная память.