Сервер Linux грузит CPU или память: как найти причину

Короткий ответ

Порядок диагностики:

1. top или htop — кто именно потребляет CPU и память прямо сейчас.
2. vmstat 1 — что ограничивает систему: процессор, память или ввод-вывод.
3. iostat -x 1 — не упирается ли всё в диск.
4. free -h и dmesg — сколько реально свободной памяти и не убивал ли ядро процессы.
5. ps — история и детали конкретного процесса.

vmstat и iostat обычно входят в пакеты procps и sysstat.

Как читать load average

В выводе top или uptime есть три числа — средняя нагрузка за 1, 5 и 15 минут. Это количество процессов, которые выполняются или ждут выполнения. В Linux сюда же входят процессы, ожидающие диска (состояние D).

• Сравнивайте load average с числом ядер (nproc). На 4 ядрах значение около 4 означает полную загрузку, заметно выше — очередь.
• Если load высокий, а CPU почти свободен — ищите проблему в диске или сети, а не в процессоре.
• Рост первого числа при спокойных остальных — свежий всплеск, а не хроническая проблема.

Шаг 1. top и htop

В top нажмите P, чтобы сортировать по CPU, и M — по памяти. В htop то же делается кликом по столбцу или клавишей F6.

Смотрите на строку %Cpu(s):

Высокий st на виртуалке не лечится внутри системы — это вопрос к хостингу или тарифу.

Шаг 2. vmstat и iostat

vmstat 1 5

• Столбец r — очередь на процессор. Стабильно больше числа ядер — CPU не хватает.
• b — процессы, заблокированные на вводе-выводе.
• si и so — подкачка из swap и в swap. Постоянные ненулевые значения — памяти мало.

iostat -x 1 5

Высокий %util и большой await у диска означают, что он не успевает. Тогда ищите, кто пишет: iotop покажет процессы по объёму ввода-вывода.

Шаг 3. Память: free, swap и OOM killer

free -h

Главное — столбец available, а не free. Linux занимает свободную память под кэш файлов (buff/cache) и отдаёт её приложениям по требованию, поэтому маленький free — норма.

Swap — запасная память на диске. Немного занятого swap не страшно. Плохо, когда идёт постоянный обмен (si/so в vmstat): система начинает тормозить.

Когда память и swap заканчиваются, ядро запускает OOM killer и убивает процесс с наибольшим «весом». Проверьте:

dmesg -T | grep -i -E "killed process|out of memory"
journalctl -k | grep -i oom

Если приложение «само перезапускается» без ошибок в своих логах — часто это именно OOM killer.

Шаг 4. ps: детали процесса

ps aux --sort=-%cpu | head -n 10
ps aux --sort=-rss  | head -n 10
ps -o pid,etime,rss,cmd -p 1234

RSS — реальная занимаемая память, etime — сколько процесс уже работает. Если RSS одного процесса со временем только растёт, это признак утечки.

Что делать с процессом-беглецом

1. Определите, что это: ps -fp PID, ls -l /proc/PID/exe, к какому сервису относится (systemctl status PID).
2. Соберите данные до перезапуска: логи приложения, journalctl -u сервис, время начала проблемы. После рестарта улики пропадут.
3. Снизьте приоритет, если процесс нужен, но мешает: renice +10 -p PID.
4. Остановите корректно: сначала kill PID (SIGTERM), и только если не помогает — kill -9 PID.
5. Если это cron-задача или неизвестный процесс — проверьте, откуда он запущен. Неожиданный процесс с высоким CPU может оказаться майнером после взлома.

Утечка памяти: пошагово

1. Подтвердите рост: записывайте RSS процесса с интервалом (ps в цикле или мониторинг).
2. Свяжите рост с событиями: деплой, конкретный маршрут, фоновая задача.
3. Ограничьте ущерб: лимит памяти через systemd (MemoryMax=) или Docker (mem_limit), чтобы падал только этот сервис, а не весь сервер.
4. Как временная мера — плановый перезапуск, но это не решение.
5. Ищите причину профилировщиком вашего языка: растущие кэши без лимита, незакрытые соединения, подписчики событий, которые никто не удаляет.