容器 CPU 節流（CFS 配額） Container CPU throttling (CFS quota)

原因 ID so-cpu-quota · 主要負責 基礎設施團隊（伺服器基礎設施） · 協同遊戲開發團隊（伺服器開發）

容器設了 CPU 上限時，只要在固定週期（通常是 100ms）內用完配額，剩下的時間就會被強制暫停（節流）。

為什麼 在 Kubernetes 等平台上為遊戲伺服器容器設定 CPU 上限（limit） → 於是 tick 計算集中的瞬間用完配額，暫停數十 ms 直到下一個週期 → 畫面上 平均 CPU 很低，tick 卻週期性飆高，出現卡頓、慢動作

症狀: 卡頓, 慢動作
因素: 停滯, 抖動
誰會遇到: 整個伺服器
何時: 人潮湧入時, 偶爾隨機發生
負責單位: 主要負責 基礎設施團隊（伺服器基礎設施） · 協同遊戲開發團隊（伺服器開發）
遊戲開發團隊要做的事: 讓工作執行緒數符合 CPU 上限（避免 runtime 依主機的全部核心數建立執行緒）。
基礎設施團隊要做的事: 把 CPU 上限設得寬鬆一些，或拿掉上限改配置專用核心；監控被節流的次數（nr_throttled）。
數值參考: 上限 2 核心的伺服器若有 8 個執行緒同時工作，會在 25ms 內用完 100ms 週期的配額，然後暫停 75ms。
圖表上: 隨人數／負載上升 · 節流次數（nr_throttled）、伺服器 tick 時間
查看位置: 將容器 cgroup 的 cpu.stat 中 nr_throttled、throttled_usec（cgroup v1 為 nr_throttled、throttled_time）的增加量與伺服器 tick 時間一起看
符合的跡象: 平均 CPU 使用率低於上限，nr_throttled、throttled_usec 卻持續增加，且與 tick 飆高的時間點重疊
不符合的跡象: nr_throttled 沒有增加就不是這個原因。虛擬機器本身分不到 CPU 時是「CPU steal（虛擬機器）」
確認方式: 用基礎設施工具確認（不需要遊戲程式碼）

出處

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 是 kernel 以 CPU 節流強制執行的硬性上限