Что означает load average и когда высокий показатель требует проверки

В отчёте сервера появились значения средней нагрузки, и самое большое из них выглядит тревожно. Без контекста это мало о чём говорит. Нагрузка зависит от числа задач, которые выполняются, ожидают процессор или находятся в непрерываемом ожидании, а не только от вычислений.

На Linux с procps выполните:

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

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

В системе с GNU Coreutils число доступных текущему процессу вычислительных единиц можно посмотреть так:

Это полезный ориентир, но не универсальный делитель для всех сред. Контейнеры, ограничения CPU и размещение виртуальной машины меняют картину доступных ресурсов. Не объявляйте сервер исправным только потому, что средняя нагрузка меньше числа логических процессоров.

Условный пример: одинаковое значение нагрузки на небольшой виртуальной машине и на многопроцессорном узле означает разные условия конкуренции за CPU. При этом даже мощный сервер способен медленно отвечать, если процессы ждут один перегруженный диск.

Дополните картину коротким наблюдением:

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

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

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

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

При оценке виртуальной машины уточните выделенный ей лимит CPU. Число видимых процессоров и гарантированная вычислительная доля могут отличаться.

The server report shows load average values, and the highest one looks alarming. Without context, this tells us little. Load depends on the number of tasks that are running, waiting for the CPU, or in uninterruptible sleep, not just on computations.

On Linux with procps, run:

At the end of the line, load averages for one, five, and fifteen minutes are shown. These are smoothed values, so they do not have to drop instantly after a heavy task finishes. Comparing short and long intervals helps see the direction of change, but does not name the cause.

If the one-minute value is higher than the others, the load recently increased. If the long-term value remains high while the short-term value drops, the system may be exiting a peak. To resolve the issue, you still need current processes and signs of resource waiting.

In a system with GNU Coreutils, you can view the number of computational units currently available to the process as follows:

This is a useful reference, but not a universal divisor for all environments. Containers, CPU limits, and virtual machine placement alter the picture of available resources. Do not declare a server healthy simply because the average load is lower than the number of logical processors.

Hypothetical example: the same load value on a small virtual machine and on a multiprocessor node implies different conditions for CPU contention. Even a powerful server may respond slowly if processes are waiting for a single overloaded disk.

Supplement the picture with a brief observation:

A large number of waiting processes does not automatically indicate a physical disk failure. The source of the wait may be various resources or environmental factors. This result only suggests which hypothesis to test next.

The threshold must account for the typical load profile and its impact on the service. A brief spike during a scheduled background task differs from a persistent queue where checkout takes too long. It is useful to monitor response time, errors, and dependency availability simultaneously.

For comparison, record the current task, the number of available processors, all three load values, and the observation period. A single screenshot without a date or context is difficult to correlate with import logs and database monitoring.

You must be able to explain whether the CPU queue is growing or the system is waiting for another resource, which workflow coincided with the spike, and how users noticed it. After fixing the issue, repeat the observation under comparable load. A reduction in the panel value alone does not prove that the cause of the slow site has been eliminated.

When evaluating a virtual machine, specify the CPU limit allocated to it. The number of visible processors and the guaranteed compute share may differ.