Память в Linux: как отличить нехватку ОЗУ от кэша

В выводе Linux занято почти всё ОЗУ — но это ещё не значит, что серверу не хватает памяти. Ядро использует свободные страницы для кэша и может освободить часть из них по запросу приложений. На Linux с ядром 6.8 разберём, как отличить такой кэш от настоящего дефицита, найти крупные процессы и заметить давление на память. Команды используют стандартные утилиты procps; их вывод может немного отличаться в разных дистрибутивах.

Сначала проверьте, сколько памяти доступно

Начните с free. Не пытайтесь определить состояние сервера по одному столбцу used: ориентируйтесь прежде всего на available и смотрите, меняется ли он со временем.

free -h

В строке Mem важны три значения:

• total — объём физической памяти, который видит система;
• available — оценка того, сколько памяти можно выделить приложениям без активного обмена со свопом;
• buff/cache — память, которую ядро использует, в частности, для кэширования данных.

Большой buff/cache сам по себе не повод расширять сервер: кэш может освободиться, когда память потребуется приложениям. Если available устойчиво мало, а задержки или ошибки приложений растут, проверяйте систему дальше. Универсальной доли «нормально занятой» памяти нет: запас зависит от нагрузки и того, какие процессы должны пережить её пик.

Термин. Своп — область на диске, куда система может перемещать страницы памяти. Он помогает пережить нехватку ОЗУ, но не равноценен ей: активное чтение и запись свопа могут замедлить приложения.

Четыре источника, которые отвечают на разные вопросы

У каждой команды своя задача. Сравните их, прежде чем делать вывод по одному снимку:

Если нужно сверить сводку с данными ядра, прочитайте ключевые поля из /proc/meminfo:

grep -E '^(MemTotal|MemFree|MemAvailable|Buffers|Cached|SwapTotal|SwapFree):' /proc/meminfo

Значения в этом файле обычно указаны в килобайтах. MemFree — полностью свободная память, а не вся память, которую система может быстро предоставить приложению. Для оценки запаса полезнее MemAvailable. Оно приблизительное: ядро оценивает, сколько кэша можно освободить, не загоняя систему в активный своп.

Пошаговая проверка на живом сервере

1. Снимите исходные показатели. Запустите free -h и запишите Mem available и использование свопа. Проверка: вы видите не только общий объём, но и доступную память.
2. Повторите замер в динамике. Выполните команду ниже, пока сервер работает под обычной нагрузкой. Проверка: в выводе есть несколько отчётов; сравнивайте строки, а не один разовый снимок.

vmstat 1 5

Первый отчёт vmstat показывает средние значения с момента загрузки, поэтому для оценки текущей ситуации смотрите на следующие строки. В них si и so — объёмы чтения из свопа и записи в него за интервал, обычно в килобайтах в секунду. Повторяющиеся ненулевые значения вместе с низким available — повод выяснить, какие приложения создают нагрузку.

1. Найдите процессы с большим RSS. Команда покажет десять процессов с наибольшим значением в списке. Проверка: в первых строках видны PID, имя процесса и RSS.

ps -eo pid,comm,rss --sort=-rss | head -n 11

RSS — оценка объёма физической памяти, находящейся в памяти процесса; в этом выводе единица измерения — килобайт. Не складывайте RSS процессов и не считайте сумму точным объёмом занятой ими памяти: общие страницы могут учитываться у нескольких процессов. Большой RSS также не доказывает утечку — сравните значения во времени и сопоставьте их с работой приложения.

1. Проверьте давление на память. На Linux 6.8 можно посмотреть показатели PSI, если они доступны в системе:

cat /proc/pressure/memory

Строки some и full отражают периоды, когда задачи простаивали из-за ожидания памяти. Поля avg10, avg60 и avg300 — усреднение за интервалы в секундах; total — накопленное время ожидания. Проверка: сравните показатели в нескольких снимках во время обычной работы и пика. Если файла нет, PSI может быть недоступен в конкретной конфигурации ядра — не делайте вывод о нормальном состоянии только по этой ошибке.

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

Как интерпретировать результат

• Кэш велик, available сохраняется, своп почти не меняется. Вероятнее всего, система использует память эффективно. Сбрасывать кэш вручную ради «освобождения» обычно не нужно: это не устраняет причину нагрузки и может ухудшить повторное чтение данных с диска.
• Available падает, но si и so почти всегда равны нулю. Проверьте, совпадает ли спад с запуском конкретного приложения или задачей по расписанию. Повторите замер в момент пика.
• Доступной памяти мало, si и so повторяются, PSI растёт. Система тратит время на работу с памятью, а не только хранит кэш. Сопоставьте эти показатели с журналами и нагрузкой приложений, затем ищите процесс или группу процессов, вызвавших рост.
• На хосте памяти достаточно, но процесс завершился с ошибкой. Если процесс работает в контейнере или ограниченной группе systemd, у неё может быть собственный лимит. Проверяйте ограничения и события OOM на уровне соответствующей группы: показания всего хоста их не отменяют.

Где эта проверка может ввести в заблуждение

Один замер не показывает, как менялась память до сбоя. Снимайте показатели с интервалом или подключите мониторинг и отметьте время ошибки приложения. ps тоже не заменяет профилировщик: RSS не объясняет, какие именно данные удерживает процесс и почему.

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

Что сделать дальше

Сохраните значения MemAvailable, si, so и PSI в момент обычной работы, а затем сравните их с периодом пиковых запросов или сбоев. Если проблема повторяется, свяжите замеры с PID и журналами приложения, отдельно проверив лимиты cgroup. Следующий полезный шаг — настроить мониторинг этих показателей с временным рядом: он покажет, что изменилось перед инцидентом, а не только после него.