遊戲 Lag 白皮書 › L10 記憶體

快取未命中 CPU cache misses

原因 ID mem-cache-miss · 主要負責 遊戲開發團隊（伺服器開發）

在含圖解與實驗的完整版中開啟卡片 →

資料散落在記憶體各處時，CPU 每次都必須到較慢的 RAM 讀取並等待資料。

為什麼 物件透過指標散落各處，存取順序雜亂 → 於是 CPU 快取裡沒有，每次都要從 RAM 讀取（慢 100 倍左右） → 畫面上 做同樣的事，tick 成本卻高出數倍，嚴重時出現慢動作

症狀

慢動作

因素

停滯

誰會遇到

整個伺服器

何時

一直都有, 人潮湧入時

負責單位

主要負責 遊戲開發團隊（伺服器開發）

遊戲開發團隊要做的事

把經常一起使用的資料連續排列（資料導向設計）。

圖表上

一開始就一直偏高 · tick 時間、CPU 使用率

查看位置

對遊戲伺服器處理程序執行 perf stat -d -p PID，量測每週期指令數（insn per cycle）與 L1、LLC 快取未命中，並與 tick 時間、CPU 使用率一起看

符合的跡象

CPU 一直很忙，但 insn per cycle 偏低、LLC 未命中很多。改變資料布局的 build 在相同人數下 tick 時間大幅縮短，即可確定

不符合的跡象

CPU 使用率低但 tick 很慢時，是鎖、I/O 等待這類在 CPU 之外等待的原因

確認方式

用基礎設施工具確認（不需要遊戲程式碼）

出處

1. Designs, Lessons and Advice from Building Large Distributed Systems (LADIS 2009 keynote) Google
   L1 快取 0.5ns、L2 快取 7ns、主記憶體 100ns（以 2009 年為準）：到 RAM 讀取比快取慢一到兩個數量級
2. perf-stat(1) — Linux manual page perf
   -p 會計算執行中處理程序的硬體事件並顯示 insn per cycle；-d 會加上 L1、LLC 資料快取事件

相關原因

同一層：L10 記憶體

• 伺服器 GC 全面暫停
• 腳本引擎的 GC 暫停
• 記憶體配置暴增
• 記憶體洩漏
• GC thrashing（heap 可用空間不足）
• Swap
• 記憶體碎片化
• NUMA 遠端記憶體

同一症狀（慢動作）在其他層的原因

• 固定時間步長追趕失控 L1 用戶端遊戲程式
• 負載平衡器分配不均與健康檢查誤判 L5 資料中心網路設備
• 執行緒過多與 context switch L7 伺服器 OS（kernel）
• 容器 CPU 節流（CFS 配額） L7 伺服器 OS（kernel）
• 伺服器電源管理（C-state、頻率調整）造成延遲飆高 L7 伺服器 OS（kernel）
• 排程工作 L7 伺服器 OS（kernel）
• OS、kernel、驅動程式、韌體更新後的效能變化 L7 伺服器 OS（kernel）
• 慢速用戶端造成的阻塞式傳送 L8 Socket 與協定

查看含圖解與實驗的完整版卡片