Load average и процент загрузки CPU отвечают на разные вопросы. Первый показатель связан с числом задач, готовых выполняться или находящихся в определённых состояниях ожидания, второй — с распределением процессорного времени. Поэтому высокий load при умеренном CPU не является противоречием и не доказывает нехватку виртуальных ядер.
Фото обложки: BrokenSphere; Panduit Pan-Net Cable Management System bottom rear.JPG, CC BY-SA 3.0. Уменьшение размеров и преобразование в WebP; кадрирование не выполнялось. Тематический снимок не изображает инфраструктуру упомянутых провайдеров.
Что показывает /proc/loadavg
Linux man-pages описывает первые три числа как усреднённое количество задач в очереди выполнения и состоянии D за 1, 5 и 15 минут. В следующих полях есть текущее отношение runnable-задач к общему числу сущностей планирования и последний созданный PID. Это системное наблюдение, а не измерение скорости сайта.
| Показатель | Вопрос | Чего не доказывает |
|---|---|---|
| Load 1/5/15 | Как меняется очередь и включаемое ожидание? | Что виноват именно CPU |
| CPU user/system | Где тратится процессорное время? | Что приложение получает полезный результат |
| I/O wait | Есть ли связанное с I/O ожидание в модели инструмента? | Какой именно файл или запрос медленный |
| Очередь PHP | Ждут ли запросы свободного worker? | Что расширение пула безопасно по RAM |
| Задержка приложения | Как долго выполняется нужная операция? | Причину без системного контекста |
Пример: высокий load без полного CPU
Представим VPS, где одновременно идёт импорт, архивирование и запись резервной копии. Некоторые задачи ждут завершения дисковых операций. Число задач в соответствующем состоянии растёт, хотя CPU не занят вычислениями всё время. Добавление vCPU в таком сценарии может не устранить узкое место.
Это учебная гипотеза, а не описание измеренного сервера. Для подтверждения нужны одинаковый интервал, процессы, состояние диска и прикладная задержка. Не делайте вывод о «медленном хостинге» только по одному снимку top.
Пример: CPU занят, а load выглядит приемлемо
Один длительный однопоточный процесс может упираться в доступное ему выполнение, пока остальные ядра простаивают. Общий процент по всем vCPU скрывает локальное ограничение. Смотрите распределение по ядрам и свойства самой задачи.
Для PHP-приложения увеличение числа работников помогает только при доступных ресурсах и возможности параллелизма. Если каждый worker ждёт одну блокировку базы, добавление процессов увеличит конкуренцию. Если память исчерпана, результатом может стать давление на систему вместо ускорения.
Как собрать пригодный интервал наблюдения
- Запишите точное время, часовой пояс и медленную операцию.
- Сохраните число доступных процессоров и ограничения среды.
- Соберите load, CPU, память, состояния процессов и I/O в тот же интервал.
- Сопоставьте журналы приложения, базы и планировщика.
- Отметьте фоновые операции и изменения конфигурации.
- Повторите наблюдение в обычном режиме и при том же воспроизводимом сценарии.
# Примеры чтения состояния Linux, набор утилит зависит от ОС uptime cat /proc/loadavg getconf _NPROCESSORS_ONLN ps -eo pid,ppid,stat,comm --sort=stat
Не публикуйте полные аргументы процессов без проверки: в них могут оказаться секреты. Для первоначальной классификации обычно достаточно имени, PID и состояния. Подробную диагностику храните в ограниченной области.
Виртуальная среда и ограничения
VPS может иметь ограничения процессорного времени и памяти, которые не сводятся к числу видимых CPU. Контейнерное приложение дополнительно ограничено cgroup. Поэтому полезно понимать, для какой области инструмент показывает статистику: хоста, гостевой ОС или контейнера.
Steal time и признаки конкуренции гипервизора рассматривают вместе с фактической задержкой. Один показатель не является доказательством вины поставщика. Отсутствие доступной метрики тоже не подтверждает отсутствие конкуренции. Сохраняйте границы наблюдения в отчёте.
Не используйте универсальный порог
Совет «load больше числа ядер — срочно менять тариф» слишком груб. Для некоторых вычислительных задач очередь ожидаема, но пользовательская задержка должна укладываться в требования. Для интерактивного сайта даже короткий пик может быть важен, если он блокирует оформление заказа.
Оцените длительность и повторяемость. Значение за минуту выше 15-минутного может указывать на свежий рост; обратное соотношение — на затухание. Однако это сглаженные показатели, которые не восстанавливают точную историю инцидента. Нужен ряд измерений.
Как выбрать действие по установленной причине
При CPU-bound операции рассматривают алгоритм, параллелизм и подходящий CPU. При дисковом ограничении — профиль чтения/записи, расписание копий и свойства хранения. При блокировках БД — запросы и транзакции. При нехватке работников — длительность запросов и общий бюджет памяти.
Меняйте один параметр за раз на стенде и повторяйте ту же операцию. «После увеличения тарифа стало лучше» без исходного сценария не объясняет причину и не показывает, останется ли запас при следующем импорте.
FAQ
Load 4 на 4 vCPU всегда означает норму?
Нет. Нужны состояния задач, длительность и прикладные требования. Само равенство не является критерием приёмки.
Низкий CPU доказывает отсутствие серверной проблемы?
Нет. Задачи могут ждать диск, сеть, блокировку или внешний сервис.
Нужно сразу перезапускать MariaDB?
Сначала соберите доказательства и определите причину. Перезапуск может прервать операции и потерять диагностический контекст.
Вывод
Load average полезен как часть ряда наблюдений. Решение о ресурсах принимают по установленному ограничению и повторяемому результату приложения, а не по одному универсальному числу.
Для смежных задач: VPS для одного WordPress: как подобрать ресурсы по измерениям, Как проверить хостинг: повторяемые измерения и границы выводов, Логи WordPress и PHP: как собрать данные для исправления ошибки.
Источники и дата проверки
Сведения проверены 29.10.2026. Параметры услуги перед заказом нужно сверять повторно. Собственные замеры провайдера и контрольные обращения в поддержку не проводились.
