遊戲 Lag 白皮書 › L11 磁碟
伺服器端的延遲載入 Lazy loading on the server
原因 ID dk-lazy-load · 主要負責 遊戲開發團隊（伺服器開發） · 協同 基礎設施團隊（伺服器基礎設施）
在含圖解與實驗的完整版中開啟卡片 →
伺服器在副本、地圖資料第一次被請求時才從磁碟讀取的話，那個 tick 期間所有人都會停住。
為什麼 有人第一次進入副本或地圖 → 於是 伺服器在遊戲執行緒上從磁碟讀取資料 → 畫面上 那台伺服器上的所有人短暫定格
- 症狀
- 定格
- 因素
- 停滯
- 誰會遇到
- 特定地點／頻道, 整個伺服器
- 何時
- 移動中／切換地圖時
- 負責單位
- 主要負責 遊戲開發團隊（伺服器開發） · 協同 基礎設施團隊（伺服器基礎設施）
- 遊戲開發團隊要做的事
- 在伺服器啟動時預先載入、改為非同步載入。
- 基礎設施團隊要做的事
- 剛從快照建立的伺服器，在投入服務前先預熱磁碟（把所有區塊讀過一次），或使用快速快照還原功能。
- 圖表上
- 偶爾隨機飆高 · 伺服器 tick 時間、磁碟讀取
- 查看位置
- 把停住的時間點與遊戲伺服器 log 中副本、地圖的首次進入紀錄對照，看那個瞬間遊戲伺服器的磁碟讀取（pidstat -d 的 kB_rd/s），並用 perf trace --duration 找耗時很久的 read、open 呼叫。若是新開的雲端伺服器，把 EBS 的 VolumeAvgReadLatency 與舊伺服器比較
- 符合的跡象
- 只在第一次進入的瞬間停住，第二次進入同一個地方時不會停住。停住期間遊戲執行緒在等待讀檔
- 不符合的跡象
- 已載入的地圖也一樣停住時，是超出 tick 預算、GC 等其他原因
- 確認方式
- 需要遊戲伺服器／用戶端的 log 與指標
- 深入了解
- 在雲端上，剛從快照（磁碟副本）建立的伺服器，每個第一次讀取的區塊都要從遠端儲存裝置取回，比平常慢得多。如果只有自動擴展新開出來的伺服器第一次進入特別久，就要懷疑是這個原因。
出處
- Initialize Amazon EBS volumes AWS
從快照建立的磁碟區在從 S3 取回區塊期間延遲增加、效能下降；可用 dd、fio 讀取所有區塊預先初始化 - Amazon EBS fast snapshot restore AWS
快速快照還原會提供建立時就已初始化完成的磁碟區，消除首次存取的延遲 - pidstat(1) — Linux manual page sysstat
-d：各處理程序的 kB_rd/s（每秒磁碟讀取量） - perf-trace(1) — Linux manual page perf
--duration：只顯示耗時超過指定 ms 的系統呼叫 - Amazon CloudWatch metrics for Amazon EBS AWS
VolumeAvgReadLatency：1 分鐘平均讀取延遲（Nitro 執行個體）
相關原因
同一層：L11 磁碟
同一症狀（定格）在其他層的原因
查看含圖解與實驗的完整版卡片