top показывает load average: 4.21, 3.87, 2.15 — и непонятно это катастрофа или рабочий режим. Ответ зависит от количества ядер. И ещё от того что именно создаёт эту нагрузку — CPU или I/O. Это разные проблемы с разными решениями.
Три числа — три временных горизонта
uptime и первая строка top показывают три значения:
uptime
10:42:15 up 14 days, 3:21, 2 users, load average: 1.85, 2.10, 3.40
Числа слева направо — средняя нагрузка за 1 минуту, 5 минут и 15 минут. Не текущая нагрузка — именно средняя за период.
Читать нужно в обратном порядке: сначала 15 минут, потом 5, потом 1. Это покажет тренд:
1.85 → 2.10 → 3.40 — нагрузка падает. Пик был 15 минут назад, сейчас лучше.
3.40 → 2.10 → 1.85 — нагрузка растёт. Только начинается.
2.10 ≈ 2.10 ≈ 2.10 — нагрузка стабильная. Система в устойчивом состоянии.
Что такое 1.0 в единицах LA
Единица LA — один процесс постоянно занимает одно ядро CPU. На сервере с 4 ядрами:
- LA = 4.0 — все ядра загружены на 100%, очереди нет. Норма.
- LA = 2.0 — половина ядер занята. Запас есть.
- LA = 8.0 — очередь в два раза больше пропускной способности. Проблема.
Формула нормального LA: количество ядер × 0.7–1.0
Узнать количество ядер:
nproc
или:
grep -c processor /proc/cpuinfo
Посчитать LA на ядро прямо в терминале:
echo "scale=2; $(uptime | awk '{print $(NF-2)}' | tr -d ',') / $(nproc)" | bc
Значение больше 1.0 означает что ядра не справляются и процессы стоят в очереди.
Что именно считается в LA: не только CPU
Главное заблуждение про Load Average — что это загрузка процессора. Это не так. В LA считаются все процессы в двух состояниях:
R (Running/Runnable) — процессы которые выполняются или готовы к выполнению и ждут CPU.
D (Disk sleep / Uninterruptible sleep) — процессы которые заблокированы в ожидании I/O: чтения диска, сетевого ответа, NFS. Их нельзя прервать сигналом.
Это критически важно: высокий LA при низкой загрузке CPU означает проблему с дисковым I/O или сетью, а не с процессором. Две совершенно разные ситуации требующие разных действий.
Как читать данные из /proc/loadavg
Файл /proc/loadavg — первоисточник для всех утилит:
cat /proc/loadavg
1.85 2.10 3.40 2/487 29341
Первые три числа — LA за 1/5/15 минут. Четвёртое поле 2/487 — сколько процессов сейчас активны из общего числа. Пятое — PID последнего созданного процесса.
Инструменты диагностики: найти виновника
Посмотреть загрузку CPU отдельно от I/O:
vmstat 1 5
Колонка wa — процент времени ожидания I/O. Если wa высокий при высоком LA — проблема в дисках или сети, не в CPU.
Найти D-state процессы (застрявшие в I/O):
ps aux | awk '$8 ~ /^D/ {print $0}'
Или короче:
ps -eo pid,stat,comm | grep "^.\{0,6\} D"
Если таких процессов много — диск или NFS не справляется.
top с сортировкой по нагрузке:
top -o %CPU
Нажать 1 внутри top — показать нагрузку по каждому ядру отдельно. Сразу видно равномерно ли распределена нагрузка.
sar: история нагрузки за прошлые часы:
sudo apt install sysstat
sar -q 1 5
sar -q показывает историю LA с временными метками — видно когда именно был пик.
Нормальные значения: ориентиры
| Ситуация | LA на ядро | Оценка |
|---|---|---|
| Сервер простаивает | < 0.1 | Нет нагрузки |
| Нормальная работа | 0.1 – 0.7 | Хорошо |
| Высокая нагрузка | 0.7 – 1.0 | Допустимо |
| Очередь нарастает | > 1.0 | Требует внимания |
| Сервер перегружен | > 2.0 | Проблема |
Кратковременные пики выше 1.0 — нормальны. Проблема начинается когда 15-минутное значение системно превышает количество ядер.
Частые причины высокого LA
Высокий LA + высокий %CPU: скрипт или процесс потребляет ядра. Найти через top или:
ps aux --sort=-%cpu | head -10
Высокий LA + низкий %CPU + высокий %wa в vmstat: I/O-проблема. Проверить диск:
iostat -x 1 5
Колонка %util близко к 100% — диск перегружен.
Высокий LA + много D-state процессов + NFS смонтирован: сетевая файловая система не отвечает. Проверить:
df -h
mount | grep nfs
Высокий LA после обновления ядра: проблема с драйвером. Смотреть dmesg:
dmesg -T --level=err | tail -20
Мониторинг LA в долгосрочной перспективе
Разовое значение uptime ничего не говорит о поведении системы за неделю. Для понимания паттернов — системы мониторинга:
Netdata — устанавливается одной командой, веб-интерфейс с историей LA по минутам:
bash <(curl -Ss https://my-netdata.io/kickstart.sh)
Zabbix, Prometheus + Grafana — для серверной инфраструктуры с алертами при превышении порогов.
Шпаргалка
| Задача | Команда |
|---|---|
| Текущий LA | uptime |
| LA из первоисточника | cat /proc/loadavg |
| Количество ядер | nproc |
| LA на ядро (быстро) | echo "scale=2; $(uptime | awk '{print $(NF-2)}' | tr -d ',') / $(nproc)" | bc |
| I/O wait (причина LA?) | vmstat 1 5 — смотреть колонку wa |
| Нагрузка по ядрам | top, затем нажать 1 |
| D-state процессы | ps aux | awk '$8 ~ /^D/ {print $0}' |
| История LA | sar -q 1 5 |
| Загрузка диска | iostat -x 1 5 |
| Топ процессов по CPU | ps aux --sort=-%cpu | head -10 |
