遊戲 Lag 白皮書 › L8 Socket 與協定

阻塞式 I/O 架構 Blocking I/O model

原因 ID sk-blocking-io · 主要負責 遊戲開發團隊（伺服器開發）

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

執行緒在等待某個 socket 時無法做其他事的架構，玩家越多整體就越慢。

為什麼 每條連線各自等待讀寫的方式 → 於是 一條連線的延遲擴散到同一執行緒的其他連線 → 畫面上 同時上線人數越多，所有人都出現慢動作、輸入延遲

症狀

慢動作, 輸入延遲

因素

停滯

誰會遇到

整個伺服器

何時

人潮湧入時, 晚間尖峰時段

負責單位

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

遊戲開發團隊要做的事

改用以 epoll、IOCP、io_uring 為基礎的非同步 I/O。

圖表上

隨人數／負載上升 · 回應時間、執行緒數

查看位置

用 pidstat -w -t 看遊戲伺服器的執行緒數與各執行緒的自願 context switch（cswch/s，為等待資源而停下的次數），並與隨同時上線人數變化的回應時間比較

符合的跡象

同時上線人數越多，回應時間上升得越陡；隨連線數增加的執行緒大多只有自願切換很多，幾乎不使用 CPU（在等 socket）

不符合的跡象

執行緒沒有等待、持續使用 CPU 時，是運算過載（「超出 tick 預算」）

確認方式

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

出處

1. epoll(7) — Linux manual page Linux man-pages
   可擴展到同時監看大量 fd 的 I/O 事件通知
2. I/O Completion Ports Microsoft
   以預先建立的執行緒池處理大量非同步 I/O 的 Windows 做法
3. pidstat(1) — Linux manual page sysstat
   -w 的 cswch/s：為等待資源而主動讓出的自願 context switch；加 -t 可看各執行緒

相關原因

同一層：L8 Socket 與協定

• TCP HOL 阻塞
• TCP RTO 與指數退避
• Nagle 演算法 + 延遲 ACK
• 慢速用戶端造成的阻塞式傳送
• 慢速用戶端（slow consumer）的處理策略
• keepalive 預設值 2 小時
• UDP 封包的 IP 分段
• 可靠 UDP 的重傳設定
• 閒置後的慢啟動（slow start）
• 壅塞控制造成傳送量驟降
• RST 強制關閉造成最後的資料遺失
• SO_REUSEPORT 分配不均
• Windows UDP socket 的 WSAECONNRESET 錯誤

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

• 固定時間步長追趕失控 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）
• 超出 tick 預算 L9 伺服器遊戲程式

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