Как диагностировать высокую нагрузку на CPU через SSH в Linux?

«Как диагностировать высокую нагрузку на CPU через SSH в Linux?» — вопрос из категории Linux, который задают на 23% собеседований Devops Инженер. Ниже — развёрнутый ответ с разбором ключевых моментов.

Ответ

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

1. Быстрый обзор (top / htop):

top -c -o %CPU  # Сортировка по использованию CPU, показ команд
# Или htop (более наглядно)

Смотрю на %Cpu(s) строку: высокий us (user) — нагрузка от приложений, sy (system) — от ядра, wa (iowait) — процессы ждут ввода-вывода.

2. Детализация по процессам (ps):

ps aux --sort=-%cpu | head -20  # Топ-20 процессов по CPU
# Или для дерева процессов:
ps faxo pid,user,pcpu,pmem,comm --forest

3. Анализ системных вызовов (perf / strace): Если процесс-потребитель найден, смотрю, ЧТО он делает.

# Профилирование CPU в реальном времени для всего system
perf top

# Прикрепиться к конкретному PID и показать стектрейсы
perf record -F 99 -p <PID> -g -- sleep 30
perf report

# Показать системные вызовы процесса (может быть тяжело)
strace -c -p <PID>  # Сводная статистика
strace -p <PID> 2>&1 | head -50  # Посмотреть текущие вызовы

4. Анализ ожидания ввода-вывода: Высокий iowait в top — это часто симптом проблем с диском.

iostat -xz 2  # Статистика по дискам каждые 2 секунды
iotop -o     # Показать процессы, активно ведущие I/O

5. Для долгосрочного анализа настраиваю сбор метрик sar (пакет sysstat), чтобы позже посмотреть историю:

sar -u 1 3    # Загрузка CPU последние 3 секунды с интервалом 1с
sar -q        # История загрузки системы и длина очереди

Типичный сценарий: htop показывает java процесс с 300% CPU -> perf record на него -> perf report показывает, что 80% времени уходит на функцию G1GC... -> проблема в настройках сборщика мусора.