Как дебажить нагрузку на CPU в ssh консоли в Linux

Диагностика высокой нагрузки на CPU через SSH

При работе через SSH-консоль диагностика высокой загрузки CPU требует особого подхода, поскольку мы ограничены командной строкой и не можем использовать графические утилиты. Вот пошаговая методика, которую я применяю на практике.

1. Быстрая первичная диагностика

Первым делом нужно понять общую картину. Я начинаю с утилиты top или её современных альтернатив.

top

В выводе top обращаю внимание на:

• load average (средняя нагрузка за 1, 5 и 15 минут) — если значения значительно превышают количество ядер CPU, система перегружена.
• Процессы в верхней части списка с высоким значением в столбце %CPU.
• Нажимаю 1, чтобы увидеть загрузку по каждому ядру отдельно.

Более удобной и информативной альтернативой для быстрого обзора является htop (требует установки).

htop

Если htop не установлен, а установка невозможна, использую atop (пишет историю) или glances.

2. Детальный анализ процессов с помощью ps

Команда top показывает динамику, но для детального снимка я использую ps. Самые полезные форматы:

# Показать топ-10 процессов по потреблению CPU
ps aux --sort=-%cpu | head -11

# Более структурированный вывод, показывающий родителей и дочерние процессы (дерево)
ps auxf

# Поиск по имени процесса (например, Java)
ps aux | grep -i java | head -20

3. Профилирование с помощью perf и анализ системных вызовов

Если процесс-виновник найден, но непонятно, что именно внутри него создаёт нагрузку, перехожу к профилированию.

Использование perf для общего профиля системы:

# Записать данные за 30 секунд
sudo perf record -a -g -- sleep 30

# Анализировать записанный профиль, смотреть на граф вызовов
sudo perf report

Анализ системных вызовов с помощью strace:

Этот инструмент показывает, какие вызовы к ядру (syscalls) делает процесс. Очень часто высокая нагрузка на CPU вызвана "плохим" системным вызовом (например, частые stat() из-за проблем с кэшированием, бесконечные циклы poll()/select()).

# Прицепиться к работающему процессу и вывести статистику по вызовам
sudo strace -c -p <PID>

# Получить детальный трассировочный лог (осторожно, может быть очень много вывода)
sudo strace -p <PID> 2>&1 | head -100

4. Анализ на уровне потоков (threads)

Современные приложения многопоточны. top по умолчанию показывает процессы. Чтобы увидеть потоки, нужно:

• В top: нажать H (Shift+h).
• Использовать ps с ключом -L:

# Показать все потоки (LWP - Light Weight Process) для конкретного PID, отсортированные по CPU
ps -L -o pid,tid,pcpu,comm -p <PID> --sort=-pcpu

5. Использование /proc файловой системы

Информация о каждом процессе лежит в директории /proc/<PID>/. Это мощнейший инструмент для низкоуровневой диагностики.

# Посмотреть статус процесса (ключевое: количество потоков, состояние)
cat /proc/<PID>/status

# Увидеть, на каком CPU (ядре) работает процесс
taskset -pc <PID>

# Посмотреть статистику по планировщику (voluntary и non-voluntary context switches)
cat /proc/<PID>/sched

6. Продвинутые инструменты для анализа

• pidstat (из пакета sysstat): Позволяет снимать статистику по процессам с интервалом, отдельно показывая нагрузку на CPU, память, дисковый ввод/вывод.

  # Снимать статистику каждые 2 секунды, 10 раз, для всех процессов
  pidstat -u 2 10
  
  # Снимать с детализацией по потокам
  pidstat -u -t 2 5
  

• vmstat: Даёт общую картину не только по CPU, но и по памяти, процессам ввода/вывода. Ключевые колонки: r (процессы в очереди на выполнение), us, sy, id, wa.

  vmstat 2 5
  

• mpstat (также из sysstat): Показывает детальную статистику по каждому ядру CPU. Полезна для выявления проблем с балансировкой нагрузки между ядрами.

  mpstat -P ALL 2 5
  

Общая стратегия и checklist

1. Быстрая оценка (top/htop): Найти PID процесса-лидера по потреблению CPU.
2. Детализация (ps): Уточнить информацию о процессе (пользователь, аргументы запуска, родитель).
3. Анализ потоков: Определить, является ли процесс многопоточным, и какой конкретно поток нагружает CPU.
4. Профилирование (perf/strace): Заглянуть "внутрь" процесса, чтобы понять, на какие операции тратятся циклы процессора (пользовательский код vs ядро, ожидание ввода-вывода vs активные вычисления).
5. Контекст (vmstat/mpstat): Оценить общее состояние системы (процессы в очереди, загрузка по ядрам, наличие блокировок ввода-вывода).
6. Сбор логов и метрик: Если проблема периодическая, настроить сбор данных с помощью pidstat, sar или мониторинговых систем (Prometheus, Grafana) для последующего анализа.

Важное замечание: В SSH-сессии нужно быть осторожным с командами, которые могут сами создавать нагрузку (например, grep по большим логам без ограничения). Всегда оцениваю возможное влияние диагностической команды на и без того нагруженную систему. Для долгосрочного сбора данных предпочитаю использовать утилиты с возможностью сохранения в файл (например, sar или atop в режиме демона).