Tuned vs cpupower vs systemd CPUQuota: управление CPU в Linux без сюрпризов

Когда админ говорит «подкрутил CPU на сервере», за этим обычно скрывается одна из трёх разных задач:

• поменяли частотную политику (cpufreq, cpu governor) — чтобы ядра быстрее выходили на высокую частоту или экономили энергию;
• включили профиль tuned — который трогает не только CPU, но и планировщик, энергосбережение, иногда IRQ, сеть и диски;
• поставили лимит CPU для конкретного сервиса (CPUQuota в systemd) — чтобы «шумный сосед» не съел весь узел.

Эти инструменты не взаимозаменяемы: они отвечают за разные уровни управления. Ниже — практичное сравнение tuned vs cpupower vs systemd CPUQuota, с акцентом на предсказуемость в продакшене.

Карта понятий: что именно вы пытаетесь контролировать

«Производительность CPU» полезно разложить на несколько измерений:

• Частота и реактивность: как быстро CPU повышает частоту при всплеске и как охотно сбрасывает (cpufreq + governor).
• Планирование и энергополитики: C-states, балансировщики, часть параметров планировщика, иногда политика IRQ (частично tuned, частично ядро/BIOS/платформа).
• Доля процессорного времени: сколько CPU-времени разрешено конкретному сервису (cgroups v2 через systemd: CPUQuota, CPUWeight, AllowedCPUs).
• Цель оптимизации: минимальная latency (низкие p95/p99, меньше jitter) или максимальный throughput (больше работы в единицу времени).

Частая ошибка: пытаться решить проблему «сервис съедает все CPU» через governor. Governor влияет на частоты, но не ограничивает долю CPU для процесса. Для изоляции нужны cgroups и лимиты.

cpupower: точечное управление cpufreq и cpu governor

cpupower — набор утилит для управления подсистемой cpufreq. Это хороший выбор, когда вы хотите явно задать cpu governor, ограничить min/max частоты (если поддерживается) и проверить, что реально происходит на уровне драйвера.

Что cpupower реально меняет

• Выбор governor: performance, powersave и другие (зависит от драйвера и ядра).
• Ограничения по частоте (min/max), если это поддерживает текущая реализация cpufreq.
• Диагностику: активный драйвер (например, intel_pstate), доступные политики, текущие частоты.

Быстрая проверка: что с частотами сейчас

cpupower frequency-info

В выводе обычно важнее всего:

• какой активен драйвер (например, intel_pstate);
• какие доступны governor;
• «current policy» и диапазоны частот.

Как переключить governor (и почему названия иногда обманывают)

cpupower frequency-set -g performance

cpupower frequency-set -g powersave

На системах с intel_pstate исторически «powersave» нередко означает «управляемая политика с бустом», а «performance» — более агрессивное удержание частот. На AMD и при acpi-cpufreq семантика может отличаться. В продакшене лучше ориентироваться не на название, а на метрики latency/throughput под вашей реальной нагрузкой.

Когда cpupower — правильный выбор

• Нужно быстро поднять отзывчивость (latency) на выделенном сервере: фиксируете governor и получаете более стабильную реакцию на bursts.
• Нужно снизить энергопотребление/нагрев на не критичных к задержкам задачах: аккуратно выбираете powersave и проверяете, что SLA не страдает.
• Нужно разобраться, почему «пила» частот коррелирует с хвостами p99.

Когда cpupower не поможет

• Если вы хотите ограничить CPU конкретному сервису — это задача cgroups (systemd), а не cpufreq.
• Если вы в VM и гипервизор скрывает реальное управление P-states: в гостевой ОС можно выставить «красиво», но фактическое поведение контролируется хостом.

tuned: профили под latency/throughput и комплексная настройка

tuned — демон и набор профилей, которые переключают группы параметров системы. Его сила в том, что вы применяете не одну «ручку», а связанный набор настроек. Минус — изменения не всегда очевидны, и легко забыть, что именно активировано.

Что tuned делает лучше всего

• Быстро применяет профиль под задачу: низкая latency или высокий throughput.
• Сводит в одну точку управление несколькими подсистемами (не только CPU).
• Упрощает поддержку «эталонной» конфигурации: профиль можно фиксировать в документации/Ansible.

Минимальные команды для контроля tuned

tuned-adm active

tuned-adm list

tuned-adm profile throughput-performance

tuned-adm profile latency-performance

Названия профилей зависят от дистрибутива, но throughput-performance и latency-performance встречаются чаще всего.

latency-performance vs throughput-performance: как выбирать без гадания

• latency-performance — для API, прокси, брокеров, систем с чувствительностью к jitter и хвостам p99.
• throughput-performance — для batch/очередей/сборок, когда важнее «перемолоть» максимум работы.

На практике проверяйте метриками: p95/p99 для latency и RPS/время джоб для throughput. Если у вас типичный веб-стек, полезно дополнительно сверяться с поведением БД и пулера соединений; по теме пулов посмотрите материал про PgBouncer и пул соединений PostgreSQL.

Если вы выбираете, где крутить «низкоуровневую производительность» на сервере, удобнее делать это на предсказуемой платформе. Для проектов, где нужны выделенные ресурсы и контроль над профилями и лимитами, обычно проще работать на VDS.

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

Как понять, что tuned конфликтует с ручными настройками

Типичный сценарий: вы один раз задали governor через cpupower, а через неделю кто-то включил профиль tuned — и частотная политика поменялась. tuned действительно может управлять cpufreq (зависит от профиля).

• Выберите «источник истины»: либо tuned управляет политиками, либо вы фиксируете их вручную и следите, чтобы tuned не трогал cpufreq.
• После смены профиля всегда повторяйте cpupower frequency-info и сверяйте ожидаемое с фактическим.

systemd CPUQuota: лимиты CPU на сервисы через cgroups v2

CPUQuota в systemd — это про ограничение процессорного времени для unit’ов, а не про частоты. На современных дистрибутивах systemd чаще всего работает поверх cgroups v2, и квоты превращаются в лимиты CPU-контроллера на уровне ядра.

Чем CPUQuota отличается от governor и tuned

• CPUQuota ограничивает CPU-время конкретному unit, даже если на хосте включён performance.
• Governor/cpufreq влияют на то, как быстро выполняются инструкции, но не «отрезают» долю CPU у конкретного сервиса.
• tuned может улучшить общее поведение системы, но не заменяет квоты, если ваша задача — изоляция соседей.

Пример: ограничить сервис до 200% CPU

В systemd проценты — доля от одного ядра. То есть 200% означает «в сумме до двух полных ядер».

systemctl edit myservice.service

В drop-in добавьте:

[Service]
CPUQuota=200%

Примените и перезапустите:

systemctl daemon-reload

systemctl restart myservice.service

Как проверить, что квота применена (и что у вас cgroups v2)

systemctl show myservice.service -p CPUQuota -p CPUQuotaPerSecUSec

stat -fc %T /sys/fs/cgroup

Если вторая команда возвращает cgroup2fs, активен cgroups v2.

CPUQuota: где чаще всего «удивляет»

• Нелинейная деградация latency: ограничили CPU веб-воркерам — и p99 резко ухудшился, хотя средняя нагрузка выглядит нормально.
• Квота не равна закреплению: процесс может мигрировать по ядрам; вы ограничиваете суммарное CPU-время, а не «привязываете» к конкретным CPU.
• Фоновая активность (GC, JIT, компакция памяти, cron) начинает конкурировать внутри квоты, что особенно заметно на JVM/Node/Python при bursts.

Что выбрать: практическая матрица решений

Если цель — минимальная latency для API/прокси/брокера

• Начните с tuned профиля latency-performance или фиксированного governor performance через cpupower (выберите один управляющий слой).
• CPUQuota вводите аккуратно: чаще всего сначала ограничивают «шумные» фоновые задачи (бэкапы, индексаторы, обработку медиа).
• Смотрите на p95/p99/p999 и jitter, а не только на среднее время ответа.

Если цель — максимальный throughput (очереди, batch, сборки)

• tuned профиль throughput-performance обычно даёт хороший базовый эффект.
• Governor performance</code уместен, если вы действительно упираетесь в CPU и хотите меньше колебаний частот.</li> <li><code>CPUQuota — рабочий инструмент «контейниризации без контейнеров»: защищает остальную систему от прожорливых задач.

Если цель — изоляция клиентов/сервисов на одном узле

• Ставьте во главу угла cgroups v2 и лимиты systemd: CPUQuota (жёсткий потолок) и/или CPUWeight (справедливость без жёсткого cap).
• Частотная политика (cpupower/tuned) вторична и относится ко всему хосту/VM целиком.

Если вы хостите несколько проектов на одной машине и хотите проще разводить «шумных соседей», для многих задач достаточно виртуального хостинга, а при росте нагрузки — перехода на VDS с явными квотами и профилями.

Виртуальный хостинг для сайтов

Универсальное решение для создания и размещения сайтов любой сложности в Интернете от 95₽ / мес

Подробнее

Комбинации, которые работают (и которые ломают ожидания)

Рабочая комбинация №1: tuned для базовой политики + CPUQuota для шумных сервисов

tuned выставляет системный профиль (latency или throughput), а systemd ограничивает конкретные фоновые unit’ы. Это часто лучший компромисс для узлов со смешанной нагрузкой.

Рабочая комбинация №2: ручной cpupower + systemd CPUQuota (без tuned)

Подходит тем, кому нужна максимальная прозрачность: минимум «магии профилей», максимум явных настроек. Главное — задокументировать, где именно вы фиксируете governor (unit, init-скрипт, cloud-init).

Конфликтная комбинация: tuned + ручной cpupower без договорённости

В лучшем случае получится «перетягивание каната», в худшем — разные результаты после перезагрузок и обновлений. Если используете tuned, не фиксируйте governor отдельно, либо убедитесь, что профиль tuned не меняет cpufreq.

Как измерять эффект правильно: latency и throughput до/после

Чтобы сравнение tuned/cpupower/CPUQuota не превратилось в гадание, держите простой план измерений:

• Latency: p95/p99 (и p999, если важно) по прикладным метрикам или внешнему тесту.
• Throughput: RPS/ops, время выполнения batch, скорость обработки очереди.
• CPU и «упор в лимит»: следите за признаками троттлинга unit’ов по квоте и за общим CPU saturation.

Минимальный набор наблюдений:

uptime

mpstat -P ALL 1

pidstat -u 1

cpupower frequency-info

Если утилит нет, установите sysstat (название пакета зависит от дистрибутива).

Для задач общего «тюнинга хранилища под нагрузку» (что часто проявляется как рост latency и очередь CPU на iowait) может пригодиться отдельный разбор про настройку ext4 и XFS на VDS.

Частые вопросы и грабли в продакшене

Почему CPUQuota «не держит» сервис строго в рамках процента?

Квоты работают по периодам: кратковременные всплески возможны, затем unit будет ограничен. Это ощущается как «рывки» и может ухудшать latency. Если сервис чувствителен к пульсациям, подбирайте квоту экспериментально и проверяйте хвосты p99.

Что важнее для веб-сервера: performance или powersave?

Зависит от профиля нагрузки. При bursty-трафике и требовательном p99 чаще выигрывает performance (или tuned latency-профиль), потому что меньше время разгона частоты. На ровной нагрузке разница может быть небольшой, и тогда важнее изоляция через cgroups и настройки приложения.

В VM есть смысл трогать cpufreq?

Иногда да, но часто реальный контроль у гипервизора. В виртуальной среде главный эффект обычно дают лимиты/веса cgroups и архитектура нагрузки, а не попытки «косметически» управлять governor в гостевой ОС.

Резюме

• cpupower — про cpufreq и cpu governor; хорош для точечных, понятных изменений частотной политики.
• tuned — профили «под задачу» (latency/throughput), меняют больше, чем кажется; отлично, если вы готовы жить по профилям и контролировать их.
• systemd CPUQuota — лимиты CPU через cgroups v2; главный инструмент для изоляции сервисов и контроля «шумных соседей».

Если нужно выбрать один инструмент — выбирайте по цели: частоты (cpupower), системный профиль (tuned) или лимиты сервисов (CPUQuota). Если нужно, чтобы сервер был и быстрым, и предсказуемым, чаще всего выигрывает базовый профиль (tuned или фиксированный governor) плюс аккуратные квоты на фоновые нагрузки.