Ответ
Load Average — это усредненные за определенные периоды времени значения числа процессов, находящихся в состоянии R (Runnable) или D (Uninterruptible Sleep).
- R (Runnable): Процессы, готовые к выполнению и ожидающие своей очереди на CPU.
- D (Uninterruptible Sleep): Процессы, заблокированные, обычно в ожидании завершения операции ввода-вывода (например, чтения с диска). Это ключевой момент: высокий load average может быть вызван не CPU, а медленным диском или сетью.
Система выводит три числа: средняя нагрузка за 1, 5 и 15 минут.
Как интерпретировать?
Сравнивайте значение с количеством доступных CPU ядер (не потоков!). Узнать можно командой nproc или grep -c ^processor /proc/cpuinfo.
- Load < Число ядер: Система справляется, процессы не ждут.
- Load ≈ Число ядер: Система загружена полностью, но без очереди.
- Load > Число ядер: Формируется очередь, возможны задержки в отклике.
Практический пример диагностики:
# 1. Смотрим нагрузку
$ uptime
15:30:01 up 30 days, 2:15, 1 user, load average: 4.21, 3.75, 2.90
# 2. Узнаем количество ядер
$ nproc
4
# 3. Интерпретация: На 4-ядерной системе load в 4.21 означает, что в среднем за последнюю минуту 4.21 процесса ждали своей очереди. Это указывает на насыщение.
# 4. Смотрим, что создает нагрузку (процессы в состоянии R и D)
$ top
# Или более детально с помощью `atop` или `htop`.
# 5. Проверяем, не связано ли это с I/O (состояние D). Команда `iostat` или `iotop` поможет.
$ iostat -dx 2 5
# Если `%util` у диска близок к 100%, проблема в медленном I/O.Для DevOps важно: Высокий load average на серверах приложений или БД — это триггер для алертов в Prometheus (node_load1, node_load5). Мы настраиваем алерты, когда нагрузка превышает порог (например, node_load1 > (число_ядер * 0.8)), и далее исследуем причину с помощью мониторинга CPU, памяти и дискового I/O.
Ответ 18+ 🔞
Ёперный театр, load average! Ну вот смотри, объясняю на пальцах, чтобы даже мартышлюшка поняла.
Load Average — это, грубо говоря, средняя арифметическая, но для очереди в бар. Система считает, сколько процессов тупо ждут, когда им дадут поесть с процессора. Считает она не всех подряд, а только тех, кто в двух конкретных состояниях:
- R (Runnable): Это те, кто уже с деньгами у стойки, бухать готов, но бармен (CPU) занят. Ждут своей рюмки.
- D (Uninterruptible Sleep): А вот это, бля, самые хитрые жопы. Это процессы, которые как бы уснули, но не просто так — они ждут, пока им принесут водку с дальнего склада (например, прочитают данные с диска). И разбудить их нельзя, пока операция не завершится. Вот ключ! Если load зашкаливает, а CPU почти простаивает — это не процессор, это твой хреновый диск или сеть тормозит всё к ебеням.
Система выдает три цифры, как градусник: средняя температура за 1, 5 и 15 минут.
Как это читать, чтобы не охуеть?
Берешь эту цифру и сравниваешь с количеством реальных ядер процессора в сервере (не потоков, ядёна вошь!). Узнать просто: nproc или посмотреть в /proc/cpuinfo.
- Нагрузка МЕНЬШЕ числа ядер: Всё пиздато. Бармены справляются, очереди нет.
- Нагрузка РАВНА числу ядер: Бар работает на полную, но каждый пьяница уже с рюмкой в руке. На пределе, но пока держим.
- Нагрузка БОЛЬШЕ числа ядер: Вот тут пиздец начинается. Очередь растёт, новые клиенты стоят и матерится, а старые уже вторую порцию ждут. Отклик системы летит в пизду.
Пример, как я бы это на проде смотрел:
# 1. Глянем, что вообще творится
$ uptime
15:30:01 up 30 days, 2:15, 1 user, load average: 4.21, 3.75, 2.90
# 2. Щупаем, сколько у нас ядер (допустим, 4)
$ nproc
4
# 3. Соображаем: Нагрузка 4.21 при 4 ядрах — это, бля, овердохуища. Значит, в среднем за минуту больше 4 процессов торчали в очереди. Система захлебнулась.
# 4. Начинаем искать виноватого. Кто эти R и D?
$ top
# Или лучше `htop`, там нагляднее.
# 5. Сразу проверяем, не дисковый ли это I/O всех положил (те самые D-процессы). Команды `iostat` или `iotop` рулят.
$ iostat -dx 2 5
# Смотри на `%util` у диска. Если он под 100% — поздравляю, нашёл бутылочное горлышко. Диск — сосалка.А для нас, деплоящих это всё, важно вот что: Высокий load на серверах — это красная тряпка. В прометее (node_load1, node_load5) мы настраиваем алерты, чтобы орало, когда нагрузка, например, больше 80% от числа ядер. Получили алерт — не бздим, а лезем смотреть глубже: что с CPU, памятью, а главное — с дисками. Часто оказывается, что какой-нибудь пидарас шерстяной (база данных или лог-ротейтор) так усердно пишет, что всех положил.
Видео-ответы
▶
▶
▶
▶
▶
▶
▶
▶
▶
▶
▶
▶
▶
▶