遊戲 Lag 白皮書 › L9 伺服器遊戲程式
超出 tick 預算 Tick overrun
原因 ID sp-tick-overrun · 主要負責 遊戲開發團隊（伺服器開發） · 協同 基礎設施團隊（伺服器基礎設施）
在含圖解與實驗的完整版中開啟卡片 →
一個 tick 內要做的事超出預算時，伺服器的 tick 週期會拉長，整個區域的遊戲進行變慢，或出現卡頓。
為什麼 一個 tick（例如 50ms）要處理的事超出預算 → 於是 每秒應計算 20 次的遊戲狀態只算了 8 次 → 畫面上 整個區域出現慢動作（依伺服器設計也可能是卡頓），技能反應變慢
- 症狀
- 慢動作, 輸入延遲, 卡頓
- 因素
- 停滯
- 誰會遇到
- 特定地點／頻道, 整個伺服器
- 何時
- 人潮湧入時, 晚間尖峰時段
- 負責單位
- 主要負責 遊戲開發團隊（伺服器開發） · 協同 基礎設施團隊（伺服器基礎設施）
- 遊戲開發團隊要做的事
- 減少昂貴的運算、把 tick 拆給多個執行緒處理、分散人數（頻道）、把 tick 處理時間記錄為指標。
- 基礎設施團隊要做的事
- 把 tick 時間與各核心的 CPU 使用率加入監控與警示；評估單核心效能（時脈）較高的 CPU 或執行個體。
- 數值參考
- 20 tick 伺服器的預算是 50ms，30 tick 是 33ms，60 tick 是 16.7ms。為了因應人潮突然湧入，平時保留餘裕、只用到預算的一半左右比較安全。
- 圖表上
- 隨人數／負載上升 · 伺服器 tick 時間、各 zone／頻道的人數、遊戲執行緒 CPU
- 查看位置
- 把伺服器記錄的 tick 處理時間（p99）、tick 超出預算的次數與各 zone／頻道的人數放在同一張圖表上看。沒有 tick 指標時，用 pidstat -t 1 看單一遊戲執行緒的 CPU 使用率
- 符合的跡象
- 人潮湧入時 tick 時間超出預算（20 tick 時為 50ms），這段期間遊戲執行緒的 CPU 使用率一直貼近 100%
- 不符合的跡象
- tick 超出預算但遊戲執行緒 CPU 偏低時，是等待類的原因（GC 暫停、鎖、同步呼叫）。bcc runqlat 的 run queue 延遲很長時，表示執行緒分配不到 CPU，是 CPU 不足或執行緒過多
- 確認方式
- 需要遊戲伺服器／用戶端的 log 與指標
- 深入了解
- 伺服器 tick 延遲時呈現的樣子依伺服器設計而不同。每個 tick 讓遊戲狀態前進固定時間（例如 50ms）的伺服器，遊戲時間本身會變慢，形成慢動作。依實際經過的時間一次移動到位的伺服器能維持遊戲進行的速度，但封包變得稀疏、每次移動幅度很大，看起來就是卡頓或瞬移。無論哪一種，輸入反應都會變慢。一個遊戲執行緒負責整台伺服器時，整台伺服器都會變慢；每個區域各有執行緒時，只有那個區域變慢。也有像 EVE Online 這樣的遊戲，在大規模戰鬥中刻意把遊戲時間放慢到最多 10 倍（Time Dilation），讓運算跟得上。
- 實際案例
- CCP Games 2014: EVE Online HED-GP 大規模艦隊戰的伺服器過載
出處
- VALORANT's 128-Tick Servers Riot Games
128 tick 伺服器必須在 7.8125ms 內完成一個畫格；依子系統量測伺服器畫格時間，並分配預算管理 - HED-GP Technical Retrospective: What a HED-ache CCP Games
EVE Online 在過載時以 Time Dilation 放慢遊戲時間，下限為 10%（慢 10 倍）；平時節點 CPU 維持在 80% 以下 - Handling variation in time Unity
固定間隔的模擬落後時，會集中執行追趕的步驟，並捨棄超過上限的時間，因此遊戲時間比實際時間流逝得慢 - pidstat(1) — Linux manual page sysstat
加 -t 可一併顯示處理程序所屬各執行緒的統計（CPU 使用率等） - Demonstrations of runqlat, the Linux eBPF/bcc version IO Visor
以直方圖顯示排程器的 run queue 延遲（工作等待分配到 CPU 的時間）
相關原因
同一層：L9 伺服器遊戲程式
同一症狀（慢動作）在其他層的原因
查看含圖解與實驗的完整版卡片