訊息佇列積壓 Mailbox / job queue backlog

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

請求進來的速度比處理速度快而在佇列中累積時，排在後面的請求要幾秒後才會處理，或被丟棄。

為什麼 請求抵達的速度比處理速度快 → 於是佇列變長，超過上限就丟棄 → 畫面上 技能、交易反應變慢或被吃掉

症狀: 輸入延遲, 吃指令／回檔
因素: 延遲, 遺失
誰會遇到: 特定地點／頻道, 只有特定功能
何時: 人潮湧入時
負責單位: 主要負責 遊戲開發團隊（伺服器開發）
遊戲開發團隊要做的事: 監控佇列長度、採用優先丟棄舊請求的策略、平行化處理。
圖表上: 碰到上限後持平 · 佇列長度與最舊訊息的停留時間、每秒處理數
查看位置: 伺服器記錄的各佇列長度、最舊訊息的停留時間，以及每秒進入數、處理數、丟棄數。沒有程式碼指標時，用 ss（或 netstat）看遊戲 socket 的 Recv-Q（kernel 已收下但處理程序尚未讀取的量）
符合的跡象: 進入數超過處理數的期間，處理數卡在某個值上不去，佇列長度、停留時間與丟棄數持續增加
不符合的跡象: 佇列很短、停留時間也很短，反應卻很慢時，是線路延遲或 tick 本身的延遲
確認方式: 需要遊戲伺服器／用戶端的 log 與指標
實際案例: CCP Games 2014: EVE Online HED-GP 大規模艦隊戰的伺服器過載

出處

Avoiding insurmountable queue backlogs AWS
Amazon Builders' Library。以等待中訊息的停留時間監控積壓；即時系統先處理新資料（接近 LIFO），有時會丟棄舊訊息
Site Reliability Engineering, Chapter 22: Addressing Cascading Failures Google
請求比處理速度快時佇列會滿、延遲增加；改用 LIFO 或 CoDel 取代 FIFO，清掉已經沒有用的舊請求
ss(8) — Linux manual page iproute2
顯示 socket 統計的工具（資訊與 netstat 類似），加 -p 顯示使用該 socket 的處理程序
netstat(8) — Linux manual page net-tools
Recv-Q：已連線的 socket 中，使用者程式尚未取走的位元組數