How to Distinguish Memory Shortage from Standard Linux Cache

В панели почти вся оперативная память занята, но сайт работает нормально. Или наоборот: свободные мегабайты ещё видны, а запросы стали медленными. Одной цифры недостаточно. Linux использует часть памяти для кэша, а признаки реального давления нужно искать в доступном объёме и поведении системы во времени.

Команды рассчитаны на Linux с пакетом procps. Они не изменяют настройки памяти. В контейнере показания могут описывать не все ограничения приложения: лимит контейнера проверяют отдельно в его среде управления.

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

Для короткой серии наблюдений выполните:

Будет выведено шесть отчётов с интервалом в одну секунду. Первая строка содержит усреднённые с загрузки показатели активности; для текущего интервала смотрите следующие строки. Поля памяти при этом отражают состояние, поэтому нельзя описывать всю первую строку одним средним значением.

Если доступной памяти достаточно, swap почти не меняется, а ответы сайта быстрые, заполненный файловый кэш сам по себе не требует исправления. Принудительная очистка кэша может ухудшить ситуацию: данные придётся повторно читать с диска.

Если доступный объём падает, активность swap сохраняется и пользователи одновременно замечают задержки, гипотеза о нехватке памяти становится сильнее. Следующий шаг — выяснить, какие процессы растут и какие задания стартовали перед проблемой. Например, ночное резервирование может совпасть с импортом каталога и увеличить суммарное потребление.

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

Сохраните время замера, вывод обеих команд, число одновременно выполняемых задач и наблюдаемую задержку. Не делайте вывод об утечке по одному снимку: для неё важна динамика при сопоставимой нагрузке. После исправления повторите короткое наблюдение в тот же рабочий период.

Не отключайте swap и не меняйте параметры ядра как первый шаг. Сначала нужен подтверждённый сценарий: какой ресурс ограничен, когда это происходит и какой процесс создаёт нагрузку. Тогда решение можно проверить по результату, а не по изменившемуся цвету графика.

In the dashboard, almost all RAM appears occupied, yet the site runs normally. Or conversely: free megabytes are still visible, but requests have slowed down. A single number is insufficient. Linux uses part of the memory for cache, so signs of real pressure must be found in available memory and system behavior over time.

These commands are designed for Linux with the procps package. They do not change memory settings. In a container, the readings may not describe all application constraints: the container limit must be checked separately in its management environment.

Also record the swap volume and its usage status. Non-zero swap does not prove that the system is actively swapping pages to disk right now: some rarely used pages may have been moved there earlier.

For a short series of observations, run:

Six reports will be output at one-second intervals. The first line contains load-averaged activity metrics; for the current interval, refer to the following lines. Memory fields reflect the current state, so the entire first line cannot be described by a single average value.

If sufficient memory is available, swap usage remains minimal and site responses are fast; a filled file cache does not require intervention on its own. Forcing a cache clear can worsen the situation, as data must then be read from disk again.

If available memory drops, swap activity persists and users simultaneously notice delays, making the hypothesis of memory shortage more likely. The next step is to identify which processes are growing and which jobs started before the issue. For example, a nightly backup might coincide with a catalog import, increasing total consumption.

Distinguish between the server's total memory and a specific process's limit. An application may terminate due to its own limit even if system memory is free. The reverse situation is also possible: each process appears moderate, but their number has grown, causing total consumption to become excessive.

Save the measurement time, output from both commands, the number of concurrently running tasks, and the observed latency. Do not conclude a memory leak based on a single snapshot; dynamics under comparable load are essential. After applying a fix, repeat a short observation during the same working period.

Do not disable swap or change kernel parameters as a first step. First, confirm the scenario: which resource is constrained, when it occurs, and which process generates the load. Only then can the solution be validated by the result, not by a changed graph color.