再起動後、高いメモリ使用量（3GB）が報告されました。

この問題は、接続追跡テーブルとハッシュテーブルの最大サイズ設定が正しくないために発生することがあります。 Linuxカーネルは、iptables nf_conntrackモジュールの接続テーブルを追跡するために連続ページを割り当てようとします。 conntrack は、物理メモリ不足のために vmalloc にフェイルバックします。

テーブルは確立された接続に基づいて動的に作成されませんが、一部のカーネルパラメータに基づいて完全に割り当てられます。

いくつかの追加の症状が大量に見られることがあります。nf_conntrack: vmalloc に置き換えます。/var/log/messages (または /var/log/kern.log またはその両方) のメッセージです。

この問題は、リンクされたトラックテーブルを簡単に調整し、サイズを小さくすることで簡単に解決できます。システム使用量に応じて適切な調整を行う必要があります。このシステムで専用のネットワークファイアウォールを運用している場合は、接続追跡テーブルを高くする必要がありますが、ネットワーク侵入から保護するためにiptablesを使用すると、接続追跡テーブルははるかに低くなる可能性があります。

接続追跡の調整の詳細については、次を参照してください。https://wiki.khnet.info/index.php/Conntrack_tuning

conntrack -Lシステム値を微調整するには、まず（または）を実行して、システムが開いた接続数を評価できます /sbin/sysctl net.netfilter.nf_conntrack_count。より良いことは、時間の経過とともに接続を追跡する統計を維持することです（ムニンうまくいきました）追跡された最大接続数に基づいて使用してください。この情報に基づいて/etc/sysctl.confを適切に設定できます。

微調整時に追跡テーブルへの接続が維持される期間も確認してください。場合によっては、ネットワーク構成エラーまたはエラーが原因で、conntrackテーブルに偽のデータ接続が含まれることがあります。たとえば、サーバーが決して閉じられていないSYN接続を受信したり、クライアントが突然接続を切断したり、ソケットを長時間開いたままにすることがあります。

第二に、conntrackエントリが正しいことを確認してください。場合によっては、一部のネットワークまたはファイアウォールの設定が正しくないため、conntrack テーブルにゴミがいっぱいになることがあります。通常、これは完全に設定されていない接続項目です。たとえば、サーバーが着信接続のSYNパケットを受信したが、サーバーの応答が常にネットワークのどこかで失われる場合、これが発生する可能性があります。

ランニングを実行すると、これらの値を微調整するときにsysctl -a | grep conntrack | grep timeoutいくつかの洞察が得られます。デフォルトは非常に保守的です。典型的なタイムアウトの場合、600（10分）、確立されたTCP接続（5日）は432000です。システムの使用量とネットワークの動作によっては、conntrackテーブルのアクティブな接続数を減らすために微調整する必要があります。これはより低い値を定義するのに役立ちます。

ただし、conntrackテーブルのサイズを小さくしすぎないように注意してください。それ以外の場合、反対の効果が発生する可能性があります。接続は追跡できないため、iptablesによって削除され、次のメッセージがログファイルに表示され始めます。"カーネル：ip_conntrack：テーブルがいっぱいになり、パケットが破棄されます。"

これが問題であることを確認するには、次の出力を提供します。

cat /proc/sys/net/ipv4/ip_conntrack_max
cat /proc/sys/net/ipv4/netfilter/ip_conntrack_buckets