Оперативная память под микроскопом: как не дать серверу задохнуться от нехватки ресурсов

Представьте себе город. Улицы — это шины данных, дома — процессы, а электричество — оперативная память. Пока энергии хватает, всё работает: свет горит, лифты ездят, холодильники морозят. Но стоит электростанции дать сбой или потребление резко вырасти — и начинается хаос. Свет гаснет, лифты застревают, продукты портятся. Так и с сервером: оперативная память (ОЗУ) — это его жизненная энергия. Без неё даже самый мощный процессор превращается в безмолвного гиганта, а сайты — в «белые экраны смерти».

В мире веб-хостинга, где каждый миллисекундный отклик влияет на доверие пользователей и позиции в поисковиках, контроль над памятью — не просто техническая задача, а вопрос выживания. Когда ОЗУ заканчивается, Linux не просто «отключает свет». Он включает аварийный генератор — своп (swap), то есть файл подкачки на жёстком диске. Но если ОЗУ — это скоростной лифт, то своп — это лестница в 20 этажей вверх с мешком картошки на плечах. Всё замедляется в десятки, а то и сотни раз. А если и своп заканчивается? Тогда ядро запускает OOM Killer (Out-Of-Memory Killer) — «палача», который без предупреждения убивает процессы, чтобы спасти систему от полного краха. И, увы, часто жертвой становится именно ваш веб-сервер или база данных.

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

Разбор по процессам: команда ps как хирургический скальпель

Если вы когда-нибудь наблюдали за работой хирурга, то знаете: он не просто «смотрит, что болит». Он точно знает, где находится каждый нерв, каждый сосуд, и действует с ювелирной точностью. Так и системный администратор, вооружённый командой ps, превращается в «хирурга памяти».

ps (от английского process status — «статус процесса») — это одна из самых старых, но оттого не менее мощных утилит в Linux. Она не показывает анимацию, не рисует графики, не шлёт уведомления. Она делает одно — и делает это идеально: выводит мгновенный снимок всех запущенных процессов и их потребления ресурсов.

Давайте начнём с самого простого:

ps aux

Эта команда — как рентген всего тела сервера. Буквы a, u и x — это флаги, которые расширяют вывод:

• a — показать процессы всех пользователей (а не только вашего).
• u — отобразить информацию в «человекочитаемом» формате (владелец, CPU, память и т.д.).
• x — включить процессы без управляющего терминала (например, демоны, такие как веб-серверы).

Результат — таблица, где каждая строка — это отдельный «житель» вашей системы. Среди множества колонок нас особенно интересуют те, что связаны с памятью:

• PID (Process ID) — уникальный номер процесса. Как паспортный номер у человека. Без него невозможно обратиться к конкретному «жителю».
• %MEM — процент от общей физической оперативной памяти, который использует этот процесс. Если у вас 8 ГБ ОЗУ, а процесс показывает 12.5%, значит, он занял ровно 1 ГБ.
• VSZ (Virtual Memory Size) — общий объём виртуальной памяти, выделенный процессу. Это не обязательно физическая память! Это может включать зарезервированное, но неиспользуемое пространство, отображённые файлы и даже участки, которые ещё не загружены в ОЗУ.
• RSS (Resident Set Size) — вот это уже «настоящая» память. То, что реально находится в оперативке прямо сейчас. Именно по RSS можно судить, сколько места процесс занимает «в железе».
• CMD — команда, с которой был запущен процесс. Например, /usr/sbin/nginx или /usr/bin/php-fpm.

Представим, что вы управляете хостингом для десятка сайтов на WordPress. Вдруг один из сайтов начинает грузиться по 10 секунд. Вы подозреваете, что какой-то PHP-процесс «съел» всю память. Вы запускаете ps aux | grep php и видите десятки строк. Одна из них выделяется:

www-data 788221  0.5 12.3 512000 102400 ?  S    10:23   0:15 php-fpm: pool www

Здесь PID — 788221, %MEM — 12.3%, RSS — 102400 килобайт, то есть 100 МБ. Если у вас 8 ГБ ОЗУ, это не критично. Но если таких процессов 50 — вы уже на грани.

Чтобы получить точные данные только по этому процессу, используйте:

ps -p 788221 -o pid,vsz,rss,%mem,cmd

Флаг -p указывает PID, а -o задаёт, какие колонки выводить. Результат:

  PID     VSZ   RSS %MEM CMD
788221 512000 102400 12.3 php-fpm: pool www

Теперь вы точно знаете: процесс использует 100 МБ физической памяти. Это может быть нормально для тяжёлого WordPress-сайта с кучей плагинов. Но если RSS растёт со временем — это признак утечки памяти: скрипт что-то загружает в память и не освобождает её.

Команда ps особенно ценна тем, что её легко встроить в автоматизацию. Например, скрипт может каждые 5 минут проверять, нет ли процессов с RSS выше 500 МБ, и отправлять вам уведомление. Это как установить датчики дыма в каждом доме города — вы узнаете о пожаре до того, как он охватит весь квартал.

Живая картина нагрузки: top и htop в бою

Если ps — это рентгеновский снимок, то top — это видеонаблюдение в реальном времени. Эта команда, существующая с 1980-х годов, до сих пор остаётся одним из самых популярных инструментов мониторинга в мире Unix-систем.

Запустите её просто:

top

Перед вами откроется динамически обновляемый экран, разделённый на две части. В верхней — сводка по всей системе. В нижней — список процессов, отсортированных по загрузке CPU (по умолчанию).

Верхняя часть особенно важна для анализа памяти. Обратите внимание на строки, начинающиеся с Mem: и Swap:. Пример:

Mem: 8123456K total, 6500000K used, 1623456K free, 500000K buffers, 2000000K cached
Swap: 2097148K total, 0K used, 2097148K free

Здесь:

• total — общая физическая память (примерно 8 ГБ).
• used — сколько занято процессами.
• free — сколько абсолютно свободно.
• buffers — память, используемая для буферизации операций ввода-вывода (например, записи на диск).
• cached — память, используемая для кэширования файлов (чтобы часто читаемые файлы не грузить с диска каждый раз).

Важно понимать: Linux старается использовать всю доступную память. Свободная память — это «потерянная» память. Поэтому даже если free близок к нулю, это не обязательно плохо — главное, чтобы used не рос за счёт реальных процессов, а cached и buffers могли быть освобождены при необходимости.

Теперь перейдём к списку процессов. Ключевые колонки для памяти:

• VIRT — виртуальная память (аналог VSZ). Может включать своп, отображённые файлы, зарезервированную, но неиспользуемую память.
• RES — резидентная память (аналог RSS). То, что реально в ОЗУ.
• %MEM — процент от общей физической памяти.

Пример строки:

788221 www-data  20   0  500m  100m  10m S  0.3  1.2   0:15.22 php-fpm

Здесь RES = 100 МБ, %MEM = 1.2% (при 8 ГБ ОЗУ). Всё в порядке. Но если вы видите, что RES у одного процесса растёт каждую секунду — это тревога.

Чтобы наблюдать только за конкретным процессом, используйте:

top -p 788221

Это особенно полезно при отладке: вы видите, как именно ведёт себя процесс в реальном времени.

htop: когда мониторинг становится искусством

Но настоящая революция в мире мониторинга произошла с появлением htop. Это не просто улучшенная версия top — это переосмысление самого подхода к наблюдению за системой.

Во-первых, htop использует цвета. Зелёный — CPU, синий — память, красный — своп. Вы сразу видите, где «горячо».

Во-вторых, он показывает графические индикаторы в верхней части экрана — как на приборной панели самолёта. Вы не читаете цифры — вы чувствуете нагрузку.

В-третьих, интерфейс интерактивен:

• Нажмите F6, чтобы отсортировать процессы по памяти, CPU или другому параметру.
• Нажмите F3, чтобы найти процесс по имени (например, «mysql»).
• Нажмите F9, чтобы убить процесс — без необходимости вводить kill вручную.
• Прокручивайте список колёсиком мыши — да, в терминале!

Установка htop проста:

# На Ubuntu или Debian
sudo apt update && sudo apt install htop

# На CentOS, Rocky Linux или AlmaLinux
sudo dnf install htop
# или (в старых версиях)
sudo yum install htop

После запуска вы увидите нечто, напоминающее дашборд из научно-фантастического фильма. И это не просто красиво — это функционально. Вы мгновенно замечаете аномалии: например, процесс mysqld внезапно занял 40% памяти. Вы нажимаете Enter на нём — и видите полную команду запуска, владельца, время работы.

Для администратора, управляющего хостингом, htop — это как диспетчерская вышка в аэропорту. Вы видите всё: кто взлетает, кто заходит на посадку, кто завис в воздухе. И можете вмешаться в любой момент.

Внутренний мир процесса: анализ через /proc

Linux — страна, где всё является файлом. Даже процессы. Даже память. Даже информация о ядре. Всё это хранится в особой виртуальной файловой системе под названием /proc.

Это не настоящая файловая система на диске. Она существует только в памяти и создаётся ядром «на лету». Когда вы читаете файл в /proc, вы не получаете данные с диска — вы получаете ответ от ядра операционной системы.

Каждый запущенный процесс имеет свою папку в /proc, названную по его PID. Например, процесс с PID 788221 будет иметь папку /proc/788221/. Внутри — десятки файлов, каждый из которых рассказывает о чём-то своём: открытые файлы, сетевые соединения, переменные окружения, и, конечно, память.

Самый важный файл для нас — /proc/[PID]/status. Он содержит читаемую человеком информацию о процессе. Чтобы извлечь только данные о памяти, выполните:

cat /proc/788221/status | grep -i vm

Флаг -i делает поиск нечувствительным к регистру, так как в разных версиях Linux поля могут быть в разном регистре.

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

VmSize:   512000 kB
VmRSS:    102400 kB
VmData:   300000 kB
VmStk:       136 kB
VmExe:      1024 kB
VmLib:     12288 kB
VmPTE:       256 kB
VmSwap:        0 kB

Разберём каждую строку:

• VmSize — общий объём виртуального адресного пространства процесса. Это то, что видит сам процесс. Может быть огромным, даже если физически используется мало.
• VmRSS — резидентная память. То, что реально загружено в ОЗУ. Это главный показатель «тяжести» процесса.
• VmData — память, выделенная под данные (глобальные переменные, динамически выделенная память через malloc и т.д.).
• VmStk — стек (память под локальные переменные и вызовы функций). Обычно небольшой.
• VmExe — память под исполняемый код программы.
• VmLib — память, занятая подключёнными библиотеками (например, libc).
• VmPTE — память под таблицы страниц (Page Table Entries) — структуры, которые связывают виртуальные адреса с физическими.
• VmSwap — сколько памяти этого процесса было выгружено в своп. Если это число растёт — система испытывает нехватку ОЗУ.

Почему это важно? Потому что /proc — это источник истины. Другие утилиты (ps, top) просто читают эти файлы и красиво оформляют вывод. Но если вы хотите написать скрипт, который будет точно знать, сколько памяти использует процесс, — читайте /proc напрямую.

Пример скрипта для мониторинга:

#!/bin/bash
# Скрипт: memory_alert.sh
PID=788221
THRESHOLD_KB=512000  # 500 МБ

if [ ! -d "/proc/$PID" ]; then
  echo "Процесс с PID $PID не существует."
  exit 1
fi

RSS_KB=$(grep VmRSS /proc/$PID/status | awk '{print $2}')

if [ "$RSS_KB" -gt "$THRESHOLD_KB" ]; then
  echo "$(date): ВНИМАНИЕ! Процесс $PID использует ${RSS_KB} КБ памяти (более 500 МБ)!" >> /var/log/memory_alerts.log
  # Отправка email или уведомления в Telegram можно добавить здесь
fi

Такой скрипт можно запускать каждые 30 секунд через cron:

*/1 * * * * /path/to/memory_alert.sh

Теперь вы не просто реагируете на падение сайта — вы получаете предупреждение за час до катастрофы. Это и есть проактивное управление.

Общая картина: как оценить состояние всей системы

Иногда важно отвлечься от отдельных «деревьев» и посмотреть на «лес». Каково общее состояние памяти на сервере? Хватает ли ресурсов? Насколько близка система к пределу? Для этого существуют инструменты глобального анализа.

free -h: мгновенная диагностика за 2 секунды

Это, пожалуй, самая часто используемая команда для проверки памяти. Она проста, быстра и информативна.

free -h

Флаг -h означает «human-readable» — вывод в удобных единицах (МБ, ГБ), а не в килобайтах.

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

               total    used    free  shared  buff/cache   available
Mem:            7.7G    3.2G    1.1G    200M        3.4G        4.1G
Swap:           2.0G      0B    2.0G

Разберём каждую колонку:

• total — общая физическая память.
• used — память, занятая процессами.
• free — абсолютно неиспользуемая память. В здоровой системе она почти всегда мала — Linux использует «лишнюю» память для кэша.
• shared — память, используемая tmpfs или разделяемая между процессами (например, через shared memory).
• buff/cache — сумма буферов и кэша. Эту память можно освободить мгновенно, если понадобится новому процессу.
• available — самое важное число! Это оценка того, сколько памяти реально доступно для запуска новых приложений без использования свопа. Именно по этому значению нужно судить, «хватает ли памяти».

Если available падает ниже 10–15% от total — пора принимать меры. Особенно если Swap used начинает расти.

vmstat -s: вскрытие показало — детальная статистика

Команда vmstat (virtual memory statistics) — это как вскрытие тела системы. Она показывает не только память, но и активность диска, переключения контекста, прерывания и многое другое.

Флаг -s выводит статистику в виде списка:

vmstat -s

Вывод может содержать сотни строк. Вот наиболее важные для памяти:

     8123456 K total memory
      6500000 K used memory
      1623456 K free memory
      4000000 K buffer memory
      2500000 K swap cache
      2097148 K total swap
            0 K used swap
      1234567 K active memory
      2345678 K inactive memory

 

Здесь:

• active memory — память, которая активно используется и вряд ли будет освобождена.
• inactive memory — память, которая не использовалась давно и может быть освобождена при необходимости (например, кэш старых файлов).

Этот инструмент особенно полезен при глубоком анализе: например, если вы подозреваете, что система «теряет» память, или хотите понять, почему available в free не совпадает с вашими расчётами.

sar -r: историческая перспектива и прогнозирование

Если вы управляете хостингом, важно не только знать текущее состояние, но и видеть динамику. Как менялась память вчера в 3 ночи? Почему сегодня утром сайт упал?

Для этого существует sar (System Activity Reporter) — часть пакета sysstat. Он собирает статистику по расписанию и сохраняет её в логах.

Установка:

# Ubuntu/Debian
sudo apt install sysstat
sudo sed -i 's/ENABLED="false"/ENABLED="true"/' /etc/default/sysstat
sudo systemctl enable --now sysstat

# CentOS/RHEL
sudo dnf install sysstat
sudo systemctl enable --now sysstat

Теперь вы можете собирать данные в реальном времени:

sar -r 1 10

Эта команда каждую секунду (1) в течение 10 секунд (10) покажет использование памяти. Пример строки:

12:05:01 PM kbmemfree kbmemused %memused kbbuffers kbcached kbcommit %commit kbactive kbinact
12:05:02 PM   1123456   7000000    86.12    123456   3456789   8000000    98.00   4000000  2000000

А ещё вы можете посмотреть исторические данные:

sar -r -f /var/log/sysstat/sa13  # данные за 13-е число месяца

Это позволяет строить графики, находить пики нагрузки, коррелировать их с действиями пользователей или обновлениями ПО. Вы не гадаете — вы анализируете.

Заключение: память — не ресурс, а ответственность

Оперативная память — это не просто цифры в терминале. Это дыхание вашего сервера. Каждый байт — это возможность ответить пользователю быстрее, обработать заказ раньше, сохранить доверие клиента.

Мы прошли путь от простого ps aux до глубокого анализа через /proc и исторического мониторинга через sar. Мы узнали, что:

• VSZ и VIRT — это виртуальная память, которая может быть больше физической и не всегда отражает реальную нагрузку.
• RSS и RES — это «настоящая» память, которую нужно контролировать в первую очередь.
• Своп — не враг, но и не друг. Его использование — признак нехватки ОЗУ, но полное его отсутствие может быть опасно (лучше иметь небольшой своп как «подушку безопасности»).
• Free ≠ available. Свободная память — это не то, что доступно. Доступна та память, которую система может выделить новому процессу, включая кэш.
• Мониторинг — это не разовое действие, а процесс. Лучше получать уведомления за час до падения, чем восстанавливать сайт после.

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

1. Оптимизированы ли мои приложения? Может, WordPress использует 20 плагинов, из которых 15 — бесполезны?
2. Правильно ли настроен веб-сервер? Например, в Apache параметр MaxRequestWorkers не должен превышать лимит, при котором все процессы вместе не превысят объём ОЗУ.
3. Есть ли утечки памяти? PHP-скрипты, которые в цикле создают объекты без освобождения, могут со временем «съесть» всю память.
4. Не пора ли перейти на более эффективные технологии? Nginx потребляет меньше памяти, чем Apache. PHP-FPM эффективнее mod_php. MariaDB может быть легче MySQL в некоторых сценариях.
5. Использую ли я кэширование? OPcache для PHP, Redis или Memcached для данных — всё это снижает нагрузку на память и CPU.

И помните: даже самый мощный сервер — это не волшебная шкатулка. Он требует внимания, понимания и уважения. А оперативная память — это не просто ресурс, который можно «докупить». Это ответственность перед каждым пользователем, который зашёл на ваш сайт и ждёт быстрого ответа.

Теперь, вооружённые знаниями, инструментами и стратегиями, вы не просто администратор. Вы — страж порядка в цифровом городе, где каждый байт на своём месте, и ни один процесс не остаётся без присмотра.