Что нужно делать, если на сервере высокий Load Average?

Общий подход к диагностике высокой загрузки системы (High Load Average)

Load Average — это среднее значение нагрузки на систему за 1, 5 и 15 минут, учитывающее процессы в состояниях R (Running) и D (Uninterruptible Sleep). Высокие значения (превышающие количество CPU ядер в 2-3 раза) сигнализируют о проблеме. Моя стратегия диагностики включает несколько этапов, от быстрой оценки до глубокого анализа.

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

Первым делом я собираю ключевые метрики, чтобы понять общую картину:

# Смотрю Load Average и время работы
uptime

# Анализирую утилизацию CPU, чтобы отличить CPU-bound от I/O-bound проблему
top -H  # Или htop, если установлен

# Проверяю использование памяти и своп
free -h

# Смотрю статистику ввода-вывода (ключевой показатель при I/O wait)
iostat -xz 2 5  # Для анализа дисковых операций

# Проверяю сетевую активность
sar -n DEV 2 5

Уже на этом этапе часто становится ясно, является ли проблема CPU-bound (высокий %us, %sy) или I/O-bound (высокий %wa, %util у дисков).

2. Глубокая диагностика процессов и потоков

Если нагрузка высокая, а CPU не загружен на 100%, скорее всего, процессы "залипли" в состоянии D (Uninterruptible Sleep) — это критично, так как такие процессы нельзя убить, и они ожидают ввода-вывода от устройств (чаще всего диска или сети).

# Ищем процессы в состоянии D
ps aux | awk '$8 ~ /D/ { print $0 }'

# Смотрю более детальную информацию о процессах
ps -eo pid,ppid,stat,cmd,wchan:32,pcpu,pmem --sort=-pcpu | head -20

# Анализирую количество потоков в системе (может быть исчерпан лимит)
ps -eLo pid,tid,psr,pcpu,stat,wchan:32,comm | head -30

3. Анализ конкретных подсистем

Дисковый ввод-вывод (наиболее частая причина)

# Использую iotop для идентификации процессов, активно работающих с диском
iotop -oP

# Смотрю очередь записи/чтения и await время
iostat -dxm 2 5 | grep -A 1 "Device"

# Проверяю использование inodes (частая проблема с множеством мелких файлов)
df -i

Проблемы с памятью и свопом

# Ищу признаки memory pressure и oom-killer
dmesg -T | grep -i "oom\|kill"

# Проверяю использование slab памяти (может "протекать")
slabtop -s c

# Анализирую использование swap
vmstat 2 5

Сетевые проблемы

# Проверяю, не исчерпаны ли лимиты сокетов или портов
ss -s

# Анализирую сетевые подключения (много TIME_WAIT? SYN_RECV?)
netstat -an | awk '/tcp/ {print $6}' | sort | uniq -c

4. Сбор дополнительной информации для долговременного анализа

В сложных случаях использую профилировщики:

# perf для анализа производительности ядра
perf top -z

# trace/strace для отслеживания системных вызовов конкретного процесса
strace -fp <PID> -c  # Или strace -fp <PID> -T -tt -o trace.log

5. Тактические действия и мониторинг

Пока идет диагностика, важно контролировать ситуацию:

• Не убивать процессы в состоянии D — это бесполезно и может усугубить ситуацию
• При CPU-bound нагрузке:

    - Определить процессы-лидеры (`top -c`, затем `top -H -p <PID>`)
    - Собрать thread dump для Java (`jstack <PID>`), pprof для Go

• При I/O-bound нагрузке:

    - Проверить RAID-массивы на деградацию (`mdadm -D /dev/md*`)
    - Оптимизировать запросы к БД, проверить индексы
    - Рассмотреть кэширование или увеличение RAM для уменьшения свопа

• Убедиться, что не исчерпаны системные лимиты (ulimit -a, /proc/sys/fs/file-max)

6. Долгосрочные меры после инцидента

После решения проблемы критически важно:

• Настроить алертирование по Load Average (с учетом количества CPU ядер)
• Внедрить мониторинг не только LA, но и satellite metrics:

    - Дисковые: IOPS, latency, queue depth
    - Сетевые: packet drops, retransmits
    - Память: page faults, swap usage

• Рассмотреть архитектурные изменения:

    - Вертикальное/горизонтальное масштабирование
    - Оптимизация запросов к БД и кэширование
    - Вынос медленных операций в фоновые задания (queue workers)

Ключевой принцип: Load Average — это симптом, а не сама болезнь. Настоящая причина чаще всего кроется в плохой оптимизации кода, неадекватных настройках СУБД, проблемах с дисками или сетью, либо в недостаточных ресурсах для текущей нагрузки. Системный подход к диагностике позволяет не просто временно снизить нагрузку, а устранить первопричину проблемы.