執行緒過多與 context switch Thread oversubscription, context switching

原因 ID so-context · 主要負責 遊戲開發團隊（伺服器開發） · 協同基礎設施團隊（伺服器基礎設施）

執行緒數量遠多於 CPU 核心時，OS 會把 CPU 花在輪流切換執行緒上。

為什麼 例如每個連線各開一個執行緒，讓執行緒多達數百～數千個 → 於是 context switch（切換執行中的執行緒）的成本與快取未命中增加 → 畫面上 CPU 很忙，處理量卻很低，tick 忽長忽短，出現卡頓、慢動作

症狀: 卡頓, 慢動作
因素: 停滯, 抖動
誰會遇到: 整個伺服器
何時: 人潮湧入時
負責單位: 主要負責 遊戲開發團隊（伺服器開發） · 協同基礎設施團隊（伺服器基礎設施）
遊戲開發團隊要做的事: 執行緒數對應 CPU 核心數，使用非同步 I/O（epoll、IOCP）。
基礎設施團隊要做的事: 監控 context switch 次數與等待執行的執行緒數（vmstat 的 cs、r）。
數值參考: 一次 context switch 要數 µs，再加上之後的快取未命中成本會更高。
圖表上: 隨人數／負載上升 · 每秒 context switch 次數、等待執行的執行緒數
查看位置: 將 vmstat 1 的 cs（每秒 context switch 次數）、r（正在執行或等待 CPU 的數量）與 CPU 核心數比較，並用 pidstat -w -t 看遊戲伺服器各執行緒的自願（cswch/s）與非自願（nvcswch/s）context switch
符合的跡象: 同時上線人數增加時，r 遠高於核心數，cs 也跟著往上衝，有數百個執行緒出現大量非自願 context switch
不符合的跡象: r 維持在核心數以下就不是這個原因。只有自願切換偏多時，是執行緒在等鎖或 I/O（「鎖競爭」、「阻塞式 I/O 架構」）
確認方式: 用基礎設施工具確認（不需要遊戲程式碼）

出處

Quantifying The Cost of Context Switch (ExpCS 2007) ACM
context switch 的直接成本約 3.8µs，加上快取影響的間接成本為數 µs～1,000µs 以上（依量測環境）
vmstat(8) — Linux manual page procps-ng
cs（每秒 context switch 次數）與 r（正在執行或等待執行的處理程序數）欄位
I/O Completion Ports Microsoft
以預先建立的執行緒池與 IOCP 處理大量非同步 I/O，並讓同時執行的執行緒數符合 CPU 的並行能力
pidstat(1) — Linux manual page sysstat
-w 的 cswch/s 是為了等待資源而主動讓出的自願 context switch，nvcswch/s 是用完時間片段而被強制切換的非自願 context switch；加 -t 可看各執行緒