Высокий load average при свободном CPU: куда смотреть в Linux

На сервере load average поднялся до 12, а график CPU показывает 25%. Возникает соблазн объявить метрики противоречивыми или срочно добавить процессорные ядра. Но load average отвечает на другой вопрос: сколько задач в среднем выполняются, готовы выполняться или находятся в определённых состояниях ожидания. Он не равен проценту занятости CPU.

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

Посмотрим время и доступные процессоры

uptime
cat /proc/loadavg
getconf _NPROCESSORS_ONLN
vmstat 1 5

Первые три числа load average относятся к сглаженным значениям за 1, 5 и 15 минут. Если первое выше третьего, нагрузка недавно выросла; если ниже — возможно, идёт восстановление. Это помогает выбрать временной диапазон журналов. Одно значение 12 без истории ещё не показывает, растёт очередь или уже рассасывается.

Число online CPU даёт контекст узла, но не гарантирует, что все они доступны интересующему процессу. У него могут быть affinity, cpuset или квота cgroup. В контейнере сравнивать load хоста с предполагаемым числом «ядер контейнера» особенно легко ошибочно. Привяжите дальнейшее наблюдение к конкретному сервису и его ограничениям.

У vmstat первая строка CPU и I/O обычно описывает средние показатели с загрузки системы; следующие строки относятся к заданному интервалу. Поля процессов и памяти отражают текущее состояние даже в первой строке. Для текущего эпизода сравнивайте несколько последовательных наблюдений. Поля r и b показывают очередь готовых и заблокированных задач, а CPU-поля помогают понять, на что приходится время. Значение iowait само по себе не измеряет задержку конкретного диска или запроса.

Найдём задачи, которые формируют очередь

ps -eLo pid,tid,stat,wchan:32,comm

Ключ -L выводит потоки: много ожидающих потоков одного процесса тоже может объяснять высокий load. Состояние R означает выполнение или готовность к выполнению, D — непрерываемое ожидание, часто связанное с I/O. Не каждое ожидание в приложении попадает в load: обычный спящий процесс в S — другая ситуация.

Сопоставьте повторяющиеся PID и имена с вашим сервисом. Поле wchan может подсказать место ожидания в ядре, но его доступность зависит от прав и настроек. Один снимок D не доказывает зависание: короткие ожидания нормальны. Повторите наблюдение и выясните, удерживаются ли те же потоки в таком состоянии на протяжении проблемы.

Например, если двадцать рабочих потоков сервиса многократно видны в D, CPU свободен и запросы задерживаются, имеет смысл исследовать путь хранения. Если очередь состоит преимущественно из R, проверьте CPU-ограничения и конкурирующие задачи. Общий load нужен здесь для постановки вопроса; ответ дают состояния и доступность конкретного ресурса.

Оценим давление на ресурсы

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

При поддержке PSI эти файлы показывают долю времени, когда задачи задерживались из-за нехватки соответствующего ресурса. Поле some относится к ситуации, когда задержана хотя бы часть задач. full для I/O и памяти выделяет периоды, когда одновременно задержаны все не простаивающие задачи. Средние avg10, avg60 и avg300 выражены в процентах; total накапливает микросекунды.

Высокое давление I/O вместе с устойчивыми D-потоками усиливает гипотезу об ожидании хранилища. Давление памяти подсказывает проверить reclaim, swap и ограничения памяти. PSI не называет конкретный накопитель или запрос, поэтому следующим шагом будет сопоставление с метриками хранилища, журналом ядра и действиями приложения. На системе без PSI этот шаг недоступен; диагностику продолжают по состояниям и ресурсным метрикам.

Что делать с найденной причиной

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

При CPU-квоте проверьте статистику throttling для cgroup сервиса и сопоставьте её с очередью R. При ошибках хранилища сначала разбирайте сообщения об устройстве или сетевом томе. Попытка принудительно завершать потоки D может не дать быстрого эффекта: выполнение сигнала зависит от выхода из соответствующего ожидания.

После изменения сравните одинаковые интервалы: пользовательскую задержку, очередь, PSI и занятость ресурса. Load average снижается с запаздыванием из-за сглаживания. Если запросы уже восстановились и очередь ушла, ожидание немедленного нулевого load только мешает увидеть результат. Цель проверки — восстановление работы сервиса и объяснение причины, а число load помогает следить за общим фоном.

Ещё по теме

• SLO и бюджет ошибок: считаем допустимые сбои сервиса на конкретном примере
• Как разобрать инцидент после восстановления: хронология, причины и проверяемые действия

Продолжить изучение

Хотите глубже разобраться в надёжности сервисов и работе с инцидентами? Посмотрите программу «DevOps Engineer PRO: от Junior до Middle».