私のログには次のようなことが頻繁に見られます。
カーネル：ip_conntrack：テーブルがいっぱいで、パケットをドロップしています。
現在、ip_conntrack_maxを65536に設定しています（デフォルト、RHEL5）。
メモリ使用量を念頭に置いて、この値を安全にどれだけ増やすことができますか？このボックスには4GBのRAMがあります。このマシンが提供する機能の1つは、おそらく接続数が多いことを説明する静的コンテンツサーバーとしての機能であり、キャッシュに使用するOSメモリをできるだけ多く保持したいということでもあります。
また、次の2つの違いは何ですか？/ proc / sys / net / ipv4 / netfilter / ip_conntrack_max / proc / sys / net / ipv4 / ip_conntrack_max
どちらを編集する必要がありますか？
ありがとう！
回答:
まず、あなた自身に質問してください：あなたの設定は接続追跡を必要としますか？それが単なるサーバーであり、ファイアウォール/ NATが別の場所で行われている場合は、おそらくconntrackをすべて一緒に無効にすることができます。
次に、conntrackエントリに意味があるかどうかを確認します。一部のネットワークまたはファイアウォールの設定ミスにより、conntrackテーブルがゴミでいっぱいになることがあります。通常、これらは完全には確立されなかった接続のエントリです。これは、たとえばサーバーが着信接続SYNパケットを取得したときに発生する可能性がありますが、サーバーの応答は常にネットワーク上のどこかで失われます。
「ip_conntrack：table full」メッセージがあり、ip_conntrack_maxの増加が必要な唯一のマシン（構成を修正するのではなく）で、ルーターは非常に大きなネットワーク（数千のエンドポイント）に対してNATを実行していました。
conntrackが必要であり、それを実際より大きくする必要があることがわかっている場合は、「テーブルがいっぱい」のメッセージが表示されなくなるまで数を増やします。そして、メモリ使用量を監視します。
conntrackオブジェクトのメモリ割り当てに関するいくつかの統計は、/ proc / slabinfoファイルにあります。
「netfilter」を含むパスは、同じ設定を参照する古い方法です。どちらのファイルも編集できます。
＃cat / proc / sys / net / ipv4 / ip_conntrack_max 655360 ＃cat / proc / sys / net / ipv4 / netfilter / ip_conntrack_max 655360 ＃echo 655361> / proc / sys / net / ipv4 / ip_conntrack_max ＃cat / proc / sys / net / ipv4 / netfilter / ip_conntrack_max 655361