Load Average в Linux: понять и устранить перегрузки

TL;DR

Load average показывает среднее число процессов, выполняющихся или ожидающих CPU за 1, 5 и 15 минут. Сравнивайте значения с количеством ядер: нагрузка выше числа ядер означает очередь процессов. Используйте uptime, top, vmstat, iostat и glances для диагностики; применяйте renice, ionice, swap, распределение cron и контейнеризацию для снижения нагрузки.

График среднего загрузки системы в Linux за 1, 5 и 15 минут

Load average — один из ключевых индикаторов состояния Linux-системы. Он показывает не моментальную загрузку процессора, а усреднённую нагрузку за 1, 5 и 15 минут. Это помогает понять тренды, отличить кратковременные всплески от постоянной перегрузки и выбрать правильную тактику устранения проблем.

Что такое Load Average и как он считается

Load average измеряет количество процессов, которые либо выполняются на CPU, либо ожидают доступа к CPU. В Unix-подобных системах в показатель включаются процессы в состоянии выполнения (running) и процессы в непрерываемом ожидании ввода-вывода (uninterruptible sleep, состояние D).

Значения выводятся в виде трёх чисел:

load average: 0.19, 0.10, 0.14

Первое число — средняя нагрузка за 1 минуту.
Второе — за 5 минут.
Третье — за 15 минут.

Коротко: это длина очереди выполнения, усреднённая во времени. Показатель зависит от числа логических ядер (vCPU). Для интерпретации всегда учитывайте количество CPU.

Как интерпретировать значения для разных систем

Правило простое: сравнивайте load average с количеством логических ядер (потоков). Узнать их можно так:

nproc      # количество доступных логических ядер
lscpu      # детальная информация о CPU
cat /proc/cpuinfo

Примеры интерпретации:

На однопроцессорной системе load = 1.0 обычно означает 100% загрузку CPU. Значение >1 говорит о накопившейся очереди на выполнение.
На 4‑ядерной системе load = 4.0 ≈ 100% загрузка всех ядер; load = 8.0 — очередь в 2 раза больше числа ядер.

Формула перевода в проценты (приближённо):

CPU_util_percent ≈ (load / logical_cores) × 100

Пример: load 6.0 на 8‑ядерной машине ≈ (6/8)*100 = 75%.

Важно: load учитывает не только CPU-bound процессы. Если процессы ждут диска (I/O wait), они тоже влияют на load.

Команды для быстрой проверки

uptime — показывает время работы, число пользователей и три числа load average

uptime

top / htop — интерактивно, отображают load сверху, список процессов, CPU, память

top
htop

Скриншот top с текущими средними загрузками и процессами

vmstat — быстрый снимок состояния CPU, памяти и ввода-вывода

vmstat 1 5

iostat (sysstat) — проверка нагрузки на диск и задержек

iostat -x 1 5

iotop — мониторит процессы по использованию диска (нужны права root)

iotop -ao

ps — выборка процессов с настраиваемыми фильтрами

ps aux --sort=-%cpu | head -n 10
ps -eo pid,ppid,cmd,%mem,%cpu,state | head -n 20

free / swapon — состояние памяти и swap

free -h
swapon --show

docker/kubectl — для контейнеризированных сред

docker stats --no-stream
kubectl top pods --all-namespaces

Типичные причины высокого Load Average

CPU-bound процессы — программы интенсивно используют CPU.
Долгие операции ввода-вывода — высокий I/O wait.
Недостаток памяти и активное использование swap.
Много параллельных задач (cron, batch, CI), стартующих одновременно.
Зависшие процессы в состоянии D (uninterruptible sleep).
Неправильные настройки контейнеров или cgroups.

Выявление причин через top: процессы, использующие CPU и память

Иллюстрация проблем с вводом-выводом (I/O) как источник высокой загрузки

Пошаговое руководство по устранению высокой нагрузки (SOP)

Снимите текущие метрики: uptime, top, vmstat 1 5, iostat -x 1 5, free -h.
Определите, что растёт: CPU (user/system), wa (I/O wait), или swap.
Найдите процессы-лидеры: ps aux –sort=-%cpu, ps aux –sort=-%mem, iotop.
Если процесс некритичный — завершите его аккуратно: kill или systemctl stop .
Для долгосрочного решения: настройте лимиты (cgroups, systemd Slice), настройте nice/ionice, добавьте swap или увеличьте RAM.
Перераспределите cron/временные задачи во времени. Используйте Anacron для машиn, работающих не круглосуточно.
Для контейнеров — уменьшите request/limit, настройте горизонтальное масштабирование.
Документируйте причину, принятые меры и результаты.

Краткий набор команд для вмешательства:

# посмотреть лидеров по CPU
ps aux --sort=-%cpu | head -n 10
# по памяти
ps aux --sort=-%mem | head -n 10
# по I/O (root)
iotop -ao
# уменьшить приоритет процесса по CPU
renice +10 -p 
# задать приоритет I/O для процесса
ionice -c2 -n7 -p 
# ограничить CPU для процесса
cpulimit -p  -l 50

Как определить узкое место: CPU vs I/O vs память

CPU-bound: высокий %user/%system в top, высокий load без роста wa и без swap.
I/O-bound: повышенный столбец wa в top, в iostat — высокий await и %util близкий к 100%.
Memory-bound: активен swap, высокая нагрузка по памяти, процессы в состоянии OOM или frequent swapping.

Используйте vmstat, iostat и sar для корреляции симптомов.

Оптимизация процессов и системные приёмы

Используйте nice/renice для снижения приоритета фоновых задач.
ionice для контроля доступа к диску.
Ограничьте параллелизм (thread pools, worker counts) в конфигурации приложений.
Внедрите rate limit и backpressure в микросервисах.
Используйте SSD или NVMe для критичных по I/O дисков.
Настройте мониторинг и алерты по порогам: load > cores × 0.8 на 5+ минут.

Управление планировщиком задач (cron) и пакетными заданиями

Проверьте логи cron: grep CRON /var/log/syslog или journalctl -u cron.
Разнесите время старта тяжёлых задач: используйте случайную задержку или cronie’s anacron.
Рассмотрите использование systemd timers с RandomizedDelaySec.

Контейнеры и оркестрация

В контейнерах load avg отражает состояние узла, а не только контейнера. Для диагностики:

docker stats показывает использование по контейнерам.
kubectl top и metrics-server/Prometheus дают метрики по подам.

Ограничения через cgroups и requests/limits помогают изолировать нагрузку.

Когда Load Average вводит в заблуждение

На системах с большим количеством процессов, часто блокирующихся на I/O, load может выглядеть высоким, хотя CPU простаивает.
Виртуальные среды и облачные экземпляры с разделяемыми ресурсами могут иметь нетипичное поведение; смотрите за steal time (st) в top/htop.
Узкие места в подсистеме ввода-вывода, а не в CPU, требуют другой стратегии (оптимизация диска, кеширования).

Критерии приёмки после оптимизации

Средний load за 5 минут ≤ number_of_logical_cores × 0.8 в течение 30 минут рабочего окна.
I/O wait (wa) < 5% и нестабильных скачков нет.
Swap практически не используется: swapon –show либо free -h показывает 0–5% swap usage.
Время отклика сервисов соответствует SLA или улучшается.

Проверочные тесты и приемка (Test cases)

Создать нагрузку CPU (stress-ng) и проверить, что при ограничениях cgroups она не поднимает load выше порога.
Смоделировать I/O нагрузку и оценить влияние на wa и latency.
Запустить массовый запуск cron-заданий и проверить, что распределение времени снижает пиковую нагрузку.

Быстрый чек-лист для ролей

Системный администратор:

Проверить uptime, top, vmstat, iostat.
Убедиться в наличии swap и свободной RAM.
Настроить systemd limits и cgroups.

Разработчик приложения:

Ограничить параллелизм и буферы.
Внедрить таймауты и механизмы отката.
Обеспечить метрики по latency и resource usage.

SRE / On-call:

Настроить алерты по load/cores, wa, swap.
Иметь runbook для быстрого рестарта сервиса и сбора дампов.

Шаблон действий при инциденте (Runbook)

Получили алерт по высокому load.
Подключились к узлу, сняли top, vmstat, iostat.
Зафиксировали лидирующие процессы и их PID.
Для некритичных — уменьшили priority (renice/ionice) или перезапустили.
Если проблема I/O — ограничили фоновые задачи, по возможности перевели на другой диск.
Документировали шаги и результаты, временно увеличили ресурсы при необходимости.

Мини‑методология для предотвращения повторов

Наблюдаем: собираем метрики (Prometheus, node_exporter, collectd).
Анализируем: корневая причина — CPU, I/O, память.
Решаем: конфигурация, масштабирование, оптимизация кода.
Проверяем: тесты под нагрузкой и мониторинг.

Факты и ориентиры

Load average — это длина очереди процессов, учитывающая ready и uninterruptible sleep.
Включает процессы в состоянии D (I/O wait).
Всегда нормируйте по числу логических ядер.

Краткий глоссарий

Load average — усреднённая длина очереди выполнения за интервалы 1/5/15 минут.
wa — время ожидания ввода-вывода (I/O wait).
uninterruptible sleep (D) — состояние ожидания I/O, которое добавляется в load.
nice/renice — инструмент для изменения приоритета CPU.
ionice — управление приоритетом ввода-вывода.

Частые вопросы

Какой предел load считать критичным?

Предел зависит от числа логических ядер. Как правило, длительная нагрузка выше числа ядер — тревожный сигнал.

Можно ли уменьшить load без добавления железа?

Да. Оптимизация параметров приложений, снижение параллелизма, распределение cron-заданий, добавление swap и использование SSD часто помогают.

Отражает ли load только загрузку CPU?

Нет. В load включаются процессы, ожидающие I/O, поэтому он показывает совокупную нагрузку на систему, а не только CPU.

Короткое резюме

Load average — мощный, но контекстно-зависимый индикатор. Сравнивайте его с числом логических ядер и сопоставляйте с показателями wa, swap и %CPU. Команды uptime, top, vmstat, iostat и инструменты контейнерной оркестрации помогут быстро диагностировать проблему. Для снижения нагрузки используйте лимиты, nice/ionice, масштабирование и оптимизацию приложений.

Decision flowchart для быстрых действий

flowchart TD
  A[Алерт: высокий load] --> B{Load > cores?}
  B -- Да --> C{wa высокий?}
  B -- Нет --> D[Проверить процессы по CPU]
  C -- Да --> E[Проверить iostat, iotop, диск]
  C -- Нет --> D
  D --> F[Найти лидирующие процессы]
  F --> G{Критичны?}
  G -- Да --> H[Переразметить нагрузку или масштабировать]
  G -- Нет --> I[renice/ionice или kill]
  E --> J[Оптимизация диска или перенос данных]
  H --> K[Мониторинг стабилизации]
  I --> K
  J --> K
  K --> L[Закрыть инцидент и документировать]