Если вы когда-нибудь открывали htop или мониторинг сервера и видели «50 % загрузки CPU», то, скорее всего, воспринимали это буквально: половина мощности процессора задействована. Но реальность куда сложнее. В недавней статье Brendan Long убедительно показал: этот показатель не отражает реальной картины, а иногда вводит системных администраторов и инженеров в заблуждение.
⚡ В чём подвох?
Есть как минимум два фундаментальных фактора, которые ломают «линейность» CPU utilization:
- 🧵 Гипертрейдинг. Когда физических ядер не хватает, система начинает распределять нагрузку по логическим потокам. Но потоки не равны ядрам: они делят кеши, ALU и прочие ресурсы. Поэтому «100 % загрузка» может означать совсем не 100 % реальной вычислительной мощности.
- 🚀 Turbo Boost и динамическая частота. Современные CPU увеличивают тактовую частоту, если задействованы только пара ядер, и снижают её при нагрузке на все ядра. В итоге на «50 % CPU» процессор может работать либо быстрее (если активны несколько ядер с бустом), либо медленнее (если активны все ядра на пониженной частоте).
🔬 Эксперимент на Ryzen 9 5900X
Brendan Long использовал stress-ng и провёл серию тестов:
- 🔢 Общие CPU-операции.
- 🧮 64-битные вычисления.
- 🧊 Матричные операции.
Результаты оказались нелинейными: при одинаковых «50 %» загрузки реальная производительность колебалась от 60 % до 100 % от теоретического максимума. И это не баг мониторинга — это особенности архитектуры.
🛠️ Что делать инженеру?
Полагаться только на %CPU — рискованно. Более надёжные практики:
- 📊 Измерять реальную работу. Вместо «%CPU» использовать метрики производительности: bogo-ops, throughput, RPS, обработанные задачи.
- 🧪 Сравнивать с эталоном. Перед эксплуатацией провести собственные бенчмарки, чтобы понимать реальную кривую зависимости «нагрузка → результат».
- 🕵️ Интерпретировать в контексте. 90 % CPU на сервере БД и 90 % на сервере Nginx — разные истории: один может уже троттлить, другой работать на пике.
💭 Моё мнение
Эта тема особенно актуальна в эпоху DevOps и SRE, где мы привыкли к «красивым дашбордам». Но метрика %CPU в них часто превращается в «цифру ради цифры». Я бы сказал, что она сродни «средней температуре по больнице»: полезна для общей картины, но бесполезна для реальной диагностики.
В своей практике я вижу, что грамотный мониторинг должен учитывать и архитектуру CPU, и специфику нагрузки. Например, на сервере Kafka меня интересует не %CPU, а пропускная способность на партиции и задержки обработки. А для ML-инференса важнее FLOPS/latency, чем средняя загрузка процессора.
Именно поэтому метрика %CPU должна быть лишь «индикатором внимания», а не ключевым параметром.
📌 Ссылки: