本番サーバのCPUガバナー判断｜powersave→performanceの切り替えとレイテンシ・電力の計測検証

CPUガバナーがレイテンシに与える影響——なぜ本番で問題になるのか

クラウドインスタンスや物理サーバに Ubuntu 22.04 / RHEL 9 をデプロイした直後、CPUガバナーが powersave のまま本番投入されているケースは珍しくありません。データセンター側の省エネポリシーやカーネルデフォルトがそのまま引き継がれるためです。

開発・ステージング環境では問題が顕在化しにくい一方、本番でリクエストが集中した瞬間に「突発的なレイテンシスパイク」として現れることがあります。powersave はC-State遷移とP-State制御により、アイドル状態からフル周波数まで数十〜数百マイクロ秒の昇圧遅延を生じさせます。HTTPリクエストの処理時間が数ミリ秒のサービスでは、この遅延が尾を引くかたちでP99レイテンシに影響します。

一方で performance ガバナーは常時最大周波数で動作させるため、消費電力と発熱が増加します。単純に「performance が正解」ではなく、サービスの特性・冗長構成・電力コストを踏まえた判断が必要です。本記事では計測データをもとに切り替えを判断する運用シナリオを、手順から検証・切り戻しまで一本で解説します。

現在のCPUガバナーを把握する——確認コマンドと見るべき指標

まず現状を正確に把握することが出発点です。Linux カーネル 5.x 以降の標準的な確認方法を示します。

# 全コアのガバナーを一覧表示
cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor

# cpupowerを使う場合（linux-tools または kernel-tools パッケージ）
cpupower frequency-info -p

出力が powersave であれば、Intel Speed Step（SpeedStep）や AMD P-State ドライバがアクティブで省電力優先の制御が行われています。performance の場合は常時最大周波数です。

あわせて確認すべき指標があります。

• scaling_min_freq / scaling_max_freq：BIOSや電源設定でハードウェアレベルの上限が設定されている場合、ガバナーを切り替えても周波数が上がらないことがあります。
• cpuinfo_cur_freq：実際にOSが認識している現在の周波数です。
• energy_performance_preference（EPP）：Intel HWP（Hardware-Controlled Performance States）が有効な場合はこちらが実効的な制御点になります。power や balance_performance などの値を持ちます。

EPPが有効な環境では、ガバナーを performance に切り替えるだけでなく EPP も performance に変更しないと、HWPが省電力方向に引き戻してしまいます。これは2020年代以降のIntelサーバ（Icelake世代以降）で特に注意が必要な点です。

# EPPの確認
cat /sys/devices/system/cpu/cpu0/cpufreq/energy_performance_preference

# EPPの変更（全コア）
echo performance | tee /sys/devices/system/cpu/cpu*/cpufreq/energy_performance_preference

ガバナーをperformanceへ切り替える——systemdによる永続化まで

一時的な切り替えは cpupower または sysfs への直接書き込みで行えます。

# cpupowerで全コアを切り替え
cpupower frequency-set -g performance

# または sysfs 経由で直接書き込み
echo performance | tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor

ただしこの変更は再起動で失われます。本番環境で永続化するには以下の方法が現行標準です。

systemd を使った永続化（RHEL 9 / Fedora / Ubuntu 22.04+）

# /etc/systemd/system/cpu-governor.service を作成
[Unit]
Description=Set CPU governor to performance
After=multi-user.target

[Service]
Type=oneshot
ExecStart=/usr/bin/cpupower frequency-set -g performance
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

systemctl daemon-reload
systemctl enable --now cpu-governor.service

Ubuntu の場合、cpufrequtils パッケージを導入して /etc/default/cpufrequtils の GOVERNOR="performance" を設定する旧来の方法も依然として動作しますが、systemdサービス定義のほうが起動順序の制御が明示的で管理しやすいです。

なお RHEL 9 では tuned デーモンが動いているとガバナー設定を上書きすることがあります。tuned-adm active でアクティブなプロファイルを確認し、throughput-performance や latency-performance プロファイルを適用するか、tuned 側でガバナーを明示的に指定するほうが整合性が取れます。

切り替え前後の計測——レイテンシと消費電力を数値で比較する

切り替えの判断は計測データが根拠になります。「なんとなく速くなった気がする」では運用の説明責任を果たせません。以下のアプローチが現場で使われています。

レイテンシ計測

アプリケーションレイヤでの計測が最も実効的です。HTTP APIサービスであれば wrk や hey でリクエストを流し、P50・P95・P99 レイテンシを比較します。

# wrk による負荷テスト（30秒、12スレッド、400接続）
wrk -t12 -c400 -d30s --latency http://localhost:8080/api/endpoint

計算集約型のバッチ処理であれば sysbench の CPU テストが参考値になります。実際の処理時間との相関を確認することが重要です。

# sysbench CPUテスト（素数計算）
sysbench cpu --cpu-max-prime=20000 --threads=8 run

多くの現場での計測事例では、powersave 時と比べて performance では P99 レイテンシが 10〜30% 改善されるケースが報告されています。ただしワークロードの特性（CPU バウンドかI/Oバウンドか）によって効果は大きく異なります。

消費電力の計測

物理サーバであれば IPMI/BMC の電力センサーが利用できます。

# IPMIで電力を取得
ipmitool sdr type "Current"
ipmitool dcmi power reading

ソフトウェアレベルでは Intel RAPL（Running Average Power Limit）が利用できます。powertop や perf stat -e power/energy-pkg/ で CPU パッケージ全体の消費エネルギーを測定できます。

# RAPL経由でエネルギーを測定（5秒間）
perf stat -e power/energy-pkg/ sleep 5

アイドル状態では powersave と performance の差が大きく（20〜40W 程度の差が出ることも）、高負荷時は逆に差が縮小します。電力コストの観点からは、負荷率のプロファイルを把握した上でガバナー戦略を決める必要があります。常時高負荷であれば performance による電力増加は軽微ですが、アイドルが多いサービスでは powersave または schedutil のほうが合理的です。

切り戻しと注意点——本番適用前に確認すべきこと

切り替えは即座に sysfs への書き込みで元に戻せます。systemdサービスを有効にした場合は無効化して再起動確認を行います。

# 即時切り戻し
echo powersave | tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor

# systemdサービスの無効化
systemctl disable --now cpu-governor.service

本番適用前に確認すべき点をまとめます。

• BIOSの電源設定との整合性：BIOS側で「バランス」や「省電力」モードが設定されていると、OS側の設定が上書きされる場合があります。特に HPE iLO や Dell iDRAC では電源ポリシーの確認が必要です。
• 仮想化環境での制限：KVM/QEMU ゲストや AWS EC2 インスタンスでは、ホスト側のガバナー設定がゲストに透過されます。EC2 では scaling_governor は読み取り専用になっており、ガバナー変更は効果を持ちません。クラウドインスタンスでは C-State の無効化（カーネルパラメータ intel_idle.max_cstate=1）が代替手段になることがあります。
• 発熱と冷却の余裕確認：高密度なラックや冷却能力が限られた環境では、performance への切り替えにより熱スロットリングが発生し、逆にスループットが低下するケースがあります。turbostat や sensors（lm_sensors）でコア温度を監視しながら切り替えることを推奨します。

2026年の現行環境における差分——schedutil・AMD P-State・クラウドの現状

2026年時点では、powersave や performance の二択だけでなく schedutil ガバナーの採用が広がっています。schedutil はカーネルのスケジューラ情報（CPU使用率の瞬間的な変動）をもとに周波数を動的調整するもので、レイテンシと省電力のバランスが powersave より優れています。Ubuntu 24.04 LTS や RHEL 10 ではデフォルトガバナーに採用されている構成も多く、powersave から切り替える際の選択肢として検討する価値があります。

AMD の第4世代 EPYC（Genoa）以降では amd_pstate ドライバが主流となり、従来の acpi-cpufreq ベースの制御とは動作モデルが異なります。amd_pstate=active モードでは EPP をフル活用した自律的な制御が行われるため、ガバナーを performance にしつつ EPP を performance に設定するアプローチが推奨されます。

# AMD P-State のモード確認
cat /sys/devices/system/cpu/amd_pstate/status
# → active / passive / guided のいずれか

# activeモードでのEPP設定
echo performance | tee /sys/devices/system/cpu/cpu*/cpufreq/energy_performance_preference

クラウド環境では、AWS Graviton3/4（ARM Neoverse）を使うインスタンスが増えており、これらでは cpufreq サブシステム自体が存在しないことがあります。ARM の周波数スケーリングはプロセッサファームウェア側で管理されるため、OS レイヤでのガバナー操作は非適用となります。このような環境では C-State の調整やワークロードの配置戦略（CPU-pinning など）が有効なチューニング手段です。

要点として、CPUガバナーの判断は「performance に変えれば速い」という単純な話ではなく、ワークロード特性・電力コスト・仮想化/クラウド環境の制約・最新ドライバの動作モデルをそれぞれ把握した上での意思決定が求められます。計測→切り替え→再計測のサイクルを短く回せる環境を整えておくことが、本番での安全な判断につながります。