ゲームラグ白書 › TCP再送の根本原因

受信サーバーのホストでのパケット破棄 Receiver host drops (ring, softirq, CPU)

原因ID rt-host-drop · 主担当 インフラチーム・サーバーインフラ

図と実験のあるメインページでこのカードを開く →

パケットはサーバーまで届いたのに、NICのリングバッファ（到着したパケットを一時的に入れておくバッファ）があふれたり、カーネルで受信処理を担うコアが飽和したりして破棄されます。

なぜ 接続数の急増・1つのコアに集中した割り込み・仮想マシンのCPUスチール・仮想スイッチの過負荷 → すると リングバッファ（rx_missed_errorsなど、名前はドライバーによって異なる）やカーネルの受信キュー（softnet dropped）で破棄 → 画面では 人が集中すると、サーバー全体で同時に入力の反映が遅れ、一瞬止まる

症状

入力遅延, フリーズ, 早送り, ワープ

要因

パケットロス, ストール

誰に起きるか

サーバー全体

いつ

人が集中したとき

担当

主担当 インフラチーム・サーバーインフラ

インフラチームの対応

ethtool -Sのrx_missed_errorsのような破棄カウンターと/proc/net/softnet_statのdroppedを監視に追加、リングバッファのサイズを増やす（ethtool -G）、RSS・割り込みを複数のコアに分散、ゲームスレッドと受信処理のコアを分離、CPUの余裕を確保、仮想マシンならCPUスチール・仮想スイッチの負荷を確認。

数値の目安

サーバーが受信中に破棄したパケットは、クライアントが送り直します。そのためサーバーの再送メトリクスにはほとんど表れず、ethtool -Sのrx_missed_errorsのような破棄カウンター（名前はドライバーによって異なる）と/proc/net/softnet_statのdroppedに先に現れます。

グラフでは

上限で頭打ち · コアごとのsoftirq使用率、NICの破棄カウンター

確認箇所

ethtool -Sの破棄カウンター（rx_missed_errorsなど、mlx5ではrx_out_of_buffer・rx_discards_phy）、ip -s -s linkのmissed、/proc/net/softnet_statの2列目（dropped）・3列目（time_squeeze）を確認し、mpstat -P ALLでコアごとの%soft（ソフト割り込み処理）を確認。仮想マシンなら%stealも確認

該当する場合

人が集中する時刻に破棄カウンターやsoftnet droppedが増え、受信処理を担うコアの%softが100%近くで頭打ちになる。そのサーバーのすべての接続で同時に入力が遅れる

該当しない場合

サーバーの破棄カウンターが変わらず、再送が特定の地域・通信事業者の接続に集中するなら経路上のパケットロス。サーバーが送ったパケットを経路上で失った場合は、サーバーのnstat TcpRetransSegsが増え、これらのカウンターは変わらない

確認手段

インフラのツールで確認（ゲームコード不要）

出典

1. Interface statistics Linux kernel
   rx_missed_errorsはバッファがなくてホストが受け取れなかったパケット数（/proc/net/devではdropに合算）、ip -s -s linkで確認
2. drivers/net/ethernet/intel/igb/igb_ethtool.c Linux kernel
   ethtool -Sのカウンター名はドライバーが決める（例：igbのrx_missed_errors・rx_no_buffer_count）
3. Ethtool counters Linux kernel
   mlx5ドライバーのrx_out_of_buffer（受信キューにバッファがない）・rx_discards_phy（ポートのバッファ不足で破棄）
4. net/core/net-procfs.c Linux kernel
   /proc/net/softnet_statはCPUごとに1行、16進数で、2列目がdropped、3列目がtime_squeeze
5. Documentation for /proc/sys/net/ Linux kernel
   netdev_max_backlog：カーネルの処理より速くパケットが入ってくるときにためておく受信キューの上限
6. Scaling in the Linux Networking Stack Linux kernel
   RSS：NICが複数の受信キューに振り分け、複数のCPUで処理
7. ethtool(8) — Linux manual page ethtool
   -G（--set-ring）でリングバッファのサイズを変更
8. proc_stat(5) — Linux manual page Linux man-pages
   /proc/statのsteal：仮想化環境で他のOSがCPUを使っていた時間
9. mpstat(1) — Linux manual page sysstat
   mpstat -P ALLでコアごとの使用率、%softはソフト割り込みの処理時間、%stealはハイパーバイザーが別の仮想CPUを処理していたために待たされた時間
10. net/ipv4/proc.c Linux kernel
    nstatに表示されるTcpRetransSegs（Tcp項目のRetransSegs）

あわせて読みたい原因

同じ層：TCP再送の根本原因

• 無線区間のパケットロス
• ボトルネックでのキューあふれ（輻輳によるロス）
• 送信バーストによる浅いバッファのあふれ
• ポリサーによる超過分の破棄
• 物理エラー（不良ケーブル・光モジュール・コネクター）
• デュプレックスの不一致
• ファイアウォール・接続追跡による破棄
• 中間機器の処理上限超過（ファイアウォール・IPS・DDoS対策）
• MTUブラックホール（大きいパケットだけ繰り返し失われる）
• 接続中のNAT・ロードバランサーのマッピング期限切れ
• 経路変更・ECMPの不良経路
• 遅延の急上昇による不要な再送
• 順序の入れ替わりによる不要な高速再送
• ACKの遅れ・消失（上り回線の飽和）
• RTOの設定が環境に合っていない
• thin streamの遅い回復
• 中間機器によるTCPオプションの除去
• ゼロウィンドウ（再送のように見える停止）
• 接続要求（SYN）の再送

同じ症状（入力遅延）を起こすほかの層の原因

• 大人数の描画負荷 L1 クライアントのゲームプロセス
• メインスレッドのパケット処理ボトルネック L1 クライアントのゲームプロセス
• V-Syncとレンダーキュー L1 クライアントのゲームプロセス
• 省電力モード・サーマルスロットリング L2 クライアントのOS・端末
• 同じ端末の他のアプリによる帯域幅の占有 L2 クライアントのOS・端末
• ディスプレイ・入力デバイス・フレーム生成による遅延 L2 クライアントのOS・端末
• Wi-Fiチャンネルの混雑 L3 家庭内ネットワーク
• バッファブロート（ルーターのキュー） L3 家庭内ネットワーク

図と実験のあるメインページでこのカードを見る