Средняя загрузка CPU 4%: сколько стоит ваш запас прочности

MAATRIX

Открываете мониторинг и видите: средняя загрузка процессора за месяц — 4%. Первая мысль обычно одна из двух: «отлично, есть запас на будущее» или «я плачу за железо, которое почти не работает». Обе мысли правильные одновременно, и в этом вся сложность. Низкая средняя загрузка — не диагноз, а симптом, за которым может стоять как разумная страховка от пиков, так и забытая переплата, которую никто давно не пересматривал. Разберёмся, как отличить одно от другого и на чём в итоге можно сэкономить, не потеряв в надёжности.

Почему у сервера в среднем 4% загрузки — это не обязательно ошибка

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

• Пиковая нагрузка сконцентрирована в узких окнах. Интернет-магазин, у которого 90% трафика приходится на несколько часов распродажи, остальное время будет показывать единицы процентов загрузки — и это нормально, если сервер рассчитан именно на пиковые часы.
• Резерв под аварийный сценарий. Если один узел из кластера должен подхватить нагрузку соседа при отказе (failover), в штатном режиме он почти простаивает — это его работа.
• Ночные batch-задачи. Бэкапы, переиндексация, агрегация отчётов — CPU нагружается на 20–40 минут в сутки, всё остальное время простаивает.
• Маркетинговые и сезонные всплески. Чёрная пятница, старт учебного года, сезонная реклама — бизнес осознанно держит мощность про запас на несколько дней или недель в году.
• Ошибка масштабирования при росте. Сервер брали «с запасом на рост», рост случился медленнее плана — и годовой excess остался как есть.

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

Что вы реально платите за простаивающие ядра

Запас прочности — это не абстракция, а конкретная строка в счёте. Вы платите за выделенные vCPU и RAM независимо от того, использует ли их сервер на 4% или на 90% — тариф не пересчитывается автоматически по факту утилизации. Это принципиально отличает аренду сервера от serverless-моделей с оплатой за фактическое потребление: здесь вы покупаете ёмкость, а не потребление.

Что это означает на практике:

• Постоянная переплата, а не разовая. Лишние ядра — это не единовременная трата, а ежемесячная статья расходов, которая накапливается за год в заметную сумму, особенно если серверов несколько.
• Упущенная альтернатива. Деньги, которые уходят на неиспользуемую мощность, могли бы пойти на резервное копирование, второй регион, мониторинг или просто остаться в бюджете.
• Риск незаметности. Переплата за избыточный тариф не создаёт инцидентов, не роняет сайт и не появляется в алертах — поэтому её крайне легко не замечать годами, в отличие от нехватки ресурсов, которая сразу видна по деградации сервиса.
• Асимметрия внимания. Команды почти всегда быстро реагируют на нехватку CPU (сайт тормозит — все смотрят на мониторинг), но почти никогда не реагируют так же быстро на избыток (сайт не тормозит — смотреть некуда).

Здесь же стоит сказать честно: сама по себе покупка запаса — это не расточительность, а страховка. У страховки есть цена, и это нормально — вопрос в том, соразмерна ли цена риску, который она покрывает. Если сервер держит 4% в среднем ради устойчивости к DDoS-атаке или сезонному пику, который случается раз в квартал и стоил бы бизнесу гораздо дороже в случае падения — это рациональная сделка. Если 4% — это просто наследие тарифа, выбранного «на всякий случай» три года назад без пересмотра, это уже не страховка, а забытый автоплатёж.

Как отличить нужный запас от лишнего

Прежде чем что-то резать, стоит понять, откуда взялась цифра. Помогает простой чек-лист:

1. Есть ли у низкой загрузки конкретное объяснение? Если вы можете назвать событие или процесс, ради которого держится резерв (распродажа, отказоустойчивость, batch-обработка) — это осознанный запас. Если объяснение звучит как «ну мало ли» — это повод присмотреться.
2. Когда в последний раз резерв реально использовался? Запас под пиковую нагрузку, который не выбирался в полку хотя бы раз за год-два, либо избыточен, либо рассчитан на сценарий, который стал маловероятным.
3. Соответствует ли резерв текущему масштабу бизнеса, а не тому, что было при заказе сервера? Планы меняются: проект мог не вырасти так, как ожидалось, часть нагрузки могла переехать на другой сервис, часть функциональности — устареть.
4. Что произойдёт, если резерв убрать? Если ответ — «ничего, просто масштабируемся при необходимости», резерв, скорее всего, лишний. Если ответ — «сервис ляжет при следующем пике», резерв нужен, но вопрос в его точном размере.

Ниже — сравнение двух типов сценариев, которые прячутся за одной и той же цифрой на графике:

Как увидеть пики, а не только среднее

Главная методологическая ошибка — судить о нагрузке по одному усреднённому числу. Среднее в 4% может скрывать как ровную низкую нагрузку весь месяц, так и десятиминутные всплески до 95%, которые просто «размылись» в общей статистике. Разница критична: во втором случае снижать резерв опасно, в первом — почти наверняка можно.

Базовые инструменты, которые дают картину точнее среднего:

# Загрузка по каждому ядру в реальном времени
mpstat -P ALL 1

# История загрузки CPU за сутки (если настроен sysstat)
sar -u -f /var/log/sysstat/sa$(date +%d)

# Быстрый снимок нагрузки и очереди процессов
vmstat 1 5

Если сервер уже под Prometheus/Grafana (что и стоит сделать в первую очередь, если пока такого мониторинга нет), картина пиков против среднего смотрится через перцентили, а не среднее:

# Средняя загрузка CPU за 7 дней
avg_over_time(node_cpu_usage_percent[7d])

# 95-й перцентиль — то, что действительно нагружает сервер в пиках
quantile_over_time(0.95, node_cpu_usage_percent[7d])

# 99-й перцентиль — редкие, но реальные всплески
quantile_over_time(0.99, node_cpu_usage_percent[7d])

Именно разрыв между средним и 95–99 перцентилем показывает, для чего на самом деле держится запас: если перцентили близки к среднему — сервер действительно почти всегда простаивает и пиков как таковых нет. Если разрыв большой — резерв реально работает в короткие окна, и это меняет разговор о том, снижать тариф или нет.

Для контейнеризированных нагрузок дополнительно полезен docker stats или docker stats --no-stream в связке с логированием в CSV по cron — это дёшево настраивается и за пару недель даёт честную картину распределения нагрузки без сторонних сервисов. О том, какие метрики вообще стоит снимать с гипервизора и хоста, подробнее в статье про метрики мониторинга гипервизора.

Расчёт: сколько ядер вам действительно нужно

Когда данные о пиках собраны, расчёт нужной мощности превращается из гадания в арифметику, но с одной оговоркой: универсального «правильного» коэффициента запаса не существует — это управленческое решение, зависящее от того, чем вы готовы рискнуть.

Логика расчёта:

1. Возьмите не среднее, а пиковую нагрузку за представительный период (минимум 2–4 недели, с захватом известных пиковых событий, если они бывают реже).
2. Определите, сколько времени сервис может провести в деградации, прежде чем это станет проблемой для бизнеса. Если ответ «ни секунды» — нужен запас, покрывающий пик с достаточным зазором. Если допустима кратковременная просадка отклика — зазор можно держать меньше.
3. Добавьте зазор на рост, но на реальный, ожидаемый в ближайшие месяцы, а не «с потолка на пять лет вперёд» — это самая частая причина хронического переразмеривания.
4. Отдельно учтите время реакции при масштабировании. Если сервер можно увеличить за минуты через панель, зазор может быть меньше — вы всегда успеете отреагировать. Если апгрейд занимает часы или требует миграции, зазор должен быть больше, потому что оперативно среагировать не получится.

Формула в общем виде выглядит так: нужная мощность = пиковая нагрузка × коэффициент запаса, где коэффициент — не константа из учебника, а результат пункта 2–4 выше. Здесь же стоит подробнее посчитать общую стоимость решения — сравнение вертикального масштабирования (один более мощный сервер) и горизонтального (несколько серверов за балансировщиком) разобрано в статье про стоимость масштабирования вверх или вширь. Готовую методику подбора конфигурации под конкретную нагрузку, с формулами и примерами, можно посмотреть в статье как рассчитать конфигурацию сервера под нагрузку.

Гибкое масштабирование вместо постоянного запаса

Самая частая альтернатива «держать резерв всегда» — это не «резать резерв полностью», а сделать его временным вместо постоянного. Идея простая: платить за пиковую мощность только тогда, когда пик действительно происходит, а не 24/7 круглый год.

Практические варианты:

• Ручной или запланированный апгрейд перед известным пиком. Если распродажа или сезонный всплеск предсказуем по датам, тариф можно повышать на несколько дней заранее и возвращать обратно после — большинство панелей управления VPS, включая нашу, позволяют изменить конфигурацию без переустановки ОС за несколько минут.
• Скрипт-триггер по метрике. Простое правило вроде «если 95-й перцентиль загрузки за последний час выше X — уведомить и/или инициировать апгрейд через API» снимает необходимость держать резерв «на всякий случай» постоянно.
• Горизонтальное масштабирование под балансировщиком. Вместо одного крупного сервера с большим запасом — несколько меньших нод, которые добавляются и убираются по факту нагрузки. Это гибче, но добавляет сложность в архитектуру (балансировка, синхронизация состояния), поэтому оправдано не всегда — для небольшого проекта один сервер с разумным запасом часто проще и дешевле в обслуживании.
• Раздельные роли вместо одного «толстого» сервера. Если один сервер несёт и веб, и базу, и фоновые задачи, пиковая нагрузка одного компонента заставляет резервировать мощность под все сразу. Разнесение ролей по разным серверам позволяет резервировать точечно, под тот компонент, который реально пиковый.

Честно: у гибкого масштабирования есть своя цена — операционная сложность. Нужно настроить мониторинг, продумать триггеры, протестировать сценарий апгрейда/даунгрейда так, чтобы он не создавал простой во время самого пика. Для проекта с редкими и предсказуемыми пиками это того стоит. Для проекта, где нагрузка почти всегда ровная и низкая без всплесков, сложность может не окупиться — там правильнее просто один раз пересчитать тариф вниз и не городить автоматику. О том, как незаметно вырастает счёт при отсутствии такого пересмотра, — в статье про счёт за облако, который вырос вдвое без роста нагрузки.

Частые вопросы