uptime и load average: что означают три числа и как их читать

Команда uptime печатает одну строку, и в ней сразу четыре сведения: текущее время, как давно система запущена, сколько пользователей вошло и три числа после слов load average. Её часто вводят, когда сервер или ноутбук «тормозит», и хотят быстро понять, виновата ли нагрузка на процессор и диск или причина лежит в другом месте.

Условный пример вывода выглядит так: время, затем «up 12 days», затем «2 users», затем «load average: 0.45, 0.60, 0.72». Конкретные цифры у вас будут свои, важно понимать порядок: первое число относится к последней минуте, второе к последним пяти минутам, третье к последним пятнадцати.

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

Load average описывает среднее число задач, готовых к выполнению. Процесс, который прямо сейчас занимает ядро, и процесс, который ждёт свободного ядра, учитываются вместе. Значение 1.00 на машине с одним ядром означает, что в среднем одна задача всегда занята делом, и свободного времени почти нет.

В Linux в это число попадают ещё и процессы в непрерываемом ожидании, обычно это ожидание ответа диска или сетевой файловой системы. Поэтому высокая нагрузка в Linux не обязательно означает занятый процессор: она может возникать, когда много задач стоят в очереди к медленному накопителю. В macOS и других BSD-системах метод подсчёта устроен иначе, подробности смотрите в справке к системе (man uptime и документация на ядро).

Ещё одна важная деталь: load average не делит значения на число ядер. Одно и то же число 4.00 на четырёхъядерной машине выглядит как полная загрузка, а на шестнадцатиядерной как небольшая. Поэтому первым делом нужно узнать, сколько у вас логических процессоров.

Количество логических процессоров узнаётся одной командой, и она различается в зависимости от системы.

Дальше работает грубое правило сравнения. Если среднее за 15 минут заметно меньше числа ядер, запас есть. Если оно держится около числа ядер, процессор загружен почти полностью, а очередь пока заметно не растёт. Если значение стабильно выше числа ядер, задачи выстраиваются в очередь, и именно тогда пользователь замечает задержки в интерфейсе или отклике сервиса.

Это ориентир, а не строгая граница. Для интерактивного компьютера краткие пики нагрузки при запуске сборки или архивации обычны и не говорят о неисправности. Тревожным признаком считается длительное превышение, особенно когда оно не связано с вашими задачами.

У uptime в Linux (в современных версиях пакета procps-ng) есть несколько полезных вариантов. В очень старых версиях и в урезанных сборках они могут отсутствовать, а в macOS утилита проще.

• uptime -p выводит время работы в человекочитаемой форме, например «up 2 weeks, 3 days». Ключ есть в Linux, в macOS его нет.
• uptime -s показывает дату и время запуска системы. Тоже особенность Linux.
• Команда w печатает ту же первую строку с load average, а ниже список вошедших пользователей и то, что они сейчас запускают. Работает и в Linux, и в macOS.
• В Linux те же три числа лежат в файле /proc/loadavg. Первые три поля это нагрузка за 1, 5 и 15 минут. Дальше идёт пара «работающих задач / всего задач», а в конце номер последнего созданного процесса.

Файл /proc/loadavg удобен в скриптах, потому что его можно прочитать без разбора текста uptime. В macOS такого файла нет, там используйте sysctl vm.loadavg или просто uptime, а формат вывода проверьте на своей версии.

Высокая нагрузка сама по себе только симптом. Дальше нужно выяснить, чем заняты процессор, память или диск.

1. Посмотрите на список процессов: top или ps aux, отсортированный по использованию процессора. Подробности о фильтрации есть на странице про ps aux.
2. Если процессор почти свободен, а нагрузка высокая, проверьте диск командой iostat и (в Linux) столбец wa в vmstat; в vmstat на macOS такого столбца нет. Высокое ожидание ввода-вывода говорит о том, что задачи ждут накопитель.
3. Проверьте, не работает ли много одинаковых процессов: pgrep -c имя в Linux покажет их число.
4. Сопоставьте момент роста с событиями: резервное копирование, обновление, индексация, запущенная сборка.
5. Если причина в вашем же фоновом задании, понизьте его приоритет с помощью nice и renice.

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

Если нужно действовать быстро, держите в голове короткий порядок и не пытайтесь анализировать сразу всё.

• Выполните uptime и запомните три числа, затем узнайте число ядер через nproc или sysctl -n hw.ncpu.
• Сравните среднее за 1 минуту со средним за 15 минут, чтобы понять направление: рост или спад.
• Если значения превышают число ядер, перейдите к списку процессов и к vmstat.
• Если значения невелики, а система тормозит, ищите причину не в процессоре: память, сеть, диск или конкретное приложение.
• Зафиксируйте вывод вместе со временем, если собираетесь обращаться за помощью: числа без даты теряют смысл.

Для сравнения с будущими замерами сохраните вывод в спокойный период. Свои «нормальные» значения знать полезнее, чем держать в памяти чужие пороги.