ブロッキングI/O構造 Blocking I/O model

原因ID sk-blocking-io · 主担当 ゲーム開発チーム・サーバー開発

1つのソケットを待っている間、スレッドがほかの処理をできない構造では、人が増えるほど全体が遅くなります。

なぜ接続ごとに読み書きを待つ方式 → すると 1つの接続の遅延が、同じスレッドのほかの接続に波及 → 画面では 同時接続数が増えるほど、全体がスローモーション・入力遅延

症状: スローモーション, 入力遅延
要因: ストール
誰に起きるか: サーバー全体
いつ: 人が集中したとき, 夜のピーク時間帯
担当: 主担当 ゲーム開発チーム・サーバー開発
ゲーム開発チームの対応: epoll・IOCP・io_uringベースの非同期I/Oに移行。
グラフでは: 人数・負荷に連動して上昇 · 応答時間、スレッド数
確認箇所: pidstat -w -tでゲームサーバーのスレッド数とスレッドごとの自発的コンテキストスイッチ（cswch/s。資源を待って止まった回数）を確認し、同時接続数に応じた応答時間と比較
該当する場合: 同時接続数が増えるほど応答時間が急激に上がり、接続数に比例して増えたスレッドのほとんどが自発的スイッチばかり多く、CPUはほとんど使っていない（ソケット待ち）
該当しない場合: スレッドが待ちなしでCPUを使い続けていれば、計算の過負荷（「ティックバジェット超過」）
確認手段: インフラのツールで確認（ゲームコード不要）

出典

epoll(7) — Linux manual page Linux man-pages
多数のfdを一度に監視できるよう、スケールするI/Oイベント通知
I/O Completion Ports Microsoft
多数の非同期I/Oを、あらかじめ作ったスレッドプールで処理するWindowsの方式
pidstat(1) — Linux manual page sysstat
-wのcswch/s：資源を待って自ら停止した自発的コンテキストスイッチ、-tでスレッドごと