ゲームラグ白書 › L7 サーバーOS（カーネル）
サーバーの電源管理（C-state・周波数制御）による遅延スパイク CPU power management latency (C-states, frequency scaling)
原因ID so-cstate · 主担当 インフラチーム・サーバーインフラ
図と実験のあるメインページでこのカードを開く →
使われていないCPUコアは、電力を節約するために深い省電力状態（C-state）に入り、周波数も下げます。パケットやタイマーが来ると、復帰して周波数を上げるまでに時間がかかるため、小さなパケットの処理に遅延が加わります。
なぜ OSの周波数制御ポリシー（governor）やBIOSの電源設定が、深いC-stateと低い周波数を許可している → すると 休んでいたコアが深い省電力状態から復帰するたびに最大数百µs遅れ、周波数が低く固定されているとティックの計算自体が遅くなる → 画面では 普段は体感しにくいが、サーバー間の呼び出しが多いと積み重なり、空いているときにかえって応答が遅くなる入力遅延。周波数が低く固定されていると、人が集中したときにティックが遅れてスローモーション
症状 入力遅延 , スローモーション 要因 遅延, ジッター, ストール
誰に起きるか サーバー全体
いつ 常に, ときどきランダムに
担当 主担当 インフラチーム・サーバーインフラ
インフラチームの対応 BIOSの電源設定を性能重視に、OSのgovernorをperformanceに（cpufreqのscaling_governor）、遅延に敏感なサーバーでは深いC-stateを制限（tunedのlatency-performanceプロファイル、PM QoSの/dev/cpu_dma_latency、カーネルパラメータintel_idle.max_cstate）、変更後は同じデータセンター内の往復時間・ティック時間のジッターと消費電力を合わせて比較。
数値の目安 Linux 6.12のintel_idleドライバーにある表によると、IntelのサーバーCPUの浅いC1は復帰に1〜2µs、深いC6は133µs（Skylake-SP）〜290µs（Sapphire Rapids）かかります。1回あたりはわずかですが、1つのリクエストが複数のサーバーを経由すると、その分だけ積み重なります。カーネルは予想されるアイドル時間が長いほど深い状態を選ぶため、パケットがまばらにしか来ない空いたサーバーほど頻繁に起きます。汎用cpufreqのpowersave governorは、許可された範囲で最も低い周波数に固定します（intel_pstateにある同じ名前のアルゴリズムは、負荷に応じて調整します）。
グラフでは 確認箇所 cpupower monitorでコアごとのC-state滞在率と実際の周波数を確認し、/sys/devices/system/cpu/cpu0/cpuidle/以下の各stateのname・latency（復帰にかかるµs）・usage、cpufreqのscaling_governor、tuned-adm activeで現在のプロファイルを確認 該当する場合 空いているときにコアが最も深いC-stateに長くとどまるか、周波数が最低付近に固定されており、performance governor・浅いC-stateに変えると小さなリクエストの往復時間とジッターが減る 該当しない場合 変えても差が数十µs以内なら、この原因は無視してよい。ms単位で跳ねるなら「CPUスチール（仮想マシン）」かほかの層 確認手段 インフラのツールで確認（ゲームコード不要）
もっと詳しく オンプレミスのベアメタルサーバーでは、BIOS（ファームウェア）の電源設定とOSの設定を両方確認します。クラウドでは一部のインスタンスタイプだけがOSからC-state・周波数を変更でき、AWSはデフォルト設定が最大性能寄りなので、ほとんどの場合はそのままで構いません。Red Hat系のtunedにあるlatency-performanceプロファイルは、governorをperformanceにし、PM QoSで浅いC-stateだけを使うようにします。省電力を無効にすると消費電力が増えるため、遅延に敏感なサーバーだけに適用します。
出典 CPU Idle Time Management Linux kernel 省電力状態ごとに復帰時間（exit latency）と最小滞在時間（target residency）があり、予想アイドル時間に合わせて深い状態を選ぶ、sysfsのstateごとのlatency・usage・time、PM QoS（/dev/cpu_dma_latency）とintel_idle.max_cstateで深い状態を制限 drivers/idle/intel_idle.c (Linux v6.12) Linux kernel IntelのサーバーCPUのC-stateごとの復帰時間：Skylake-SP C1 2µs・C1E 10µs・C6 133µs、Ice Lake C6 170µs、Sapphire Rapids C1 1µs・C6 290µs CPU Performance Scaling Linux kernel scaling_governorでgovernorを確認・変更、performanceは許可範囲で最も高い周波数、powersaveは最も低い周波数を要求 intel_pstate CPU Performance Scaling Driver Linux kernel intel_pstateのpowersaveアルゴリズムは、汎用のpowersave governorと違って負荷に応じて調整（schedutil・ondemandに近い） Chapter 2. Getting started with TuneD Red Hat latency-performanceプロファイルは省電力機能を無効にしてgovernorをperformanceにし、PM QoSで浅いC-stateだけを使わせる、tuned-adm activeで現在のプロファイルを確認 tools/power/cpupower/man/cpupower-monitor.1 (Linux v6.12) Linux kernel cpupower monitor：コアごとの周波数と省電力状態の統計 Processor state control for Amazon EC2 Linux instances AWS 一部のインスタンスタイプだけがOSからC-state・P-stateを制御でき、遅延を減らすために変更できる、デフォルト設定は最大性能でほとんどのワークロードに適している、Gravitonは固定周波数のためOSからは制御しない あわせて読みたい原因
同じ層：L7 サーバーOS（カーネル）
同じ症状（入力遅延）を起こすほかの層の原因
図と実験のあるメインページでこのカードを見る