tuned на Linux VDS: CPU governor, профили performance и powersave

tuned — это демон и набор профилей для Linux, который применяет настройки производительности без ручного редактирования десятков файлов в /sys, /proc и /etc/sysctl.d. Для администратора Linux VDS он удобен тем, что позволяет быстро переключаться между режимами «экономим ресурсы», «выжимаем throughput», «снижаем latency» и так же быстро возвращаться назад, если результат оказался хуже.

Но у VDS есть важная особенность: виртуальная машина не всегда полностью управляет частотой процессора. CPU governor внутри гостевой ОС может отображаться и даже меняться, а реальное распределение частоты, turbo boost, энергопрофиль и лимиты часто остаются на стороне гипервизора и физического узла. Поэтому правильный подход такой: сначала понять, какие knobs доступны именно в вашей Linux VDS, затем включить подходящий performance profile через tuned-adm, после этого измерить эффект на своём приложении.

Главная ошибка — включить performance «на всякий случай» и считать сервер ускоренным. На VDS итог зависит от steal time, лимитов тарифа, соседней нагрузки, типа виртуализации и профиля самого приложения.

Что делает tuned и где тут CPU governor

tuned работает как служба systemd. После запуска демон читает активный профиль и применяет набор настроек: CPU governor, параметры энергосбережения, scheduler-опции, дисковые readahead-настройки, sysctl-параметры, иногда поведение устройств и сетевого стека. В отличие от разрозненных команд в автозагрузке, профиль можно посмотреть, поменять, задокументировать и откатить.

CPU governor — это политика, по которой ядро выбирает частоту CPU. На bare metal часто встречаются performance, powersave, schedutil, ondemand, conservative. На современных системах с intel_pstate или amd_pstate названия и смысл могут отличаться: например, powersave не обязательно означает «минимальная частота всегда», а может быть частью более сложной политики управления производительностью.

На VDS ситуация ещё тоньше. Гостевая ОС видит виртуальные vCPU. Если провайдер отдаёт гостю интерфейс cpufreq, вы сможете проверить и изменить scaling_governor. Если интерфейса нет, tuned всё равно может быть полезен за счёт sysctl, disk/network-настроек и профилей latency, но CPU governor применить не получится. Это не поломка, а нормальное поведение многих виртуальных окружений.

Какие профили tuned полезны на VDS

Набор профилей зависит от дистрибутива и версии пакета, но на серверных системах чаще всего встречаются следующие варианты.

• balanced — универсальный профиль по умолчанию. Хорош для обычного веб-сервера, где нет явной CPU-проблемы.
• virtual-guest — профиль для виртуальных машин. Часто самый разумный старт для VDS, потому что учитывает гостевую среду.
• throughput-performance — профиль для максимальной пропускной способности. Может подойти для сборок, очередей, batch-задач, нагруженных API и баз данных, где важен общий объём выполненной работы.
• latency-performance — профиль для снижения задержек. Интересен для real-time-ish приложений, игровых backend-сервисов, VoIP, WebSocket-шлюзов, но требует внимательного тестирования.
• powersave — режим экономии энергии. На VDS обычно редко нужен для продакшена, но может быть уместен для dev/stage, малонагруженных cron-серверов или лабораторных стендов.

Для типичного LEMP/LAMP-стека на небольшой VDS не стоит начинать с агрессивных latency-настроек. Часто лучше сначала проверить virtual-guest, затем throughput-performance, и только если есть метрики задержек — сравнивать с latency-performance. Если приложение упирается в MySQL, PHP-FPM, диск или сеть, смена governor может почти ничего не дать.

Установка tuned

Перед установкой обновите индекс пакетов и проверьте, что у вас есть права root или sudo. Команды ниже сгруппированы по семействам ОС: добавлять отдельные блоки для систем с одинаковыми командами смысла нет.

Debian и Ubuntu

sudo apt update
sudo apt install tuned

На минимальных образах Debian/Ubuntu пакет может установиться без дополнительных утилит для просмотра частот. Если понадобится cpupower, пакет зависит от версии ядра и дистрибутива, поэтому сначала попробуйте базовые проверки через /sys, описанные ниже.

AlmaLinux, Rocky Linux, CentOS Stream, Oracle Linux, RHEL-based

sudo dnf install tuned
sudo systemctl enable --now tuned

На многих RHEL-based образах tuned уже установлен и включён. Это можно проверить без переустановки пакета.

rpm -q tuned
systemctl status tuned

Fedora

sudo dnf install tuned
sudo systemctl enable --now tuned

Fedora часто получает новые версии ядра и драйверов управления частотой раньше серверных дистрибутивов, поэтому при диагностике обращайте внимание на scaling_driver: поведение intel_pstate, amd_pstate и классического acpi-cpufreq может отличаться.

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

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

Подробнее

Запуск, автозагрузка и базовая проверка через systemd

После установки включите демон и убедитесь, что он стартует без ошибок. Даже если профиль ещё не выбран вручную, tuned может активировать рекомендованный или дефолтный профиль.

sudo systemctl enable --now tuned
systemctl is-active tuned
tuned-adm active
tuned-adm list

Если служба не стартует, начните с журнала systemd. В нём обычно видно, какой плагин не смог применить настройку: CPU, disk, sysctl или другой.

journalctl -u tuned -b --no-pager

Полезная команда — рекомендация профиля. Она не заменяет benchmark, но показывает, как tuned классифицирует окружение.

tuned-adm recommend

На VDS рекомендация часто будет близка к virtual-guest. Это нормальная отправная точка, особенно если сервер выполняет смешанную работу: nginx, PHP-FPM, база данных, cron и фоновые воркеры.

Проверяем, доступен ли CPU governor в вашей VDS

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

ls /sys/devices/system/cpu/cpu0/cpufreq
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

Если файлов нет, команда cat вернёт ошибку о несуществующем пути. Это не означает, что tuned бесполезен: профиль всё ещё может применить часть параметров. Просто CPU governor не будет главным рычагом оптимизации.

Чтобы проверить governor по всем vCPU, удобно пройтись циклом. Команда ниже выводит путь к каждому CPU и текущее значение, если файл существует.

for f in /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor; do echo $f; cat $f; done

Также проверьте steal time. Если st стабильно заметен под нагрузкой, приложение ждёт физический CPU на стороне хоста. В такой ситуации переключение powersave на performance внутри гостя может дать меньше эффекта, чем смена тарифа, уменьшение конкуренции процессов или оптимизация приложения.

top

В top смотрите строку CPU и поле st. Для более спокойного наблюдения можно использовать mpstat из пакета sysstat.

Выбираем профиль: безопасный порядок

Самый практичный сценарий — менять профиль по одному шагу и сразу фиксировать результат. Не переключайте одновременно tuned, параметры PHP-FPM, MySQL, nginx и sysctl: потом будет сложно понять, что именно повлияло на latency или throughput.

1. Запишите текущий профиль и базовые метрики.
2. Включите кандидатный профиль.
3. Перезапустите или прогрейте приложение, если оно чувствительно к кешам.
4. Проведите одинаковый benchmark.
5. Сравните не только среднее значение, но и p95/p99 latency, ошибки и steal time.
6. Откатитесь, если профиль ухудшил хвостовые задержки или стабильность.

Посмотреть текущий профиль:

tuned-adm active

Включить профиль для виртуальной машины:

sudo tuned-adm profile virtual-guest

Включить throughput-oriented performance profile:

sudo tuned-adm profile throughput-performance

Включить профиль для latency:

sudo tuned-adm profile latency-performance

Включить powersave:

sudo tuned-adm profile powersave

Отключить применение профиля:

sudo tuned-adm off

После переключения проверьте, какой профиль активен, и загляните в журнал. Некоторые настройки могут быть пропущены, если ядро или гипервизор их не поддерживает.

tuned-adm active
journalctl -u tuned -b --no-pager

Как понять, применился ли governor

Допустим, вы включили throughput-performance или latency-performance. Теперь проверьте фактический scaling_governor. Не полагайтесь только на сообщение tuned-adm active: оно показывает активный профиль, но не гарантирует, что каждый параметр был применён.

cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq

Если scaling_governor остался прежним, возможны три типовые причины: профиль не задаёт governor для вашего драйвера, гостевая ОС не имеет права менять cpufreq, либо используется драйвер с другой моделью управления производительностью. В этом случае смотрите scaling_driver и журнал tuned.

cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver
journalctl -u tuned -b --no-pager | grep -i cpu

На некоторых VDS вы увидите, что частота выглядит постоянной или условной. Это не обязательно отражает реальную частоту физического ядра. Для виртуальной машины важнее практические метрики: время ответа приложения, число обработанных запросов, p95/p99, CPU steal, load average и очереди в приложении.

Собственный профиль tuned для VDS

Готовые профили хороши для старта, но иногда нужен небольшой профиль поверх базового. Например, вы хотите наследовать virtual-guest, но явно попросить performance governor там, где он доступен. Для этого создайте отдельный каталог в /etc/tuned. Не меняйте файлы в системном каталоге пакета: при обновлении они могут быть перезаписаны.

sudo mkdir -p /etc/tuned/vds-performance

Создайте файл /etc/tuned/vds-performance/tuned.conf:

[main]
summary=VDS profile based on virtual-guest with performance CPU policy
include=virtual-guest

[cpu]
governor=performance
energy_perf_bias=performance
min_perf_pct=100

Активируйте профиль и проверьте результат:

sudo tuned-adm profile vds-performance
tuned-adm active
journalctl -u tuned -b --no-pager

Если в журнале видно, что min_perf_pct или energy_perf_bias не поддерживаются, это не критично. Такие параметры зависят от драйвера CPU и виртуализации. Профиль может частично примениться, а неподдерживаемые опции будут проигнорированы или отмечены предупреждением.

Для latency-oriented сервиса можно сделать отдельный профиль на базе latency-performance. Но перед этим убедитесь, что вы действительно оптимизируете задержку, а не маскируете проблему в приложении: блокировки в базе данных, медленные DNS-запросы, переполненные очереди PHP-FPM или сетевой bufferbloat governor не исправит.

sudo mkdir -p /etc/tuned/vds-low-latency

Создайте файл /etc/tuned/vds-low-latency/tuned.conf:

[main]
summary=VDS low latency profile for measured workloads
include=latency-performance

[cpu]
governor=performance
energy_perf_bias=performance

sudo tuned-adm profile vds-low-latency

Benchmark: как измерять, чтобы не обмануть себя

Benchmark для tuned должен быть ближе к вашей реальной нагрузке. Синтетический CPU-тест полезен, чтобы увидеть грубую разницу, но он не отвечает на вопрос, стал ли быстрее WordPress, Laravel API, PostgreSQL или очередь обработки изображений. Поэтому используйте два уровня: короткий синтетический тест и прикладной тест.

Установите базовые инструменты. Для Debian/Ubuntu:

sudo apt update
sudo apt install sysstat sysbench stress-ng

Для RHEL-based и Fedora:

sudo dnf install sysstat sysbench stress-ng

Снимите исходное состояние:

tuned-adm active
uptime
mpstat 1 5
vmstat 1 5

Простой CPU benchmark через sysbench:

sysbench cpu --threads=2 --time=60 run

Число потоков подставляйте по количеству vCPU или по реальному сценарию. Для VDS на 2 vCPU тест с 16 потоками покажет не «запас мощности», а поведение при переподписке и очередях. Это тоже может быть полезно, но интерпретировать результат нужно отдельно.

Нагрузочный тест с наблюдением за CPU:

stress-ng --cpu 2 --timeout 60s --metrics-brief
mpstat 1 10

Для веб-приложения лучше использовать внешний генератор нагрузки с другого сервера или хотя бы с локальной машины, чтобы benchmark не конкурировал с тестируемым сервисом за те же vCPU. Сравнивайте не только requests per second, но и p95/p99 latency, коды 5xx, timeouts, saturation PHP-FPM, slow query log базы данных.

Минимальный протокол измерения может выглядеть так:

• 5 минут прогрева после смены профиля;
• 3 одинаковых прогона по 1–3 минуты;
• фиксация среднего результата и худшего p95/p99;
• параллельный сбор mpstat, vmstat, логов приложения;
• возврат на исходный профиль и контрольный повтор, если результат подозрительно хороший.

Особенно осторожно относитесь к улучшениям в пределах 1–3%. На VDS такой разброс легко объясняется соседней нагрузкой на хосте, прогревом кешей, фоновой активностью cron, работой дисковой подсистемы или сетевыми колебаниями. Значимым можно считать результат, который повторяется и улучшает именно нужную метрику.

Когда performance помогает, а когда нет

Профиль throughput-performance или custom-профиль с governor=performance может помочь, если нагрузка короткими всплесками упирается в CPU, а governor слишком медленно поднимает производительность. Это встречается у API с резкими пиками, PHP-приложений с тяжёлыми шаблонами, сервисов компрессии, сборщиков ассетов, воркеров изображений, некоторых JVM/Go/Node.js процессов.

Для баз данных эффект неоднозначный. Если запросы реально CPU-bound — например, много сортировок, JSON-обработки, агрегаций, вычислений — performance profile может улучшить throughput. Если же база ждёт диск, блокировки, fsync, сеть или память, governor будет второстепенным. В таких случаях полезнее смотреть iostat, slow query log, индексы, буферный пул, checkpoint-настройки и архитектуру подключений; для PostgreSQL отдельно пригодится разбор пулинга соединений через PgBouncer.

Если узкое место находится в дисковой подсистеме, смена CPU governor почти не поможет. Для VDS с интенсивной записью или большим числом мелких файлов лучше отдельно проверить файловую систему, mount-опции и очереди ввода-вывода — об этом подробнее в материале про настройку ext4 и XFS на VDS.

latency-performance может уменьшить хвостовые задержки, но иногда повышает общее потребление CPU и делает систему менее «мягкой» под смешанной нагрузкой. На маленькой VDS это способно ухудшить ситуацию: один шумный процесс начнёт сильнее конкурировать с nginx, php-fpm или базой. Поэтому для latency-профилей особенно важны лимиты systemd, cgroups и аккуратное разделение сервисов.

powersave редко выбирают для боевого веб-сервера. Но он может быть полезен на тестовой VDS, где важнее минимальная активность, чем скорость реакции. Также его удобно включать временно для лабораторных стендов, которые большую часть времени простаивают. На продакшене powersave стоит применять только после проверки, что p95/p99 не выходят за SLA.

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

Виртуальные серверы с быстрым запуском и гибкой конфигурацией от 390₽ / мес

Доступные локации

Россия Нидерланды

Смотреть тарифы

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

tuned-adm пишет, что профиль активен, но governor не меняется

Проверьте наличие cpufreq-интерфейса и драйвер. Если /sys/devices/system/cpu/cpu0/cpufreq отсутствует, менять governor внутри гостя нельзя. Если интерфейс есть, но governor остаётся прежним, смотрите журнал tuned и список доступных governor.

cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors
journalctl -u tuned -b --no-pager | grep -i governor

После latency-performance вырос load average

Сам по себе load average не всегда проблема, но если одновременно выросли задержки, появились 502/504, увеличились очереди PHP-FPM или базы данных, профиль лучше откатить. Latency-настройки не заменяют контроль конкуренции процессов. Проверьте, кто потребляет CPU, нет ли steal time и не упёрлись ли вы в лимит vCPU.

top
mpstat 1 10
pidstat 1 10

После перезагрузки профиль не сохранился

Проверьте, включена ли служба tuned в автозагрузку, и какой профиль активируется после boot. Обычно выбранный через tuned-adm profile профиль сохраняется, но на кастомных образах автозагрузка может быть отключена.

systemctl is-enabled tuned
systemctl status tuned
tuned-adm active

Benchmark стал лучше, а пользователи жалуются

Синтетический benchmark мог улучшить throughput, но ухудшить хвостовые задержки или работу соседних процессов. Например, CPU-тест показывает больше операций в секунду, а реальное приложение страдает от блокировок, IO wait или очередей. Сравнивайте профиль на пользовательских метриках: TTFB, p95/p99, error rate, время SQL-запросов, длина очередей воркеров.

Откат и аккуратная эксплуатация

Перед экспериментами запишите исходное состояние. Это простая привычка, которая экономит время при инцидентах.

tuned-adm active
systemctl status tuned
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

Если в вашей VDS нет cpufreq-интерфейса, последняя команда вернёт ошибку. В runbook так и запишите: governor недоступен внутри гостя, оцениваем только профиль tuned, sysctl-настройки и прикладные метрики.

Чтобы вернуться на безопасный универсальный профиль, обычно достаточно включить balanced или virtual-guest.

sudo tuned-adm profile virtual-guest

Если нужно полностью выключить управление со стороны tuned:

sudo tuned-adm off
sudo systemctl disable --now tuned

Для продакшена лучше хранить кастомные профили в системе управления конфигурацией: Ansible, Salt, Puppet, Git-репозиторий для /etc или хотя бы документированный runbook. Тогда смена performance profile будет повторяемой операцией, а не ручной магией на одном сервере.

Практический чек-лист для Linux VDS

• Установите и запустите tuned через systemd.
• Проверьте tuned-adm recommend, текущий профиль и список доступных профилей.
• Убедитесь, что cpufreq и scaling_governor доступны внутри VDS.
• Начните с virtual-guest, затем тестируйте throughput-performance или latency-performance.
• Не оценивайте результат без benchmark и пользовательских метрик.
• Следите за steal time: высокий st не лечится governor внутри гостевой ОС.
• Держите быстрый откат на virtual-guest или balanced.
• Для кастомных настроек создавайте профиль в /etc/tuned, а не правьте системные профили пакета.

Итоги

tuned — хороший инструмент для Linux VDS, если использовать его как управляемый механизм профилей, а не как волшебный ускоритель. Он помогает быстро включить performance profile, проверить powersave, поэкспериментировать с latency-performance и централизованно применить CPU governor там, где виртуализация это позволяет.

Лучший результат даёт спокойная методика: зафиксировать исходные метрики, выбрать один профиль, провести benchmark, посмотреть p95/p99 latency, CPU steal и логи приложения, затем принять решение. На одних VDS смена governor заметно сглаживает пики, на других почти не влияет на реальную производительность. И это нормально: в виртуальной среде часть управления CPU находится ниже гостевой ОС.

Если после тестов virtual-guest показывает стабильность, а throughput-performance даёт измеримый выигрыш без ухудшения хвостовых задержек, профиль можно оставлять. Если эффект спорный, выбирайте предсказуемость: для серверной эксплуатации стабильные p95/p99 и понятный откат обычно важнее красивой цифры в синтетическом CPU benchmark.