ゲームラグ白書 › L7 サーバーOS（カーネル）
スレッド過多とコンテキストスイッチ Thread oversubscription, context switching
原因ID so-context · 主担当 ゲーム開発チーム・サーバー開発 · 副担当 インフラチーム・サーバーインフラ
図と実験のあるメインページでこのカードを開く →
コア数よりはるかに多いスレッドを動かすと、OSがそれらを切り替えて実行するだけでCPUを消費します。
なぜ 接続ごとにスレッドを作るなどして、スレッドが数百〜数千個 → すると コンテキストスイッチ（実行するスレッドの切り替え）のコストとキャッシュミスが増加 → 画面では CPUはビジーなのにスループットは低く、ティックがばらついてカクつき・スローモーション
- 症状
- カクつき, スローモーション
- 要因
- ストール, ジッター
- 誰に起きるか
- サーバー全体
- いつ
- 人が集中したとき
- 担当
- 主担当 ゲーム開発チーム・サーバー開発 · 副担当 インフラチーム・サーバーインフラ
- ゲーム開発チームの対応
- コア数に合わせたスレッド数、非同期I/O（epoll・IOCP）。
- インフラチームの対応
- コンテキストスイッチ回数と実行待ちスレッド数（vmstatのcs・r）の監視。
- 数値の目安
- コンテキストスイッチは1回あたり数µsで、その後のキャッシュミスのコストまで含めるとさらに大きくなります。
- グラフでは
- 人数・負荷に連動して上昇 · 毎秒のコンテキストスイッチ数、実行待ちスレッド数
- 確認箇所
- vmstat 1のcs（毎秒のコンテキストスイッチ数）・r（実行中またはCPU待ちの数）をコア数と比較し、pidstat -w -tでゲームサーバーのスレッドごとの自発的（cswch/s）・非自発的（nvcswch/s）コンテキストスイッチを確認
- 該当する場合
- 同時接続数が増えるとrがコア数を大きく上回り、csも急上昇し、非自発的コンテキストスイッチの多いスレッドが数百個ある
- 該当しない場合
- rがコア数以下にとどまればこの原因ではない。自発的なスイッチだけが多ければ、スレッドがロックやI/Oを待っている（「ロック競合」「ブロッキングI/O構造」）
- 確認手段
- インフラのツールで確認（ゲームコード不要）
出典
- Quantifying The Cost of Context Switch (ExpCS 2007) ACM
コンテキストスイッチの直接コストは約3.8µs、キャッシュへの影響まで含めた間接コストは数µs〜1,000µs以上（測定環境での値） - vmstat(8) — Linux manual page procps-ng
cs（毎秒のコンテキストスイッチ数）とr（実行中または実行待ちのプロセス数）の項目 - I/O Completion Ports Microsoft
あらかじめ作ったスレッドプールとIOCPで多数の非同期I/Oを処理し、同時に動くスレッド数をCPUの並行度に合わせる - pidstat(1) — Linux manual page sysstat
-wのcswch/sは資源を待って自ら停止した自発的コンテキストスイッチ、nvcswch/sはタイムスライスを使い切って強制的に切り替えられた非自発的コンテキストスイッチ、-tでスレッドごと
あわせて読みたい原因
同じ層：L7 サーバーOS（カーネル）
同じ症状（カクつき）を起こすほかの層の原因
図と実験のあるメインページでこのカードを見る