ゲームラグ白書 › L7 サーバーOS（カーネル）
サーバーのconntrackテーブル飽和 conntrack table full
原因ID so-conntrack · 主担当 インフラチーム・サーバーインフラ · 副担当 ゲーム開発チーム・サーバー開発, ゲーム開発チーム・クライアント開発
図と実験のあるメインページでこのカードを開く →
Linuxのファイアウォールがすべての接続を記録する接続追跡（conntrack）テーブルが上限に達すると、新しいパケットを破棄します。
なぜ 接続の殺到や短い接続の繰り返しで、接続の記録が増加 → すると テーブルが満杯になり、新しい接続と一部のパケットを破棄 → 画面では 接続不可、原因不明のパケットロスでワープ
- 症状
- 接続不可・無限ロード, ワープ
- 要因
- パケットロス
- 誰に起きるか
- サーバー全体
- いつ
- 接続直後・メンテ明け, 人が集中したとき
- 担当
- 主担当 インフラチーム・サーバーインフラ · 副担当 ゲーム開発チーム・サーバー開発, ゲーム開発チーム・クライアント開発
- ゲーム開発チームの対応
- サーバー：短い接続を減らす（サーバー間の呼び出しは接続を再利用）。クライアント：接続に失敗したり切れたりしたら、再試行の間隔を広げながらランダムに分散。
- インフラチームの対応
- テーブルサイズ（nf_conntrack_max）を増やす、ゲームのポートは追跡の対象外にする（rawテーブルのNOTRACK）、使用量のアラート。
- 数値の目安
- デフォルトの上限はサーバーのメモリ量に応じて約6万〜26万件です。あふれるとカーネルログに「nf_conntrack: table full, dropping packet」が出力されます。
- グラフでは
- 上限で頭打ち · conntrackのエントリ数（nf_conntrack_count）
- 確認箇所
- sysctlのnet.netfilter.nf_conntrack_count（現在のエントリ数）をnf_conntrack_maxと同じグラフに並べ、dmesgで「nf_conntrack: table full, dropping packet」を探す
- 該当する場合
- nf_conntrack_countがmaxで頭打ちになり、その時刻からカーネルログにtable fullが出ている
- 該当しない場合
- エントリ数がmaxに遠く及ばなければこの原因ではない。AWSインスタンス自体の接続追跡の上限は、「クラウドのPPS上限超過」にあるconntrack_allowance_exceededで確認
- 確認手段
- インフラのツールで確認（ゲームコード不要）
出典
- Netfilter Conntrack Sysfs variables Linux kernel
nf_conntrack_maxのデフォルト値はハッシュバケット数（nf_conntrack_buckets）と同じで、バケット数はメモリサイズで決まる - net/netfilter/nf_conntrack_core.c (Linux v6.12) Linux kernel
デフォルトのサイズは、メモリが1GB超なら65,536で、4GB超（64ビット）なら262,144、満杯になると「nf_conntrack: table full, dropping packet」を記録して破棄 - iptables-extensions(8) — Linux manual page netfilter
rawテーブルのCT --notrackで接続追跡の対象外にする
あわせて読みたい原因
同じ層：L7 サーバーOS（カーネル）
同じ症状（接続不可・無限ロード）を起こすほかの層の原因
図と実験のあるメインページでこのカードを見る