Текущее состояние cpufreq на сервере смотрится одной командой:
cpupower frequency-info
В выводе — используемый драйвер (intel_pstate, acpi-cpufreq или другой), список доступных governor’ов, аппаратные границы частоты и transition latency — время, за которое ядро способно переключить частоту. Governor по умолчанию на современных серверах с intel_pstate — обычно powersave, и здесь важная тонкость: это не то же самое, что powersave на старом acpi-cpufreq. Там powersave жёстко фиксирует минимальную частоту и не отпускает её без смены governor. Под intel_pstate powersave — динамический режим, близкий по поведению к ondemand: частота сама поднимается под нагрузкой через аппаратный P-state алгоритм (HWP) и опускается в простое.
Проблема не в том, что CPU «застревает» на минимуме — а в задержке самого перехода из простоя в разгон. Для латенси-чувствительной нагрузки (СУБД под синхронной репликацией, HFT-подобные вещи, обработка в реальном времени) даже миллисекунды на раскрутку частоты после короткого простоя между запросами — это дрожание отклика, которое видно на графиках p99. Лечится фиксацией на максимальной частоте:
cpupower frequency-set -g performance
Governor performance держит частоту на максимально разрешённой аппаратно весь время, независимо от загрузки — ценой более высокого энергопотребления и нагрева в простое. Посмотреть список governor’ов, доступных именно на этом драйвере, можно так:
cpupower frequency-info --governors
Важно: cpupower frequency-set меняет состояние только до следующей перезагрузки. Чтобы governor сохранялся, на Debian/Ubuntu правится /etc/default/cpupower (там же задаются минимальная и максимальная частота) и включается cpupower.service:
systemctl enable --now cpupower.service
#linux #perf