한국어 English 日本語简体中文繁體中文 Deutsch ไทย Tiếng Việt Русский Português (Brasil)Español Bahasa Indonesia

コンテナのCPUスロットリング（CFSクォータ） Container CPU throttling (CFS quota)

原因ID so-cpu-quota · 主担当 インフラチーム・サーバーインフラ · 副担当ゲーム開発チーム・サーバー開発

コンテナにCPU上限をかけると、決まった周期（通常100ms）の中でクォータを使い切った時点から、残りの時間は強制的に止められます（スロットリング）。

なぜ Kubernetesなどで、ゲームサーバーのコンテナにCPU上限（limit）を設定している → すると ティックの計算が集中した瞬間にクォータを使い切り、次の周期まで数十ms停止 → 画面では 平均CPUは低いのにティックが周期的に跳ねて、カクつき・スローモーション

症状: カクつき, スローモーション
要因: ストール, ジッター
誰に起きるか: サーバー全体
いつ: 人が集中したとき, ときどきランダムに
担当: 主担当 インフラチーム・サーバーインフラ · 副担当ゲーム開発チーム・サーバー開発
ゲーム開発チームの対応: ワーカースレッド数をCPU上限に合わせる（ランタイムがホスト全体のコア数分のスレッドを作らないように）。
インフラチームの対応: CPU上限に余裕を持たせるか、上限を外して専用コアを割り当てる、スロットリング回数（nr_throttled）の監視。
数値の目安: 上限2コアのサーバーでスレッド8個が同時に動くと、100ms周期のクォータを25msで使い切り、残りの75msは止まります。
グラフでは: 人数・負荷に連動して上昇 · スロットリング回数（nr_throttled）、サーバーのティック時間
確認箇所: コンテナのcgroupのcpu.statで、nr_throttled・throttled_usec（cgroup v1ではnr_throttled・throttled_time）の増加量をサーバーのティック時間と並べて確認
該当する場合: 平均CPU使用率は上限より低いのにnr_throttled・throttled_usecが増え続け、ティックが跳ねた時刻と重なる
該当しない場合: nr_throttledが増えなければこの原因ではない。仮想マシン自体が待たされているなら「CPUスチール（仮想マシン）」
確認手段: インフラのツールで確認（ゲームコード不要）

出典

CFS Bandwidth Control Linux kernel
周期ごとに割り当てられたクォータを使い切ると次の周期までスレッドが停止（スロットリング）、デフォルトの周期は100ms、nr_throttledの統計
Control Group v2 Linux kernel
cpu.maxは「$MAX $PERIOD」（クォータ、周期）の形式で、デフォルト値は「max 100000」（100ms周期）
Resource Management for Pods and Containers Kubernetes
コンテナのCPU limitは、カーネルがCPUスロットリングで強制するハードリミット

あわせて読みたい原因

同じ層：L7 サーバーOS（カーネル）

同じ症状（カクつき）を起こすほかの層の原因

フレームタイムのスパイク L1 クライアントのゲームプロセス
クライアントのガベージコレクション L1 クライアントのゲームプロセス
メインスレッドでの同期ロード・シェーダーコンパイル L1 クライアントのゲームプロセス
ストレージが遅くアセットストリーミングが間に合わない L1 クライアントのゲームプロセス
大人数の描画負荷 L1 クライアントのゲームプロセス
補間バッファがないか短い L1 クライアントのゲームプロセス
過度な外挿（デッドレコニング） L1 クライアントのゲームプロセス
固定タイムステップの追いつき処理の暴走 L1 クライアントのゲームプロセス

図と実験のあるメインページでこのカードを見る