Какое значение загрузки процессора считается малым, а какое большим?

Анализ загрузки CPU: от низкой до критической

Загрузка центрального процессора (CPU) — один из ключевых метрик производительности и здоровья системы. Однако понятия «малая» и «большая» загрузка — не абсолютные, а ситуационные и контекстные, зависящие от типа системы, её роли, временного интервала и ожидаемого поведения.

Общие ориентиры для интерпретации

1. Низкая (малая) загрузка CPU

• Усреднённое значение: < 30-40%

    *   **Для интерактивных/веб-серверов (например, Nginx, Apache):** Постоянная нагрузка 5-20% часто является нормой, если отклик системы быстр, а очереди процессов нет.
    *   **Для систем баз данных (например, PostgreSQL, MySQL):** Загрузка 10-30% в периоды низкой активности может считаться хорошим показателем.
    *   **Для рабочих станций/ноутбуков:** В состоянии простоя ожидаемы значения 1-10% (фоновые процессы ОС).

    Низкая загрузка обычно указывает на:
    *   Избыточность ресурсов (ресурсы простаивают).
    *   Низкую активность пользователей/трафика.
    *   Возможную проблему, если система **должна** быть под нагрузкой (например, очередь задач растёт, а CPU простаивает — возможна блокировка I/O, сетевая проблема или ошибка конфигурации приложения).

2. Средняя (умеренная) загрузка

• Усреднённое значение: 40-70%

    *   Часто считается «здоровой» рабочей зоной для систем под нагрузкой. Это указывает на активное использование ресурсов без перегрузки.
    *   **Важно смотреть на тренд и максимумы.** Кратковременные пики до 80-90% могут быть нормальными (например, при старте JVM, компиляции).

3. Высокая (большая/критическая) загрузка CPU

• Усреднённое значение: > 70-80% в течение продолжительного времени (минуты/часы)

    *   Это сигнал для глубокого анализа. Система приближается к пределу производительности.

• Критическая загрузка: > 90% постоянно

    *   Система перегружена. Возникают:
        *   Рост **очередей выполнения (run queues)**.
        *   Увеличение времени отклика (**latency**) приложений.
        *   Возможны отказы в обслуживании.

Ключевые нюансы интерпретации

1. Временные интервалы и агрегация Значение 5% и 95% за сутки — ни о чём не говорит. Нужно смотреть перцентили (P95, P99) и графики за разные периоды.

# Пример: анализ нагрузки за последние 10 минут с помощью sar
sar -u 10 60

Вывод покажет %user, %system, %iowait, %idle с интервалом в 10 секунд.

2. Контекст типа нагрузки

• %user (пользовательское пространство): Высокий %user под нагрузкой — часто норма (приложение работает).
• %system (пространство ядра): Высокий %system (например, >30%) может указывать на проблемы с драйверами, сетевым стеком (много мелких пакетов), частым переключением контекста.
• %iowait: Показывает, какую долю времени CPU простаивал в ожидании операций I/O. Высокий %iowait (например, >20-30%) при низкой общей утилизации CPU — чёткий сигнал о проблеме с дисками или сетью, а не о нехватке CPU.

3. Многопроцессорные/многоядерные системы Нагрузка 100% на одно ядро при полном простое остальных — признак неоптимального параллелизма в приложении (single-threaded bottleneck). Смотреть нужно на общую утилизацию всех ядер.

# Просмотр загрузки по ядрам
mpstat -P ALL 2 5

4. Load Average vs. CPU Utilization Это разные, но взаимосвязанные метрики!

• CPU Utilization (%): Мгновенная занятость процессора.
• Load Average (средняя нагрузка): Усреднённое количество процессов, находящихся в состоянии R (Running) или D (Uninterruptible Sleep). Ключевое правило: если Load Average > количества доступных CPU ядер — система перегружена, процессы ждут своей очереди на выполнение.

# Просмотр Load Average (1, 5, 15 минут)
uptime
# 18:45:21 up 30 days,  2:15,  1 user,  load average: 0.82, 1.45, 1.60
# Для 4-ядерной системы 1.60 — это низкая нагрузка. Для 1-ядерной — высокая.

5. Ожидания приложений (SLA/SLO) Главный критерий — не абстрактный процент, а влияние на конечного пользователя или бизнес-процесс. Если при 85% загрузки 95-й перцентиль времени ответа API составляет 50 мс, а SLO — 100 мс, то такая нагрузка приемлема. Если при 60% загрузки перцентиль уже 200 мс — это проблема.

Рекомендации для мониторинга и реагирования

1. Определите базовые линии (baselines) для каждой системы в разное время суток и дни недели. Норма для понедельника утром и воскресенья ночью — разная.
2. Настройте алерты не на статический порог (например, >80%), а на отклонения от baseline (например, с помощью MAD или IQR) и на сочетание метрик (высокий load average + низкий %idle + высокий %iowait).
3. Используйте профилировщики и трассировку для диагностики причин высокой утилизации:

   # Поиск процессов, потребляющих CPU
   top -o %CPU
   # или
   ps aux --sort=-%cpu | head -20
   

4. Помните о "хорошей" и "плохой" нагрузке. Высокая утилизация из-за полезной работы приложения (обработка запросов) — это «хорошая» нагрузка, масштабируйте систему. Высокая утилизация из-за busy-wait циклов, утечек ресурсов или неоптимальных алгоритмов — «плохая», требует исправления кода.

Итог: Значения 5%, 50% или 95% — не являются индикаторами «плохо» или «хорошо» сами по себе. Малая загрузка — это когда система легко справляется с рабочим потоком, соблюдая SLO, и имеет headroom для пиков. Большая (критическая) загрузка — когда производительность деградирует, очереди растут, и система не может обслуживать запросы в ожидаемом объёме и с ожидаемой задержкой. Главный фокус DevOps-инженера — на корреляции метрик CPU с бизнес-логикой и пользовательским опытом.