Команди та інструменти для перевірки споживання 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 завищує використання майже вдвічі в цьому сценарії. При прийнятті рішень про масштабування на Виділеному сервері, використання PSS з smem дає вам достовірні дані.

Перевірка RAM за допомогою vmstat

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

vmstat 2 10    # Report every 2 seconds, 10 times

Ключові стовпці пам’яті

Критичний сигнал: Ненульові значення si (swap-in) і so (swap-out) у запущеному потоці 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 означає, що ядро почне свопінг, коли RAM буде використана на 40%. Для серверів баз даних (MySQL, PostgreSQL, Redis) встановлення цього значення на 10 зберігає дані в RAM значно довше, що різко знижує затримку введення/виведення. Для настільних систем або систем з обмеженою RAM значення за замовчуванням є більш відповідним.

Поширені помилки та неправильні інтерпретації

Помилка 1: Паніка через низьку «вільну» пам’ять

Як пояснювалося раніше, Linux навмисно використовує вільну RAM як кеш. Система з 200 МБ вільної пам’яті, але 8 ГБ доступної — здорова. Завжди читайте стовпець Available.

Помилка 2: Підсумовування RSS для оцінки загального використання пам’яті

Підсумовування значень ps RSS по всіх процесах зазвичай перевищить загальну фізичну 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 Хостингу також відстежуйте GPU VRAM поряд із системною RAM — nvidia-smi --query-gpu=memory.used,memory.free --format=csv надає еквівалентні метрики для пам’яті GPU.

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

Матриця технічних рішень: який інструмент використовувати і коли

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

• Завжди перевіряйте Available пам’ять з 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> з хоста для форматованого перегляду.