Как найти процесс, который нагружает Linux-сервер

Высокая нагрузка — симптом, а не диагноз. Один процесс может действительно занимать CPU, ждать диск, удерживать память или лишь оказаться рядом по времени. Задача администратора — зафиксировать состояние, найти конкретный PID и проверить гипотезу до остановки.

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

Что такое процесс

Процесс — запущенный экземпляр программы со своим PID, владельцем, памятью, открытыми файлами и состоянием. Родительский PID помогает восстановить цепочку запуска.

Получите понятный снимок:

ps -eo pid,ppid,user,stat,etimes,pcpu,pmem,comm,args --sort=-pcpu | head -n 20

ps показывает состояние в момент запуска команды. top обновляет картину периодически. Не путайте имя исполняемого файла comm с полной командной строкой args; последняя иногда содержит чувствительные значения, поэтому не публикуйте её без проверки.

Зафиксируйте общий симптом

date --iso-8601=seconds
uptime
nproc
free -h
df -h

uptime показывает load average за несколько интервалов, но не процент CPU. Значение интерпретируют относительно числа доступных логических процессоров и состояний задач. Рост нагрузки при свободном CPU может указывать на ожидание ввода-вывода.

free показывает память системы. Смотрите прежде всего на доступную память, а не пытайтесь освободить весь cache: Linux использует свободную RAM для ускорения файловых операций и способен перераспределить её.

Проверка df нужна потому, что заполненный диск вызывает зависание записи, сбои журналов и повторные попытки приложения. Если свободного места мало, сначала определите проблемную точку монтирования по диагностике дисков и файловых систем.

Найдите процесс по CPU или памяти

ps -eo pid,user,stat,pcpu,pmem,rss,etimes,comm --sort=-pcpu | head
ps -eo pid,user,stat,pcpu,pmem,rss,etimes,comm --sort=-rss | head

RSS — объём резидентной памяти процесса, но сумма RSS по процессам может учитывать общие страницы несколько раз. pmem — относительный ориентир, не точный ответ о всей памяти приложения.

Откройте динамический просмотр:

top

В top обычно можно сортировать по CPU или памяти и отфильтровать пользователя. Смотрите несколько обновлений: краткий всплеск во время сборки не равен постоянной утечке.

Прочитайте состояние процесса

Основные коды в STAT:

• R — выполняется или готов выполняться;
• S — прерываемое ожидание события;
• D — непрерываемое ожидание, часто I/O;
• T — остановлен сигналом или отладчиком;
• Z — завершён, но родитель ещё не забрал статус.

Zombie почти не потребляет CPU и память; устранять нужно поведение родителя, а не пытаться «убить» уже завершённый процесс. Большое число D вместе с ростом load требует проверки диска, сети хранения или ядра.

Посмотрите дерево:

ps -eo pid,ppid,user,stat,comm --forest

Если дочерние процессы постоянно появляются заново, ими может управлять systemd, контейнер или supervisor. Ручной kill не изменит политику перезапуска.

Свяжите PID со службой и журналом

systemctl status nginx --no-pager
systemctl show nginx -p MainPID -p ActiveState -p SubState
journalctl -u nginx --since "15 minutes ago" --no-pager

Замените nginx на нужный unit. Сверьте время роста нагрузки с сообщениями, deploy и внешними событиями. Один высокий PID не доказывает ошибку приложения: процесс мог обрабатывать законный пик трафика.

Для неизвестного PID полезны:

ps -p 1234 -o pid,ppid,user,lstart,stat,pcpu,pmem,comm,args
readlink -f /proc/1234/exe
ls -l /proc/1234/fd | head

Подставьте фактический PID. Доступ к /proc зависит от владельца и системных ограничений. Вывод дескрипторов и командной строки может раскрыть пути или секреты — храните диагностику закрыто.

Сигналы и корректная остановка

Сигнал — это стандартное сообщение процессу от ядра или другой программы. Посмотреть доступные имена и номера можно без отправки сигнала:

kill -l

По умолчанию kill отправляет SIGTERM: просьбу корректно завершиться. Для конкретного процесса с PID 1234 последовательность выглядит так:

kill -TERM 1234
ps -p 1234 -o pid,stat,comm

Дайте приложению разумное время завершить запросы и закрыть ресурсы. Если это systemd-служба, правильнее:

sudo systemctl stop example.service
systemctl status example.service --no-pager

SIGKILL прекращает выполнение без обработчика. Он может оставить незавершённую транзакцию, временный файл или внешнюю блокировку. Применяйте его лишь после фиксации состояния и не используйте широкие шаблоны pkill по имени без проверки списка целей.

Разберите CPU, память и I/O отдельно

Для CPU проверьте устойчивую загрузку процесса и число ядер. Для памяти сравните RSS, доступную память, swap и события OOM в журнале. Для I/O ищите процессы в D, рост ожидания и заполнение диска. Если установлены дополнительные утилиты мониторинга, используйте их как подтверждение, но не устанавливайте пакет во время аварии без необходимости.

События нехватки памяти:

journalctl -k --since today | grep -Ei 'out of memory|oom-kill|killed process'

Отсутствие строки не исключает проблему вне выбранного интервала. Не «лечите» утечку бесконечным увеличением swap: сначала установите процесс, момент начала и изменение после релиза.

Проверка исправления и откат

После перезапуска или изменения конфигурации повторите тот же набор измерений через одинаковый интервал. Проверьте прикладной результат: HTTP-ответ, очередь задач или время выполнения запроса. Падение CPU без работающего сервиса — не исправление.

Если причина появилась после deploy, безопасный откат — вернуть предыдущий проверенный релиз и снова измерить. Если менялся лимит systemd, восстановите старый unit, выполните daemon-reload, перезапустите службу и подтвердите состояние по журналу.

Если процесс запущен как служба, сопоставьте его состояние с параметрами systemd и событиями в journalctl.

Первоисточники

• Linux manual page: ps — выбор процессов, форматы вывода и коды состояний.
• Linux manual page: kill — отправка сигналов процессам и сигнал по умолчанию.