Как узнать, кто нагружает сервер

MAATRIX

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

С чего начать: общая картина нагрузки

Прежде чем искать конкретный процесс, посмотрите на сервер в целом. Первая команда — uptime: она показывает load average, среднюю нагрузку за 1, 5 и 15 минут. Если эти числа заметно превышают количество ядер вашего сервера, система перегружена и процессы стоят в очереди.

uptime
top

top — базовый инструмент, который показывает процессы, отсортированные по нагрузке. Обратите внимание на строку с общей статистикой: сколько процессора занято пользовательскими процессами (us), системными (sy) и сколько уходит на ожидание диска (wa). Высокий wa — сигнал, что упирается не процессор, а диск. Удобнее пользоваться htop, если он установлен: там нагрузка по ядрам показана наглядными полосками, а процессы можно сортировать и убивать прямо из интерфейса.

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

Кто ест процессор

Если load average высокий, а в строке wa значение небольшое, дело в процессоре. Отсортируйте процессы по загрузке CPU и посмотрите на верхушку:

ps aux --sort=-%cpu | head -n 10

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

Если виновник — веб-сервер или интерпретатор, копайте глубже: возможно, конкретный запрос или страница запускают тяжёлую логику. Загляните в логи доступа и найдите, какие URL обрабатываются в момент пика. Часто оказывается, что нагрузку создаёт бот, который долбит тяжёлый эндпоинт, или один медленный запрос к базе, повторяющийся сотни раз.

Полезно понимать разницу между процессом, который стабильно занимает ядро, и процессом, который вспыхивает на секунды. Первый вы поймаете сразу, второй — только если смотреть в динамике. Если в топе мелькает какой-то процесс, но не задерживается, запустите наблюдение на минуту-другую и последите, повторяется ли всплеск с определённой периодичностью. Периодические пики раз в пять или пятнадцать минут почти всегда указывают на крон-задачу: посмотрите содержимое crontab -l для нужных пользователей и системные задания в каталоге cron. Нередко виновником оказывается забытый скрипт, который кто-то поставил на регулярный запуск и не убрал, или задача, которая раньше отрабатывала за секунды, а теперь на разросшихся данных грузит сервер по несколько минут.

Отдельно стоит проверить, не размножились ли процессы. Бывает, что нагрузку создаёт не один прожорливый процесс, а десятки лёгких копий одного и того же — например, зависшие обработчики, которые не завершились и продолжают висеть. Команда с группировкой по имени быстро это показывает: если вы видите сотню процессов PHP-FPM или питоновских воркеров там, где ожидали десяток, значит где-то не отрабатывает завершение, и пул раздувается. Такое лечится корректной настройкой лимитов и таймаутов, а не наращиванием мощности.

Кто ест память

Нехватка памяти проявляется иначе: сервер начинает свопить, всё замедляется, а в критических случаях система убивает процессы через OOM-killer. Сначала оцените общую картину:

free -h
ps aux --sort=-%mem | head -n 10

free -h покажет, сколько памяти занято, свободно и ушло в своп. Если своп активно используется, а свободной памяти почти нет — вы нашли причину тормозов. Вторая команда выведет процессы, отсортированные по потреблению RAM. Типичные пожиратели памяти — базы данных с неудачным конфигом, приложения с утечками, слишком много воркеров веб-сервера. Проверьте, не убивал ли OOM-killer процессы: следы этого видны в системном журнале командой dmesg | grep -i oom или в journalctl -k.

Кто грузит диск и сеть

Если в top высокое значение wa, узкое место — диск. Найти процесс, который активно читает или пишет, поможет iotop (ставится отдельно):

iotop -o

Ключ -o показывает только процессы, реально работающие с диском в данный момент. Частые виновники — резервное копирование, запущенное в рабочее время, ротация логов, тяжёлые запросы к базе, которая не помещается в память и постоянно читает с диска. Заодно проверьте, не забит ли диск: переполненный раздел сам по себе валит сервисы. Команда df -h покажет занятость разделов, а du -sh /var/* | sort -h поможет найти, какая директория раздулась.

Сетевую нагрузку смотрите через iftop или nload: они показывают, сколько трафика идёт через интерфейс и с какими адресами. Всплеск исходящего трафика может означать, что сервер рассылает спам после взлома или его используют как прокси, а входящего — что идёт атака или наплыв ботов.

Разовый всплеск или постоянная нагрузка

Важно понять характер проблемы. Разовый всплеск — например, во время бэкапа или деплоя — это норма, если он проходит сам. Постоянная высокая нагрузка означает, что либо сервер перерос свой тариф, либо в системе что-то работает неправильно. Чтобы отличить одно от другого, не гадайте по одному замеру, а посмотрите на динамику. Установите лёгкий мониторинг, который пишет историю нагрузки, — например, netdata или простую связку из cron и логирования вывода top. Так вы увидите, когда именно случаются пики и совпадают ли они с крон-задачами, наплывом трафика или бэкапами.

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

Профилактика: чтобы не искать в панике

Несколько привычек экономят часы разбирательств. Держите на сервере установленными htop, iotop и iftop, чтобы в момент проблемы не тратить время на их установку. Настройте базовый мониторинг с историей метрик и оповещением при перегрузке. Разнесите тяжёлые крон-задачи по времени, чтобы бэкап, ротация логов и обновления не запускались одновременно. Ограничьте число воркеров веб-сервера и подключений к базе разумными значениями под ваш объём памяти. И ведите привычку заглядывать в логи при первых признаках замедления, а не когда сайт уже лёг — ранняя реакция почти всегда дешевле.

Частые вопросы