遊戲執行緒上的同步呼叫 Synchronous DB / file I/O on the game loop

原因 ID sp-sync-call · 主要負責 遊戲開發團隊（伺服器開發）

在 tick 進行中等待 DB 回應或檔案寫入時，伺服器上整個遊戲進行就會停住同樣長的時間。

為什麼 在 tick 內等待 DB 查詢與儲存、log 寫入、外部 API 呼叫 → 於是 DB 花 100ms，tick 也停住 100ms → 畫面上 每當 DB 或磁碟變慢，整個野外就頓一下

症狀: 定格, 卡頓
因素: 停滯
誰會遇到: 特定地點／頻道, 整個伺服器
何時: 做特定動作時, 偶爾隨機發生
負責單位: 主要負責 遊戲開發團隊（伺服器開發）
遊戲開發團隊要做的事: 把慢的工作（DB 查詢與儲存、log 寫入、外部 API 呼叫）全部改成非同步，結果在下一個 tick 反映（只設逾時的話，等待期間仍會停住）。
數值參考: 即使同一資料中心內的 DB 往返只要 0.5ms，一個 tick 呼叫 100 次就是 50ms，單靠這一項就用光 20 tick 的預算。
圖表上: 偶爾隨機飆高 · 伺服器 tick 時間、DB 查詢延遲
查看位置: 把 tick 時間圖表與 DB 查詢延遲（slow query log 等）、磁碟延遲放在同一條時間軸上看。沒有 tick 指標時，用 bcc offcputime -p 看遊戲執行緒在哪裡等待
符合的跡象: tick 飆高的時間點與 DB、檔案延遲飆高的時間點重疊，遊戲執行緒的等待時間集中在接收 DB 回應、寫入檔案的呼叫堆疊
不符合的跡象: DB 與磁碟延遲平穩、tick 卻飆高時，是 GC 暫停或鎖競爭
確認方式: 需要遊戲伺服器／用戶端的 log 與指標

出處

Designs, Lessons and Advice from Building Large Distributed Systems Google
LADIS 2009 主題演講（Jeff Dean）。同一資料中心內的往返約 0.5ms（500,000ns）
ASP.NET Core Best Practices Microsoft
資料存取、I/O 與耗時的工作應以非同步呼叫；同步阻塞呼叫會導致執行緒池耗盡與回應延遲
Demonstrations of offcputime, the Linux eBPF/bcc version IO Visor
把執行緒停住、離開 CPU 的時間（off-CPU）依呼叫堆疊加總，-p 指定處理程序