Мониторинг сервера: как следить за CPU, памятью и диском

Зачем вообще следить за нагрузкой сервера

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

Базовый мониторинг — это не сложная система с графиками и алертами, а привычка периодически (или по расписанию через cron) смотреть на несколько простых показателей: сколько занят процессор, сколько свободно памяти и диска, и не растёт ли какой-то из этих показателей быстрее, чем растёт реальная нагрузка от посетителей.

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

Load average: три числа, которые видно везде

Load average — это среднее число процессов, ожидающих или использующих процессор, усреднённое за последнюю минуту, 5 минут и 15 минут соответственно. Эти три числа видны в выводе команд uptime, top, htop и во многих других местах — это, пожалуй, самый быстрый способ понять общее состояние сервера одним взглядом.

uptime\n# 14:32:01 up 12 days,  3:47,  2 users,  load average: 0.52, 0.61, 0.58

Ключевой момент для интерпретации — load average нужно сравнивать с числом ядер процессора, а не с абстрактной шкалой. Значение 2.0 на сервере с 4 ядрами означает, что в среднем занята половина вычислительной мощности — это нормально. То же значение 2.0 на сервере с 1 ядром означает, что задачи уже выстраиваются в очередь, ожидая своей доли процессорного времени.

Число ядер можно посмотреть командой nproc или через содержимое /proc/cpuinfo. Если load average стабильно держится заметно выше числа ядер в часы пиковой посещаемости — это первый объективный сигнал, что текущей конфигурации процессора начинает не хватать.

nproc\n# 4

Разница между тремя значениями load average тоже несёт информацию. Если минутное значение заметно выше пятиминутного и пятнадцатиминутного, нагрузка выросла только что — возможно, это кратковременный всплеск от одного тяжёлого запроса или запущенного вручную скрипта, и стоит подождать несколько минут перед выводами. Если все три значения близки друг к другу и стабильно высоки, это уже не всплеск, а постоянный уровень нагрузки, с которым сервер живёт постоянно.

Важно понимать, что load average в Linux считает не только процессы, реально занимающие CPU, но и процессы в состоянии uninterruptible sleep — чаще всего это ожидание ответа от диска. Поэтому высокий load average при низкой видимой загрузке CPU в top почти всегда указывает на медленный диск или перегруженную дисковую подсистему, а не на нехватку вычислительной мощности процессора.

top и htop: что происходит на сервере прямо сейчас

Команда top встроена в любой дистрибутив Linux по умолчанию и показывает список процессов в реальном времени, отсортированный по потреблению CPU, с обновлением в несколько секунд. Верхняя часть вывода дублирует load average, общую загрузку CPU по типам (пользовательские процессы, системные вызовы, ожидание диска) и состояние памяти.

top

htop делает то же самое, но в более читаемом виде: цветные полосы загрузки по каждому ядру отдельно, постраничная прокрутка списка процессов мышью или стрелками, и удобные горячие клавиши — например, F6 или Shift+P для сортировки по CPU, Shift+M для сортировки по памяти, F9 для завершения выбранного процесса без набора отдельной команды kill.

apt install htop -y\nhtop

Практический сценарий использования обеих команд одинаков: сервер вдруг начал отвечать медленнее обычного — первым делом стоит открыть top или htop и посмотреть, какой конкретно процесс потребляет больше всего CPU или памяти прямо сейчас. Часто причина видна сразу: зависший процесс PHP-FPM, резервное копирование в неудачное время суток или неожиданно активный краулер поискового робота, создающий много параллельных запросов.

Если найденный процесс явно зависший и не отвечает, его можно завершить командой kill с указанием PID (виден в первой колонке top и htop), а если процесс важен, но временно создаёт слишком много нагрузки, можно снизить его приоритет командой renice, не останавливая работу полностью, — это позволяет остальным процессам на сервере получить больше процессорного времени, пока фоновая задача продолжает выполняться в менее приоритетном режиме.

kill -15 1234\nrenice 10 -p 1234

Память: free -h и разница между free и available

Команда free -h показывает состояние оперативной памяти в удобных единицах (гигабайты вместо байтов). Самая частая ошибка при чтении её вывода — пугаться маленького значения в колонке free и делать вывод, что памяти почти не осталось.

free -h\n#               total        used        free      shared  buff/cache   available\n# Mem:           7.8Gi       2.1Gi       0.3Gi       120Mi       5.4Gi       5.6Gi

Linux по умолчанию использует почти всю не занятую процессами память под файловый кэш — buff/cache в примере выше занимает 5.4 из 7.8 ГБ. Это не потерянная память: она мгновенно освобождается и отдаётся любому процессу, которому она реально понадобится, а до этого момента ускоряет повторные обращения к файлам на диске, которые уже читались раньше.

Реальный показатель свободной памяти, доступной для новых процессов, — колонка available, а не free. В примере выше available показывает 5.6 ГБ, что гораздо ближе к действительности, чем пугающие 0.3 ГБ в колонке free. Мониторить стоит именно available, и тревогу имеет смысл поднимать, когда это значение приближается к нулю, а не когда уменьшается free.

Строка Swap в том же выводе free -h показывает, сколько раздела подкачки используется прямо сейчас. Периодическое небольшое использование свопа обычно не страшно, но его стабильный и растущий рост — верный признак, что физической памяти уже не хватает, и система вынужденно выгружает часть данных процессов на диск, который на порядок медленнее оперативной памяти. Заметное падение отзывчивости сайта при одновременном росте использования swap — почти всегда сигнал к увеличению объёма RAM в конфигурации, а не к дальнейшей оптимизации кода.

Диск: df -h, du и что делать при переполнении

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

df -h\n# Filesystem      Size  Used Avail Use% Mounted on\n# /dev/vda1        40G   36G  2.1G  95% /

Когда конкретный раздел близок к 100%, следующий шаг — найти, что именно занимает больше всего места. Команда du с сортировкой по размеру directories первого уровня быстро находит основных «виновников».

du -h --max-depth=1 /var | sort -rh | head -10

Частые кандидаты на переполнение диска: логи, которые никогда не ротировались или не сжимались (особенно логи Nginx, Apache и самого приложения при высокой посещаемости), старые резервные копии, которые копятся в одной директории без автоматической очистки, и журналы систем управления версиями или Docker-образов, накапливающиеся при активной разработке.

Отдельный неочевидный случай — диск показывает почти полную занятость, а du не находит крупных файлов вообще. Это означает, что какой-то процесс продолжает писать в файл, который уже удалили командой rm, — операционная система физически не освобождает место, пока хотя бы один процесс держит файл открытым. Найти такие файлы помогает команда lsof, а решение — перезапустить процесс, всё ещё удерживающий удалённый файл.

lsof 2>/dev/null | grep deleted | awk '{print $1, $2, $10}'

Чтобы логи не накапливались бесконтрольно в принципе, в большинстве дистрибутивов уже настроен logrotate — он автоматически сжимает и удаляет старые файлы логов по расписанию. Стоит проверить конфигурацию конкретного приложения (например, самого веб-сервера или приложения на PHP) на предмет того, действительно ли logrotate охватывает его логи, а не только системные — многие приложения по умолчанию пишут логи в собственную директорию, о которой logrotate ничего не знает, пока не добавить для неё отдельное правило.

/var/log/myapp/*.log {\n  daily\n  rotate 14\n  compress\n  missingok\n  notifempty\n}

iostat, vmstat и ss: когда узкое место не в CPU и не в памяти

Иногда сервер тормозит при формально невысокой загрузке CPU и достаточном объёме свободной памяти — в таком случае стоит проверить дисковый ввод-вывод и сеть. Команда iostat (из пакета sysstat) показывает, насколько активно диск занят операциями чтения и записи и сколько времени процессы реально ждут ответа от диска.

apt install sysstat -y\niostat -x 2

Ключевая колонка в выводе iostat — %util, показывающая процент времени, когда диск был занят операциями ввода-вывода. Значение, стабильно близкое к 100%, при том что CPU и память свободны, обычно означает, что узкое место — именно диск, и решением может быть переход на более быстрый тип накопителя (например, с HDD или SATA SSD на NVMe) либо оптимизация запросов к базе данных, создающих избыточную нагрузку на диск.

Команда vmstat даёт похожую картину в компактном виде одной строкой на интервал — удобна для быстрого взгляда на CPU, память, своп и диск одновременно без переключения между несколькими инструментами.

vmstat 2 5

Для проверки сетевых соединений полезна команда ss — современная замена устаревшей netstat, показывающая список открытых соединений и слушающих портов. Она пригодится, если нужно быстро проверить, действительно ли сервис слушает ожидаемый порт, или сколько одновременных соединений держит база данных или веб-сервер прямо сейчас.

ss -tulnp\nss -s

Отдельный случай: мониторинг сервера с Docker-контейнерами

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

docker stats

Команда docker stats решает именно эту задачу — показывает использование CPU, памяти, сети и диска отдельной строкой на каждый работающий контейнер, обновляясь в реальном времени, аналогично top, но в разрезе контейнеров, а не системных процессов. Это особенно полезно, когда на одном сервере запущено несколько независимых сервисов в контейнерах и нужно быстро понять, какой из них создаёт основную нагрузку.

Для разового снимка без интерактивного режима подходит тот же docker stats с флагом --no-stream — удобно вызывать из cron-скрипта, если нужно логировать потребление ресурсов контейнерами на регулярной основе, не открывая интерактивную сессию вручную.

docker stats --no-stream --format "table {{.Name}}\t{{.CPUPerc}}\t{{.MemUsage}}"

Простое автоматическое оповещение без отдельной системы мониторинга

Для одного VPS полноценная система вроде Zabbix, Prometheus с Grafana или коммерческих SaaS-решений обычно избыточна — она требует времени на установку, отдельных ресурсов на работу самой системы мониторинга и постоянной поддержки. Для базовой потребности «сообщи мне, если что-то пошло не так» достаточно простого скрипта, запускаемого по cron.

#!/bin/bash\nDISK_USE=$(df / --output=pcent | tail -1 | tr -d ' %')\nif [ "$DISK_USE" -gt 85 ]; then\n  echo "Диск заполнен на ${DISK_USE}% на сервере $(hostname)" | mail -s "Внимание: мало места на диске" admin@example.ru\nfi

Такой скрипт стоит запускать по расписанию через cron — подробно о синтаксисе crontab и типичных ошибках при настройке рассказано в отдельной статье про задачи по расписанию в Linux.

Аналогичным образом можно добавить проверку load average и свободной памяти в тот же скрипт, чтобы получать одно письмо со всеми проблемами сразу, а не по отдельному скрипту на каждый показатель. Для проектов, где нужна визуализация истории нагрузки за недели и месяцы, а не только текущий момент, разумным промежуточным шагом (до полноценного Zabbix или Grafana) служит Netdata — устанавливается одной командой и сразу даёт веб-интерфейс с графиками по десяткам метрик без ручной настройки каждой из них.

bash <(curl -Ss https://my-netdata.io/kickstart.sh)

Чек-лист: на что смотреть в первую очередь

Шаг 1. uptime — быстрый взгляд на load average и сравнение с числом ядер (nproc), чтобы понять, насколько в целом загружен процессор.

Шаг 2. top или htop — если load average повышен, сразу видно, какой конкретно процесс создаёт нагрузку.

Шаг 3. free -h — проверка доступной памяти по колонке available, а не free.

Шаг 4. df -h — проверка занятости дисковых разделов, особенно корневого раздела /.

Шаг 5. Если CPU и память в порядке, а сервер всё равно медленный — iostat -x для проверки, не упирается ли всё в диск.

Шаг 6. Настройте простой cron-скрипт с отправкой письма при превышении пороговых значений по диску и памяти, чтобы узнавать о проблеме заранее, а не постфактум от расстроенных пользователей сайта.

Итог: мониторинг — это привычка, а не разовая настройка

Ни одна из рассмотренных команд не требует установки дополнительного софта (кроме htop, iostat и Netdata, которые ставятся одной командой) и не создаёт заметной нагрузки на сам сервер. Регулярная привычка проверять несколько базовых показателей за минуту экономит часы разбирательств в момент, когда сайт уже недоступен, а причина не очевидна.

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

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