Высокая загрузка CPU в Linux: быстрое диагностирование и решение

Введение / Зачем это нужно

Высокая загрузка процессора (CPU) в Linux — частая проблема, которая приводит к замедлению работы системы, «зависаниям» приложений и перегреву оборудования. Эта инструкция поможет вам системно диагностировать причину: от быстрого поиска «критичного» процесса до углублённого анализа системных вызовов и прерываний. Вы получите чёткий алгоритм действий, работающий на большинстве дистрибутивов (Ubuntu, CentOS, Debian).

Требования / Подготовка

Перед началом убедитесь, что:

1. У вас есть доступ к терминалу с правами sudo (некоторые команды требуют их).
2. Система подключена к интернету для установки утилит (если они отсутствуют).
3. Вы понимаете базовые команды Linux (cd, grep, kill).

Шаг 1: Быстрая оценка ситуации через top

Стандартная утилита top даёт первичную картину:

top

• Нажмите 1 — увидите загрузку каждого ядра CPU.
• Сортируйте по %CPU (клавиша P).
• Обратите внимание на:
  • %CPU — процент использования CPU процессом.
  • RES — потребляемая оперативная память (в KB).
  • TIME+ — общее время, потраченное процессом на CPU.
  • Состояние (S): R (running), D (uninterruptible sleep), Z (zombie).

Ключевой признак: Если load average (вверху) значительно превышает количество ядер CPU (например, 8.0 на 4-ядерном сервере) — система перегружена.

Шаг 2: Углублённый анализ с htop

htop — более удобная альтернатива top с цветовой индикацией и интерактивным интерфейсом.

Установка (если нет):

sudo apt update && sudo apt install htop   # Для Debian/Ubuntu
sudo yum install htop                      # Для CentOS/RHEL

Запустите:

htop

Что делать в htop:

• Нажмите F5 — дерево процессов (видно родительские связи).
• Нажмите F6 — сортировка, выберите PERCENT_CPU.
• Нажмите F9 → kill → выберите сигнал (обычно SIGTERM 15) для мягкого завершения проблемного процесса.

⚠️ Важно: Убедитесь, что завершаете именно тот процесс. Не убивайте системные демоны (например, systemd, kthreadd).

Шаг 3: Поиск «тяжёлых» процессов через ps

Для скриптового анализа или быстрого вывода топ-процессов в терминале:

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

• aux — все процессы всех пользователей.
• --sort=-%cpu — сортировка по убыванию CPU.
• head -10 — первые 10 строк.

На что смотреть:

• Процессы с %CPU > 100% — это многопоточные (например, java, chrome). Учитывайте, что 100% = одно ядро.
• Процессы в состоянии D — ждут I/O (диск/сеть). Их высокий %CPU может быть артефактом.

Шаг 4: Анализ активности процесса с perf

Если обычные утилиты не показывают, что именно внутри процесса нагружает CPU (например, Java-приложение или компиляция), используйте perf.

Установка:

sudo apt install linux-tools-common linux-tools-generic   # Ubuntu/Debian
sudo yum install perf                                     # CentOS/RHEL

Профилирование в реальном времени:

perf top -p <PID>

Где <PID> — идентификатор процесса (из top/htop). Вы увидите «горячие» функции (symbols) внутри процесса. Для записи отчёта:

perf record -F 99 -p <PID> -g -- sleep 30
perf report

Это покажет call-graph — стек вызовов, ведущих к нагрузке.

Шаг 5: Отслеживание системных вызовов через strace

Если процесс «завис» в состоянии D ( uninterruptible sleep, обычно I/O), strace поможет увидеть, какой системный вызов его блокирует.

strace -p <PID> -e trace=read,write,open,close,select,epoll_wait -s 128 -T

• -e trace= — фильтр по вызовам (здесь: файловые и сетевые операции).
• -s 128 — длина выводимых строк.
• -T — время каждого вызова.

Типичные выводы:

• Много вызовов read/write на медленном диске → проблема с I/O подсистемы.
• Блокировка в select/epoll_wait → ожидание сетевого ответа.

Шаг 6: Проверка активности прерываний (IRQ)

Иногда высокая нагрузка создаётся не пользовательскими процессами, а обработкой прерываний оборудования (сетевые карты, диски, таймеры).

Посмотрите общую статистику:

cat /proc/interrupts

• Первый столбец — количество прерываний с загрузки системы.
• Сравните значения для разных IRQ. Резкий рост у одного устройства (например, eth0 или nvme) может указывать на сбойный драйвер или «флуд» пакетов.

Дополнительно:

mpstat -P ALL 1 5   # Показывает %usage ядер, включая softirq (si) и irq (hi)

Если %si/%hi высоки — оптимизируйте обработку прерываний (настройка irqbalance, обновление драйверов).

Проверка результата

После каждого шага оцените:

1. load average в top — должен снижаться до уровня, близкого к числу ядер.
2. Отсутствие процессов с аномально высоким %CPU (>90% на ядро в течение минуты).
3. Отзывчивость системы (например, ping 8.8.8.8 без потерь, быстрый отклик shell).

Если проблема осталась, повторите диагностику, зафиксировав состояние:

# Сделайте снимок процессов
ps aux > ~/process_snapshot_$(date +%s).txt
# И загрузите его для дальнейшего анализа

Возможные проблемы

Проблема: perf или strace не устанавливаются

Решение: Проверьте, что репозитории включены. Для RHEL-подобных может потребоваться yum install -y epel-release. Или используйте альтернативы: bpftrace (если поддерживается), gdb для attached-отладки.

Проблема: Процесс «утекает» в D-состояние, и strace не показывает активности

Решение: Это состояние uninterruptible sleep (обычно I/O). Проверьте:

iostat -x 2 5        # Загрузка дисков (await, svctm)
dmesg | tail -20     # Ошибки диска/контроллера

Возможно, физический диск неисправен или сетевая файловая система (NFS) недоступна.

Проблема: Высокий load average, но top не показывает процессов с высоким %CPU

Решение: Скорее всего, много процессов в состоянии D (ожидание I/O). Запустите iotop -o (только процессы с активностью I/O) или iftop для сети. Также проверьте kswapd0 — если он активен, не хватает памяти, и система активно своппирует.

Проблема: После завершения процесса нагрузка не падает

Решение: Возможно, zombie-процессы (Z в top). Они не потребляют CPU, но занимают слот в таблице процессов. Устраните родительский процесс или перезагрузите систему. Также проверьте, не запущен ли демон-монитор (например, systemd), который автоматически перезапускает упавший сервис.

Дата актуальности инструкции: 2026-04-08. Проверено на Ubuntu 22.04, CentOS Stream 9.