メッセージキューの滞留 Mailbox / job queue backlog

原因ID sp-queue · 主担当 ゲーム開発チーム・サーバー開発

リクエストが処理速度より速く届いてキューにたまると、後ろのリクエストは数秒後にやっと処理されるか、破棄されます。

なぜリクエストが処理速度より速く到着 → すると キューが長くなり、上限を超えると破棄 → 画面では スキル・取引の反応が遅れるか、不発になる

症状: 入力遅延, 不発・ロールバック
要因: 遅延, パケットロス
誰に起きるか: 特定の場所・チャンネル, 特定の機能だけ
いつ: 人が集中したとき
担当: 主担当 ゲーム開発チーム・サーバー開発
ゲーム開発チームの対応: キュー長の監視、古いリクエストから破棄するポリシー、処理の並列化。
グラフでは: 上限で頭打ち · キュー長・最も古いメッセージの経過時間、毎秒の処理数
確認箇所: サーバーが記録するキューごとの長さ、最も古いメッセージの経過時間、毎秒の到着数・処理数・破棄数。コード側のメトリクスがなければ、ss（またはnetstat）でゲームソケットのRecv-Q（カーネルが受信済みで、プロセスがまだ読んでいない量）
該当する場合: 到着数が処理数を上回っている間、処理数はある値で頭打ちになり、キュー長・経過時間と破棄数が増え続ける
該当しない場合: キューが短く経過時間も小さいのに反応が遅ければ、回線の遅延かティック自体の遅れの側
確認手段: ゲームサーバー・クライアントのログ・メトリクスが必要
実際の事例: 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
処理速度よりリクエストの到着が速いとキューが埋まって遅延が増える、FIFOの代わりにLIFOやCoDelを使い、すでに意味のなくなった古いリクエストを間引く
ss(8) — Linux manual page iproute2
ソケットの統計を表示するツール（netstatと同様の情報）、-pでソケットを使っているプロセスを表示
netstat(8) — Linux manual page net-tools
Recv-Q：接続済みソケットで、ユーザープログラムがまだ読み取っていないバイト数