最近、サーバーの1つ(Debian Squeeze)が重い負荷の間に応答しなくなるという問題が発生しました。カーネルログを見ると、これが原因だと思います。
kernel: nf_conntrack: table full, dropping packet
私が理解しているように、これはconntrackモジュールであり、接続のステートフルトラッキングを実行し、接続の詳細を格納するために使用されるテーブルがいっぱいであることを報告します。
私が行った調査から、これを軽減する方法は2つあるようです。
テーブルのサイズを大きくします。
システムからモジュールを完全に取り外します。
ただし、どちらも/proc/sys/net/ipv4/ip_conntrack_max
nor /proc/sys/net/ipv4/netfilter/ip_conntrack_max
このマシンに存在します(存在しませんipv4
net
の下のカタログ)。
lsmod
を実行すると、結果が得られません。
だから、私は少し混乱しています-おそらく誰かが私のために状況を明らかにすることができますか?
ありがとうございました
これは経験によるものです-私はこの情報を検証するための調査を行っていません:これと同じエラーがシステムログにあるいくつかのシステムを見ましたそして/proc/sys/net /には何もありませんipv4/ip_conn *または/ proc/sys/net/ipv4/netfilter。理由も知りたいのですが、元の症状の修正を見つけたら、それはそれほど重要ではありません。 ;)
緩和戦略は2つありました。sysctl(ナイーブな短期的アプローチ)を介して制限を増やすことと、追跡される接続の数が非常に多い理由を理解することです。
デフォルトの制限を超えており、問題のサーバーが多数の接続を処理するように設計されていない場合は、制限に達してはいけないのは当然のことです。高い接続追跡要件を持つサービスの良い例は、10万以上のクライアントにサービスを提供する「パブリック」DNSサーバーです。
緩和策は、ログを調べ、DOS/DDOS対策が実施されていることを確認し(たとえば、fail2banを参照)、適切なファイアウォール構成がインストールされていることを確認することです。
Lsmodに関しては、アクティブに見えるがモジュールがリストされていないという状況に遭遇したことはありません。そのような状況がどのように発生するのかはわかりません。
多くの場合、conntrackの設定は/ proc/sys/net/netfilter/nf_conntrack_maxにあります。