CPU нагрузка приложения: формула, примеры и калькулятор

В 2026 году требования к отзывчивости приложений выросли: пользователи ожидают ответ менее чем за 200 мс, а облачные инстансы стали дороже. CPU нагрузка — процент времени, которое процессор тратит на выполнение задач вашего приложения. Если он регулярно превышает 80%, готовьтесь к деградации и сбоям.

Основные метрики:

• User CPU — время на код приложения;
• System CPU — время на системные вызовы (ядро);
• I/O Wait — процессор ждёт диск/сеть (не чистая нагрузка, но важна).

Для измерения используйте: top, htop, mpstat, а в контейнерах — docker stats. Но чтобы планировать ёмкость, нужно считать заранее.

Базовая формула (для однопоточного приложения на одном ядре):

• Requests_per_second (RPS) — сколько запросов в секунду приходит;
• Avg_CPU_Time_per_Request (сек) — сколько времени процессор работает на один запрос (из профайлера);
• Number_of_Cores — количество ядер CPU (ядер, не потоков!).

Если приложение многопоточное, формула усложняется: суммируйте время по всем потокам, но делите на ядра. Подводный камень: не путайте wall-clock time (реальное время) и CPU time (активная работа).

Пример: у вас Go-приложение, обрабатывающее 1000 RPS. Профилирование показало, что каждый запрос потребляет 5 мс CPU. Сервер — 4-ядерный.

Requests_per_second = 1000
Avg_CPU_Time = 0.005 сек
Cores = 4

CPU_Util = (1000 * 0.005) * 100 / 4 = (5) * 100 / 4 = 125%

Результат 125% — нагрузка превышает 100%, значит сервер не справляется. Нужно либо оптимизировать код (снизить CPU Time), либо добавить ядер. Реальный совет: держите запас 30-40%, т.е. для такого RPS нужно минимум 8 ядер.

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

Базы данных: CPU нагрузка часто нелинейна из-за блокировок. Если приложение шлёт 500 параллельных запросов, а БД использует 8 ядер — каждый запрос может ждать блокировку, увеличивая CPU time формально, но не утилизируя ядра. Считайте средний активный запрос.

Очереди (Kafka/RabbitMQ): потребление CPU сильно зависит от размера сообщения и сериализации. Пример: 10 000 сообщений/сек по 1 КБ требуют ~2 мс CPU на сообщение → 20 секунд CPU в секунду, нужно 20 ядер.

Фоновые задачи: их нагрузку добавляйте к пиковой. Если раз в час запускается отчёт, используйте стратегию off-peak или выделенный пул ресурсов.

• Путаница между CPU time и реальным временем: profiler'ы часто показывают wall time. Используйте pprof с опцией -seconds для CPU time.
• Игнорирование I/O Wait: если диск медленный, процессор простаивает, но нагрузка кажется низкой. Меряйте iowait через mpstat.
• Неучтённая конкуренция за кэш: на NUMA-архитектурах не все ядра равны. Используйте алгоритмы привязки к ядру (CPU pinning).
• Линейная экстраполяция: нагрузка часто нелинейна. Например, при увеличении RPS в 2 раза CPU может вырасти в 2.5 раза из-за GC и блокировок.

Совет: снимите профиль нагрузки с помощью wrk или k6 при разных RPS и постройте регрессию.

1. Измерьте текущую нагрузку: top -bn1 | grep 'Cpu(s)'
2. Найдите процесс-виновник: ps aux --sort=-%cpu | head -10
3. Соберите профиль CPU: perf record -g -p PID -- sleep 30
4. Постройте флейм-граф: perf script | FlameGraph/stackcollapse-perf.pl | FlameGraph/flamegraph.pl > flame.svg
5. Оптимизируйте горячие участки: замените тяжёлые вычисления, включите кэш, уменьшите аллокации.

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

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

• Калькулятор CPU нагрузки приложения — введите RPS, среднее CPU время и ядра — получите утилизацию и рекомендации.
• Калькулятор нагрузки на сайт — оценивает необходимое количество серверов для веб-приложений.
• Калькулятор нагрузки на сервер — помогает спланировать ёмкость под конкретные сценарии.

Остальные калькуляторы (финансовые) не по теме, но они есть на сайте.

• Формула: CPU% = (RPS × время запроса × 100) / ядра.
• Норма: держите ниже 80%, запас 30-40%.
• Инструменты: top, perf, pprof.
• Ошибки: не путайте wall time и CPU time; не экстраполируйте линейно.