Load average 100 — это катастрофа или норма: что число значит на самом деле

MAATRIX

Видите в uptime число вроде «load average: 42.00, 38.50, 35.10» и не понимаете, паниковать или нет. Первая реакция — это же явно больше 100% CPU, сервер сейчас упадёт. На деле load average — это не проценты и вообще не про процессор напрямую, а про очередь: сколько процессов ждут своей возможности выполниться или зависли в ожидании диска. Ниже разберём, что это число реально считает, почему одно и то же значение может быть нормой на одной машине и катастрофой на другой, и как быстро найти, кто именно создаёт нагрузку.

Что на самом деле считает load average

Load average — это среднее число процессов, которые находятся в состоянии «runnable» (готовы выполняться и ждут ядро) плюс процессы в состоянии D — uninterruptible sleep, обычно ожидание диска или другого блокирующего ввода-вывода. Ядро Linux берёт этот срез каждые несколько секунд и усредняет по трём окнам — 1, 5 и 15 минут. Отсюда и три числа в выводе uptime или cat /proc/loadavg:

$ cat /proc/loadavg
42.15 38.72 35.03 12/487 28931

Первые три числа — те самые средние за 1/5/15 минут. Четвёртое поле (12/487) — сейчас выполняется/запущено всего процессов и потоков, пятое — PID последнего созданного процесса. Ключевой момент: в очередь, которую измеряет load average, попадают не только процессы, реально грузящие процессор, но и процессы, зависшие в D-состоянии — то есть ждущие диск, сеть NFS, медленное блочное устройство. Именно поэтому нельзя читать load average как «загрузка CPU в процентах» — это исторически прижившееся, но неверное толкование.

Второе отличие от привычного %CPU в top: load average — не мгновенный снимок, а скользящее среднее с экспоненциальным затуханием, похожее по духу на то, как считается средняя скорость на спидометре с инерцией. Резкий всплеск на 10 секунд почти не сдвинет 15-минутное значение, а вот 1-минутное отреагирует быстро. Если все три числа растут одновременно — нагрузка нарастает и держится. Если 1-минутное значение намного выше 15-минутного — это свежий всплеск, возможно, уже проходящий. Если наоборот, 15-минутное выше 1-минутного — пик уже прошёл, система успокаивается.

Почему это не «проценты CPU» и как с ним ошибаются

Путаница растёт из привычки к метрикам вроде CPU usage в панелях мониторинга, где 100% — это явный потолок. Load average потолка не имеет вообще: число 0 значит «очередь пуста», а число 500 значит «в очереди было в среднем 500 процессов» — и оно в принципе не ограничено сверху количеством ядер. Сравнивать load average с процентом CPU из top — то же самое, что сравнивать длину очереди в кассу с загрузкой конкретного кассира: связанные вещи, но не одна и та же метрика.

Отсюда вторая частая ошибка — судить о критичности числа без контекста. Load average 8 — это ни о чём не говорит само по себе. На сервере с одним ядром это означает, что в среднем восемь процессов ждали своей очереди на единственное ядро — почти наверняка сервер тормозит на глазах у пользователей. На сервере с 32 ядрами то же самое число 8 означает, что четверть мощности используется — совершенно спокойная ситуация, возможно, даже недогруженная машина.

Поэтому единственный корректный способ читать load average — соотносить его с числом логических ядер (nproc), а не с абсолютным порогом вроде «выше 5 — плохо». Это правило работает независимо от того, VPS у вас на пару ядер или выделенный сервер на сотни потоков — методика диагностики одна и та же, различается только масштаб цифр.

Как соотнести число с количеством ядер

Узнать число логических ядер:

$ nproc
8

Грубое эмпирическое правило, которым пользуются многие инженеры: пока load average держится в районе числа ядер или ниже — процессор в целом справляется, очередь не копится. Когда среднее заметно превышает число ядер — значит, в среднем процессы стоят в очереди дольше, чем выполняются, и это уже повод разбираться, кто грузит систему. Это именно ориентир, а не жёсткий порог с научным обоснованием — реальная граница «нормально/ненормально» зависит от типа нагрузки, приоритетов процессов и от того, насколько чувствительны к задержке ваши сервисы.

Отсюда и ответ на вопрос из заголовка. Load average 100 на сервере с 256 логическими ядрами — это примерно 40% условной загрузки очереди, вполне рабочая ситуация под серьёзную нагрузку, особенно если число стабильно, а не растёт лавинообразно. То же самое load average 100 на сервере с 4 ядрами — это в 25 раз больше числа ядер, и это уже авария: процессы стоят в очереди в буквальном смысле десятками, отклик сервиса просядёт очень заметно, а часть запросов может уйти в таймаут.

Важный нюанс с виртуализацией и контейнерами: если у вас VPS с ограничением по vCPU внутри более крупного физического хоста, nproc покажет именно выделенные вам ядра — это и есть база для сравнения, а не физическое число ядер хоста. А в Docker-контейнере с --cpus load average вообще считается для всей хостовой системы, а не для cgroup контейнера — внутри контейнера это число может вводить в заблуждение ещё сильнее, потому что не отражает именно ваш лимит.

CPU-bound и IO-bound: почему одна и та же цифра означает разное

Здесь возвращаемся к тому, что load average считает не только процессы, реально занимающие процессор (R — running/runnable), но и процессы в D — uninterruptible sleep. Это разные по природе проблемы, и путать их — терять время на диагностике.

CPU-bound нагрузка: много процессов реально считают что-то на процессоре — рендеринг, шифрование, сборка, тяжёлые запросы к базе с полным сканированием таблиц. Тут load average растёт вместе с %CPU в top, ядра действительно заняты вычислениями, и iowait в том же top остаётся низким.

IO-bound нагрузка: процессы не считают, а ждут — медленный диск, сетевой сторедж вроде NFS, зависшая на морском дне SAN-полка, файловая система, упёршаяся в лимит IOPS. Такие процессы попадают в D-состояние: они не могут быть прерваны сигналом, потому что ядро ждёт ответа от устройства. Пока процесс висит в D, он засчитывается в load average наравне с процессом, который реально грузит ядро — хотя сам процессор в этот момент может простаивать почти полностью. Отличительный признак такой ситуации — высокий load average при низкой загрузке CPU и заметном iowait.

Это самая частая причина, почему «load average подскочил, а top показывает, что процессор свободен» — на первый взгляд парадокс, но на деле это явный сигнал: ищите не процессор, а диск, сеть или файловую систему.

Практика: кто создаёт нагрузку

Порядок действий, который экономит время — сначала понять, CPU это или IO, потом найти конкретный процесс.

Быстрый снимок общей картины:

$ top

В шапке top смотрите на строку %Cpu(s) — если высокий us (user) или sy (system) — это CPU-bound история, ищите процесс по %CPU в списке ниже. Если высокий wa (iowait) — процессор ждёт диск, дело в IO.

Топ процессов по потреблению CPU без интерактивного режима, удобно для логов и скриптов:

$ ps aux --sort=-%cpu | head -15

Аналогично по памяти, если подозреваете, что дело не в CPU, а в свопинге:

$ ps aux --sort=-%mem | head -15

Найти процессы именно в D-состоянии — это прямые кандидаты на IO-bound проблему:

$ ps -eo pid,ppid,stat,pcpu,pmem,etime,cmd | awk '$3 ~ /D/'

Если такие процессы есть и не пропадают за несколько повторных запусков команды — они реально застряли на ожидании ввода-вывода, а не просто мелькнули между снимками.

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

$ vmstat 1 5

Колонка r — число процессов, реально готовых выполняться (runnable queue), колонка b — число процессов, заблокированных в uninterruptible sleep. Если b заметно больше r — вы имеете дело с IO-bound ситуацией, и дальше нужно смотреть именно на диски.

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

$ iostat -xz 1 5

Здесь важны колонки %util (насколько устройство занято обслуживанием запросов) и await (среднее время ожидания запроса, включая время в очереди). Устройство с %util, стабильно близким к максимуму, и растущим await — это и есть источник D-состояний, которые раздувают load average.

Если сервер под управлением systemd, полезно также свериться с systemd-cgtop — он покажет потребление ресурсов по группам служб (cgroups), что удобно, когда на машине крутится десяток сервисов и непонятно, какой именно расходится.

Когда число вводит в заблуждение

Несколько ситуаций, где голое число load average без контекста обманывает:

• Контейнеры и cgroup-лимиты. Внутри Docker или Kubernetes load average, который видит процесс через /proc/loadavg, — это load average хоста целиком, а не вашего контейнера. Контейнер может быть жёстко ограничен по CPU через cgroup и throttled, а load average при этом покажет спокойную цифру хоста — метрика просто не про ваш лимит.
• Гипертрединг и виртуальные ядра. nproc считает логические потоки (включая hyperthreading/SMT), а не физические ядра. Это корректная база для сравнения с load average — планировщик ОС действительно раскладывает процессы по логическим потокам, — но не путайте эту цифру с «числом настоящих ядер», если сравниваете конфигурации серверов между собой.
• Кратковременные всплески vs устойчивая нагрузка. Одиночный скачок 1-минутного значения при спокойных 5- и 15-минутных — обычно неопасен: это могла быть разовая тяжёлая задача (бэкап, пересборка индекса), которая уже завершается. Тревожный сигнал — рост во всех трёх окнах одновременно.
• NFS и сетевые файловые системы. Зависший NFS-монтирование способно держать процессы в D очень долго — иногда пока не восстановится сеть или не перемонтируется ресурс, — и в это время load average будет расти без какой-либо видимой нагрузки на CPU или локальный диск.
• Планировщики задач и cron. Пачка cron-заданий, запущенных одновременно (классика — все в 00:00 или на границе часа), может кратковременно поднять 1-минутное значение просто потому, что несколько процессов стартовали разом, а не потому что что-то сломалось.

Если на сервере регулярно случаются такие всплески и разбираться в них вручную надоедает, стоит поставить постоянный сбор метрик — тогда видно не разовое число, а тренд. О том, как быстро найти конкретный процесс, съедающий ресурсы, подробнее написано в статье как узнать, кто нагружает сервер, а если подозрение падает именно на процессор — в разборе высокая нагрузка на процессор: как найти причину. Когда картина указывает на диск, а не на CPU, логично сразу проверить его отдельно — как это сделать, описано в статье медленный диск на VPS: как проверить. А если жалоба звучит просто как «сайт тормозит» и непонятно, с чего начать диагностику вообще, есть отдельный разбор сайт тормозит на VPS: диагностика.

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