Как найти причину высокого load average при низкой загрузке CPU в Linux

Почему load average может быть высоким при почти свободном CPU

Load average в Linux показывает не процент загрузки процессора, а среднее количество задач, которые выполнялись, ожидали процессор или находились в непрерываемом ожидании. В выводе uptime три числа соответствуют среднему значению за 1, 5 и 15 минут.

uptime
 17:20:41 up 18 days,  4:12,  2 users,  load average: 12.84, 10.21, 8.67

В расчет попадают прежде всего процессы в состояниях:

R — выполняются на CPU или ждут своей очереди;
D — находятся в непрерываемом ожидании, обычно дисковой, сетевой или другой операции ядра.

Поэтому сервер может показывать load average 20 при загрузке CPU 5–10%, если множество процессов зависло в состоянии D. Процессор свободен, но задачи не могут продолжить работу, пока ядро не завершит операцию ввода-вывода.

Не сравнивайте load average с процентом CPU напрямую. Сначала определите количество доступных процессоров, затем проверьте очередь выполняемых задач и число процессов в состоянии D.

Шаг 1. Оценить масштаб нагрузки

Узнайте количество логических CPU:

nproc
lscpu | grep '^CPU(s):'

Load average не нормализуется по числу процессоров. Значение 8 означает разную ситуацию на двух- и шестнадцатиядерном сервере. На системе с 16 CPU load 8 сам по себе не указывает на перегрузку процессора. На системе с 2 CPU такое значение требует диагностики.

Посмотрите динамику:

uptime
cat /proc/loadavg

Пример содержимого /proc/loadavg:

12.84 10.21 8.67 3/812 24591

Первые три числа — load average. Значение 3/812 означает, что сейчас три задачи выполняются или готовы к выполнению, а всего в системе учтено 812 задач. Последнее число — PID недавно созданного процесса.

Если первое значение заметно выше второго и третьего, нагрузка растет. Если ниже — проблема ослабевает. Высокие значения за 15 минут при нормальном текущем состоянии могут быть следствием уже завершившегося инцидента.

Шаг 2. Проверить CPU, очередь и заблокированные процессы

Для первичной проверки используйте vmstat:

vmstat 1

Наиболее важные столбцы:

r — задачи, ожидающие CPU;
b — задачи в непрерываемом ожидании;
us и sy — работа CPU в пользовательском режиме и ядре;
id — простой CPU;
wa — время ожидания ввода-вывода;
si и so — чтение из swap и запись в swap.

Если r стабильно превышает количество CPU, вероятна процессорная очередь. Если b велико, а id остается высоким, причину следует искать среди заблокированных операций.

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

Шаг 3. Найти процессы в состояниях R и D

Выведите PID, состояние, время работы, команду и точку ожидания:

ps -eo pid,ppid,user,stat,etime,wchan:32,comm,args --sort=stat

Для отбора только интересующих состояний:

ps -eo pid,ppid,user,stat,wchan:32,comm,args |
awk '$4 ~ /^[RD]/'

Состояние может содержать дополнительные символы, например Ds или D<. Для диагностики важна первая буква.

Поле wchan показывает функцию ядра, в которой спит процесс. Типичные значения могут указывать на ожидание диска, файловой системы, сетевого ответа, блокировки или завершения дочернего процесса. Название функции не всегда достаточно для точного вывода, но помогает сгруппировать зависшие задачи.

Полезно посчитать процессы по состояниям:

ps -eo stat= |
cut -c1 |
sort |
uniq -c |
sort -nr

Если число процессов D растет, запишите их PID и команды. Один заблокированный процесс обычно не создает большой load average. Десятки или сотни однотипных процессов уже указывают на системную причину.

Шаг 4. Проверить дисковую подсистему

Высокий load average при низком CPU часто связан с медленным накопителем, исчерпанием IOPS, высокой задержкой, проблемами RAID или переполненной очередью блочного устройства.

При наличии пакета sysstat выполните:

iostat -xz 1

Оценивайте показатели в динамике:

r/s и w/s — число операций чтения и записи;
r_await и w_await — средняя задержка операций;
aqu-sz — средняя длина очереди;
%util — занятость устройства.

Нельзя использовать одно универсальное допустимое значение задержки: нормы различаются для локального SSD, HDD, сетевого блочного устройства и облачного тома. Важнее сравнивать показатели с обычным состоянием конкретного сервера и искать резкий рост задержки или очереди.

Определите процессы, создающие ввод-вывод:

pidstat -d 1

Дополнительно проверьте свободное место и inode:

df -h
df -i

Полный раздел не всегда повышает load average напрямую, но может вызывать зависания приложений, циклы повторных попыток, ошибки баз данных и проблемы с журналами.

Проверка ошибок устройств и файловых систем

Просмотрите сообщения ядра за текущую загрузку:

journalctl -k -b --no-pager |
grep -Ei 'error|fail|timeout|reset|I/O|blk|nvme|scsi|ata|ext4|xfs|btrfs'

Особенно важны сообщения о тайм-аутах, сбросах контроллера, ошибках I/O, зависших задачах и переключении файловой системы в режим только для чтения.

Не перезапускайте сервер до сохранения журналов, если ситуация позволяет продолжить диагностику. После перезагрузки часть признаков может исчезнуть, а проблема останется.

Шаг 5. Проверить сетевые файловые системы

NFS, CIFS и другие удаленные файловые системы способны удерживать процессы в состоянии D, когда недоступен сервер хранения, нарушена маршрутизация или завис сетевой запрос.

Найдите сетевые монтирования:

findmnt -t nfs,nfs4,cifs,fuse.sshfs

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

fuser -vm /mnt/storage

Команды вроде df, ls или du сами могут зависнуть при обращении к недоступному сетевому ресурсу. Выполняйте их с ограничением времени:

timeout 5s stat /mnt/storage
timeout 5s ls -la /mnt/storage

Если команда завершается по тайм-ауту, проверьте доступность сервера хранения, состояние сети, DNS, правила фильтрации и журналы NFS или CIFS. Попытка принудительно завершить процесс в состоянии D обычно не помогает: сигнал будет обработан только после возврата процесса из ядра.

Шаг 6. Проверить память и swap

Недостаток памяти может привести к интенсивному вытеснению страниц, блокировкам на вводе-выводе и росту load average.

free -h
vmstat 1
swapon --show

Наличие занятого swap само по себе не означает проблему. Важнее постоянные ненулевые значения si и so в vmstat, падение производительности и рост дисковой задержки.

Проверьте сообщения об OOM:

journalctl -k -b --no-pager |
grep -Ei 'out of memory|oom-killer|killed process'

Также полезно оценить давление на ресурсы через PSI:

cat /proc/pressure/cpu
cat /proc/pressure/io
cat /proc/pressure/memory

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

Шаг 7. Исключить ограничения контейнеров и cgroup

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

Для cgroup v2 проверьте квоту:

cat /sys/fs/cgroup/cpu.max
cat /sys/fs/cgroup/cpu.stat

В cpu.max значение max означает отсутствие квоты. Два числа задают разрешенное процессорное время и период. В cpu.stat рост nr_throttled и throttled_usec указывает, что задачи регулярно ограничиваются квотой CPU.

На сервере с systemd можно посмотреть нагрузку по группам:

systemd-cgtop

Такой сценарий отличается от блокировок ввода-вывода: процессы чаще находятся в состоянии R, а не D.

Шаг 8. Исследовать конкретный зависший процесс

Для выбранного PID сначала соберите базовые сведения:

PID=1234
cat /proc/$PID/status
cat /proc/$PID/wchan
cat /proc/$PID/io
ls -l /proc/$PID/fd

Стек ядра может показать место ожидания:

cat /proc/$PID/stack

Для чтения некоторых файлов в /proc требуются права root. Интерпретировать стек следует вместе с типом приложения, файловой системой и сообщениями ядра.

Для процесса, который не находится в непрерываемом ожидании, можно кратковременно использовать трассировку системных вызовов:

timeout 10s strace -tt -p 1234

Если процесс застрял внутри системного вызова чтения, записи, синхронизации или обращения к файлу, трассировка покажет последнюю операцию. Для процесса в глубоком состоянии D вывод может не появиться до завершения ожидания.

Типичные причины и признаки

Причина	Признаки	Что проверять
Медленный или неисправный диск	Много процессов D, растут await и очередь	`iostat`, `pidstat`, журнал ядра
Недоступный NFS или CIFS	Зависают обращения к каталогу, одинаковый wchan	`findmnt`, сеть, сервер хранения
Активный swap	Ненулевые si и so, высокая задержка диска	`vmstat`, `free`, PSI memory
CPU-квота контейнера	Процессы R, throttling в cgroup	`cpu.max`, `cpu.stat`
Проблема драйвера или устройства	Тайм-ауты, reset, hung task в ядре	`journalctl -k`, стек процессов
Кратковременный пик	Текущий load снижается, очередей уже нет	`uptime`, мониторинг за период

Итоговый чек-лист

Сравнить load average с количеством доступных CPU.
Проверить через vmstat 1 значения r, b, wa, si и so.
Найти процессы в состояниях R и D.
Сгруппировать зависшие процессы по команде и wchan.
Проверить задержку дисков, длину очереди и активных потребителей I/O.
Просмотреть журнал ядра на ошибки устройств, файловых систем и hung task.
Проверить NFS, CIFS и другие удаленные точки монтирования.
Оценить память, swap и показатели PSI.
Проверить CPU-квоты и throttling в cgroup или контейнере.
Сохранить диагностические данные до перезапуска сервисов или сервера.

Главный ориентир при такой диагностике — состояние процессов. Большое число задач D обычно ведет к хранилищу, файловой системе, сети или драйверу. Большое число задач R указывает на очередь CPU, ограничение cgroup или нехватку вычислительных ресурсов. Само значение load average описывает симптом, а не источник проблемы.