Команды и инструменты для проверки потребления RAM в Linux

Мониторинг использования RAM в Linux означает запрос подсистемы памяти ядра для получения метрик о распределении физической памяти, использовании swap и размерах резидентного набора для каждого процесса. Наиболее прямые методы используют встроенные утилиты — free, top, htop, ps, vmstat и smem — каждая из которых открывает разный уровень иерархии памяти: от общесистемных итогов до пропорционального размера набора (PSS) для каждого процесса.

Чрезмерное давление на память запускает механизм Linux Out-of-Memory (OOM) killer, который принудительно завершает процессы для освобождения RAM. Понимание того, какие команды раскрывают какие метрики — и что эти метрики на самом деле означают — это разница между реактивным устранением проблем и проактивным управлением ресурсами. В этом руководстве рассматриваются все основные инструменты, источники данных ядра, из которых они читают, и крайние случаи, которые застают врасплох даже опытных администраторов.

Почему мониторинг RAM важен на серверах Linux

Управление памятью в Linux намеренно агрессивно. Ядро использует всю доступную RAM в качестве кэша страниц для ускорения дискового ввода-вывода, что означает: система, сообщающая о почти нулевой свободной памяти, не обязательно находится под давлением — она может просто эффективно кэшировать данные. Неправильное понимание этого поведения является одной из наиболее распространённых ошибок при интерпретации необработанных показателей памяти.

Основные причины для непрерывного мониторинга RAM:

• Предотвращение OOM killer: Выявляйте процессы, потребляющие много памяти, до того, как ядро завершит критически важные службы.
• Обнаружение использования swap: Интенсивная активность swap (свопинг) указывает на исчерпание RAM и вызывает серьёзную задержку ввода-вывода.
• Диагностика утечек памяти: Процессы с постоянно растущим RSS со временем сигнализируют об утечках на уровне приложения.
• Планирование ресурсов: Данные о тенденциях помогают принимать решения о вертикальном масштабировании или перераспределении нагрузки.
• Настройка производительности: Настройка vm.swappiness, огромных страниц и топологии NUMA требует базовых данных о памяти.

В среде VPS Хостинга, где ресурсы совместно используются или ограничены гипервизором, точный мониторинг RAM особенно важен — достижение предела памяти незаметно снижает производительность до того, как сработает какое-либо оповещение.

Понимание терминологии памяти Linux

Прежде чем выполнять какую-либо команду, необходимо понять, что на самом деле представляют столбцы вывода.

Важное замечание: Всегда используйте столбец Available из free -h, а не столбец Free, при оценке того, достаточно ли у системы RAM для новой рабочей нагрузки. Столбец Free игнорирует освобождаемый кэш, что приводит к ложным тревогам.

Файл /proc/meminfo: Авторитетный источник

Каждый инструмент, описанный в этой статье, читает из /proc/meminfo — виртуального файла, поддерживаемого ядром в режиме реального времени. Его непосредственный просмотр даёт наиболее детальные доступные данные:

cat /proc/meminfo

Ключевые поля для наблюдения:

• MemTotal — общая используемая RAM
• MemFree — полностью простаивающая RAM
• MemAvailable — расчётная доступная RAM для новых процессов
• Buffers — необработанный кэш дисковых блоков
• Cached — кэш страниц для файлов
• SwapTotal / SwapFree — ёмкость и доступность swap
• Dirty — память, ожидающая записи на диск (высокие значения указывают на давление ввода-вывода)
• HugePages_Total / HugePages_Free — статус выделения огромных страниц
• Slab — кэш структур данных ядра (может сильно вырасти на загруженных NFS или серверах баз данных)

Понимание /proc/meminfo позволяет интерпретировать вывод любого другого инструмента с полным контекстом.

Проверка RAM с помощью команды free

free — это самый быстрый способ получить общесистемный снимок памяти. Он читает непосредственно из /proc/meminfo и форматирует вывод в удобочитаемую таблицу.

Базовое использование

free

По умолчанию вывод в килобайтах. Используйте флаги для более удобочитаемых форматов:

free -h        # Human-readable (MB/GB)
free -m        # Output in megabytes
free -g        # Output in gigabytes
free -s 5      # Refresh every 5 seconds (continuous monitoring)
free -h --si   # Use SI units (1000-based) instead of binary (1024-based)

Пояснение к примеру вывода

              total        used        free      shared  buff/cache   available
Mem:           15Gi       4.2Gi       1.1Gi       312Mi       9.8Gi       10.9Gi
Swap:         2.0Gi       128Mi       1.9Gi

В этом примере система, по всей видимости, имеет только 1,1 ГБ свободной памяти, но 10,9 ГБ фактически доступно для новых процессов, поскольку ядро освободит buff/cache по требованию. Это самое важное, что нужно понять о выводе free.

Крайний случай: использование swap как сигнал предупреждения

Даже небольшое использование swap (Swap: used > 0) на производственном сервере требует расследования. Это означает, что ядро уже решило, что некоторые страницы памяти лучше хранить на диске, чем в RAM — признак того, что рабочий набор превышает физическую память.

Проверка RAM с помощью команды top

top предоставляет непрерывно обновляемый просмотр системных ресурсов в реальном времени, объединяя статистику CPU и памяти со списком процессов, упорядоченным по рангу.

top

Ключевые поля памяти в top

В верхней части интерфейса top две строки показывают статистику памяти:

MiB Mem :  16384.0 total,   1126.4 free,   4301.2 used,  10956.4 buff/cache
MiB Swap:   2048.0 total,   1920.0 free,    128.0 used.  11200.0 avail Mem

В таблице процессов наиболее релевантные столбцы памяти:

• VIRT — размер виртуальной памяти (эквивалент VSZ)
• RES — резидентная физическая память (RSS)
• SHR — доля разделяемой памяти в RES
• %MEM — процент используемой физической RAM

Полезные интерактивные команды top

Запуск top в неинтерактивном режиме

Для написания скриптов и захвата журналов запустите top в пакетном режиме:

top -b -n 1 | head -30

Это выводит единственный снимок — полезно для скриптов мониторинга на основе cron.

Проверка RAM с помощью htop

htop — это улучшенный просмотрщик процессов на основе ncurses, который представляет те же базовые данные, что и top, со значительно более удобным интерфейсом. По умолчанию он не установлен в большинстве дистрибутивов.

Установка

# Debian / Ubuntu
apt-get install htop

# RHEL / CentOS / AlmaLinux / Rocky Linux
yum install htop
# or on newer versions:
dnf install htop

# Alpine Linux
apk add htop

Что htop добавляет по сравнению с top

• Цветные полосы памяти, различающие используемую память, буферы и кэш с первого взгляда
• Горизонтальный и вертикальный вид дерева процессов (F5)
• Поддержка мыши для кликов и прокрутки
• Множественный выбор для массового управления процессами
• Встроенный поиск (F3) и фильтр (F4) без запоминания сочетаний клавиш
• Прямое отображение доступной памяти на видном месте в заголовке

Цветовая легенда полосы памяти htop

Совет профессионала: В htop нажмите F2 (Настройка) > Параметры отображения > включите «Show CPU frequency» и «Detailed CPU time» для более полной картины наряду с данными о памяти.

Проверка RAM с помощью команды ps

ps (статус процесса) запрашивает таблицу процессов ядра и может быть отсортирован и отфильтрован для определения основных потребителей памяти в конкретный момент времени.

Сортировка процессов по потреблению памяти

ps aux --sort=-%mem

Пояснение к столбцам вывода

Практические однострочные команды

Показать 10 процессов с наибольшим потреблением памяти в удобочитаемом формате:

ps aux --sort=-%mem | head -11

Показать использование памяти для конкретного имени процесса (например, Apache):

ps aux | grep apache2 | awk '{sum += $6} END {print sum/1024 " MB"}'

Это суммирует значения RSS всех рабочих процессов apache2 — критически важно для понимания реального объёма многопроцессных веб-серверов.

Важная оговорка: ps показывает RSS, который дважды учитывает разделяемые библиотеки. Если 20 рабочих процессов Apache каждый отображает одну и ту же разделяемую библиотеку размером 50 МБ, ps сообщает о 1 000 МБ использования разделяемой библиотеки по всем ним, тогда как фактическая физическая стоимость составляет всего 50 МБ. Используйте smem для точного учёта.

Проверка RAM с помощью smem

smem — наиболее точный инструмент учёта памяти для каждого процесса, доступный в Linux, поскольку он сообщает PSS (Proportional Set Size) — разделяемая память делится пропорционально между всеми процессами, которые её отображают, устраняя проблему двойного подсчёта, присущую инструментам на основе RSS.

Установка

# Ubuntu / Debian
apt-get install smem

# CentOS / RHEL 7
yum install smem

# RHEL 8+ / AlmaLinux / Rocky Linux
dnf install smem

# Alternatively, install via pip
pip install smem

Базовое использование

smem

Полезные параметры smem

smem -r              # Sort by RSS (descending)
smem -s pss -r       # Sort by PSS (most accurate, descending)
smem -u              # Aggregate by user
smem -m              # Show system-wide memory map
smem -p              # Show percentages instead of raw KB
smem -k              # Show values in KB
smem -t              # Show totals row
smem --pie name      # Generate a pie chart (requires matplotlib)
smem -P apache2      # Filter by process name pattern

PSS против RSS: почему это важно

Рассмотрим сервер, на котором работают 10 рабочих процессов Node.js, каждый из которых использует общую библиотеку V8 размером 100 МБ:

• RSS на процесс: 200 МБ (100 МБ общих + 100 МБ частных)
• Общий сообщаемый RSS: 2 000 МБ
• PSS на процесс: 110 МБ (10 МБ доля от 100 МБ + 100 МБ частных)
• Общий сообщаемый PSS: 1 100 МБ
• Фактически используемая физическая RAM: 1 100 МБ

RSS завышает использование почти в 2 раза в этом сценарии. При принятии решений о масштабировании на Выделенном сервере, использование PSS из smem даёт вам достоверные данные.

Проверка RAM с помощью vmstat

vmstat (статистика виртуальной памяти) предоставляет более широкий обзор памяти, swap, ввода-вывода и активности CPU, что делает его идеальным для диагностики общесистемного давления на память, а не проблем отдельных процессов.

vmstat 2 10    # Report every 2 seconds, 10 times

Ключевые столбцы памяти

Критический сигнал: Ненулевые значения si (считывание из swap) и so (запись в swap) в работающем потоке vmstat указывают на активный свопинг — окончательный признак исчерпания памяти. Даже периодические всплески so могут вызывать скачки задержки приложения в сотни миллисекунд.

Проверка RAM с помощью sar (System Activity Reporter)

sar из пакета sysstat записывает исторические данные о памяти, обеспечивая ретроспективный анализ — то, что инструменты реального времени не могут предоставить.

Установка

apt-get install sysstat    # Debian/Ubuntu
yum install sysstat        # CentOS/RHEL

Использование

sar -r 1 5          # Memory stats every 1 second, 5 times
sar -r -f /var/log/sysstat/sa$(date +%d)   # Today's historical data
sar -S 1 5          # Swap statistics

sar незаменим для ответа на вопросы вроде «Был ли скачок памяти в 3 часа ночи, который вызвал сбой приложения?» — вопрос, на который ни один инструмент реального времени не может ответить постфактум.

Проверка RAM с помощью /proc/<PID>/status и /proc/<PID>/smaps

Для глубокого анализа отдельных процессов ядро предоставляет подробные карты памяти непосредственно в /proc.

Быстрая проверка памяти для конкретного процесса

cat /proc/$(pgrep nginx | head -1)/status | grep -E "VmRSS|VmPeak|VmSize|VmSwap"

Пример вывода:

VmPeak:   512340 kB
VmSize:   498120 kB
VmRSS:    102400 kB
VmSwap:        0 kB

• VmPeak — пиковый размер виртуальной памяти, когда-либо достигнутый этим процессом
• VmRSS — текущий размер резидентного набора
• VmSwap — сколько этого процесса было выгружено в swap

Подробная карта памяти с smaps

cat /proc/$(pgrep mysql | head -1)/smaps | grep -E "^(Size|Rss|Pss|Shared|Private)"

Это раскрывает каждое отображение памяти (куча, стек, разделяемые библиотеки, анонимные отображения) с индивидуальными значениями RSS и PSS — наиболее детальный вид памяти, доступный без профилировщика.

Сравнение инструментов: выбор правильной команды

Практические рабочие процессы мониторинга

Рабочий процесс 1: Быстрая сортировка (менее 60 секунд)

free -h                          # Step 1: Is Available memory critically low?
vmstat 1 5                       # Step 2: Is active swapping occurring?
ps aux --sort=-%mem | head -15   # Step 3: Which processes are the top consumers?

Рабочий процесс 2: Выявление утечки памяти

# Watch a specific process's RSS grow over time
watch -n 5 'ps -o pid,rss,vsz,comm -p $(pgrep your_app)'

# Or use smem with repeated snapshots
while true; do smem -P your_app -t; sleep 30; done

Рабочий процесс 3: Ретроспективный анализ после инцидента

sar -r -f /var/log/sysstat/sa$(date +%d --date='yesterday')

Рабочий процесс 4: Скрипт автоматического оповещения

#!/bin/bash
THRESHOLD=90
USED_PCT=$(free | awk '/^Mem:/ {printf "%.0f", $3/$2 * 100}')
if [ "$USED_PCT" -gt "$THRESHOLD" ]; then
    echo "ALERT: RAM usage at ${USED_PCT}% on $(hostname)" | mail -s "Memory Alert" admin@example.com
fi

Этот скрипт можно разместить в задании cron для непрерывного автоматического мониторинга — практическая необходимость на любом производственном VPS с cPanel или физическом сервере.

Дополнительно: Параметры настройки памяти ядра

После выявления давления на память эти параметры sysctl непосредственно влияют на поведение:

# View current swappiness (default: 60)
sysctl vm.swappiness

# Reduce swap tendency (recommended for databases: 10)
sysctl -w vm.swappiness=10

# Increase dirty page write-back aggressiveness
sysctl -w vm.dirty_ratio=15
sysctl -w vm.dirty_background_ratio=5

# Drop page cache manually (use with caution on production)
sync; echo 3 > /proc/sys/vm/drop_caches

Пояснение vm.swappiness: Значение 60 означает, что ядро начнёт свопинг при 40% использовании RAM. Для серверов баз данных (MySQL, PostgreSQL, Redis) установка этого значения в 10 удерживает данные в RAM значительно дольше, резко снижая задержку ввода-вывода. Для настольных систем или систем с ограниченной RAM значение по умолчанию более подходит.

Распространённые ошибки и неверные интерпретации

Ошибка 1: Паника из-за низкой «свободной» памяти

Как объяснялось ранее, Linux намеренно использует свободную RAM в качестве кэша. Система с 200 МБ свободной памяти, но 8 ГБ доступной — в хорошем состоянии. Всегда читайте столбец Available.

Ошибка 2: Суммирование RSS для оценки общего использования памяти

Суммирование значений RSS ps по всем процессам, как правило, превысит общую физическую RAM из-за двойного подсчёта разделяемых библиотек. Используйте smem -t для точного системного итога.

Ошибка 3: Игнорирование кэша Slab

На загруженных клиентах NFS или серверах с множеством небольших файлов аллокатор Slab ядра может потреблять гигабайты RAM. Проверьте cat /proc/meminfo | grep Slab — эта память технически освобождаема, но не отображается в инструментах уровня процессов.

Ошибка 4: Путаница VSZ с фактическим использованием памяти

Приложение Java может показывать 4 ГБ VSZ, но только 512 МБ RSS. VSZ включает файлы, отображённые в память, зарезервированную, но не выделенную кучу и разделяемые библиотеки — большинство из которых никогда не загружается в физическую RAM.

Ошибка 5: Пренебрежение памятью в контейнерных рабочих нагрузках

Внутри контейнера Docker free показывает общую память хоста, а не лимит cgroup контейнера. Используйте cat /sys/fs/cgroup/memory/memory.usage_in_bytes и cat /sys/fs/cgroup/memory/memory.limit_in_bytes для точных метрик на уровне контейнера.

Настройка постоянного мониторинга RAM

Для производственных сред команды, выполняемые в конкретный момент времени, недостаточны. Рассмотрите эти подходы для непрерывной видимости:

• sysstat с cron: Автоматически включает сбор исторических данных sar.
• Prometheus + Node Exporter: Собирает метрики /proc/meminfo и предоставляет их для дашбордов Grafana.
• Netdata: Мониторинг в реальном времени с нулевой конфигурацией, посекундной детализацией и встроенным обнаружением аномалий памяти.
• Zabbix или Nagios: Корпоративные оповещения с настраиваемыми порогами памяти и политиками эскалации.

При запуске рабочих нагрузок на инфраструктуре GPU Хостинга также следите за VRAM GPU наряду с системной RAM — nvidia-smi --query-gpu=memory.used,memory.free --format=csv предоставляет эквивалентные метрики для памяти GPU.

Для сред веб-хостинга, управляемых через Панели управления VPS, большинство панелей включают встроенные графики памяти — но они, как правило, опрашивают данные с интервалом 1–5 минут и пропустят кратковременные всплески, которые vmstat или sar зафиксировали бы.

Матрица технических решений: какой инструмент использовать и когда

Контрольный список ключевых выводов

• Всегда проверяйте доступную память из free -h, а не столбец Free, для оценки фактического запаса.
• Используйте vmstat 1 5 для подтверждения или исключения активного свопинга перед эскалацией расследования.
• Используйте smem -s pss -r вместо ps aux --sort=-%mem, когда вам нужны точные данные о памяти для каждого процесса — особенно на серверах со многими процессами, использующими общие библиотеки.
• Устанавливайте sysstat на каждый производственный сервер сразу после подготовки, чтобы включить исторический сбор данных sar.
• Устанавливайте vm.swappiness=10 постоянно в /etc/sysctl.conf на серверах баз данных для минимизации использования swap.
• Проверяйте /proc/meminfo на значения Slab и Dirty, когда стандартные инструменты не объясняют наблюдаемое давление на память.
• Для контейнерных рабочих нагрузок читайте файлы памяти cgroup — а не free — для точных лимитов и использования.
• В средах общего хостинга или VPS устанавливайте базовые показатели памяти в период нормальной работы, чтобы аномалии были немедленно распознаваемы.

—

Часто задаваемые вопросы

В чём разница между «свободной» и «доступной» памятью в Linux?

«Свободная» — это RAM, которая вообще не используется. «Доступная» — это реалистичная оценка памяти, которую можно выделить новым процессам без запуска свопинга — она включает освобождаемый кэш страниц и буферы. На здоровом сервере Linux «свободная» память часто близка к нулю, тогда как «доступная» остаётся высокой. Всегда используйте «доступную» для оценки ресурсов.

Почему сумма значений RSS всех процессов превышает общую физическую RAM?

RSS (Resident Set Size) учитывает разделяемую память — например, разделяемые библиотеки — по одному разу для каждого процесса, который её отображает. Если 50 процессов каждый отображает разделяемую библиотеку размером 100 МБ, общая сумма RSS раздувается на 4 900 МБ сверх фактической физической стоимости. Используйте smem с отчётностью PSS для устранения этого двойного подсчёта.

Как найти, какой процесс запустил Linux OOM killer?

Выполните dmesg | grep -i "oom|killed process" или journalctl -k | grep -i oom. Ядро записывает точное имя процесса, PID и статистику памяти в момент события завершения, включая oom_score всех оцениваемых процессов.

Что означает высокое использование swap и насколько это серьёзно?

Устойчивое использование swap означает, что рабочий набор системы превышает физическую RAM. Ядро компенсирует это, выгружая данные на диск, что обычно в 100–1 000 раз медленнее, чем доступ к RAM. Даже умеренная активность swap вызывает измеримую задержку приложения. Это окончательный сигнал либо сократить потребление памяти, увеличить RAM, либо перераспределить рабочие нагрузки.

Можно ли отслеживать использование RAM внутри контейнера Docker с помощью стандартных команд Linux?

Стандартные команды, такие как free внутри контейнера, показывают общую RAM хоста, а не лимит cgroup контейнера. Для точных метрик на уровне контейнера читайте /sys/fs/cgroup/memory/memory.usage_in_bytes для текущего использования и /sys/fs/cgroup/memory/memory.limit_in_bytes для настроенного лимита. Либо используйте docker stats <container_name> с хоста для форматированного просмотра.