web-dev-qa-db-ja.com

再起動後に報告される過度に高いメモリ使用量（3 GB）

簡単な問題の説明： Intel Core-2 Q6600上の64ビットGentooは、再起動後に8GBの合計メモリのうち約3GBが使用されたことを報告します。このメモリは、どのプロセスでも要求されておらず、バッファ/キャッシュでも使用されていません。

Context： OOMがソースからオクターブを構築しようとしたときに、OOMがemergeプロセスを強制終了した後、この動作に最初に気付きました。システムが再び応答するようになったとき、どのプロセスでも使用されなかったと報告されている約3GBのメモリが残っていました。 （これが本当に始まりであったかどうかはわかりませんが、以前は気づかなかったかもしれません。）

OOMの考えられる問題に精通していないため、再起動を試みましたが、メモリが再び使用されたと報告されています。

次に、3246.3MBで1つの「アドレスの失敗」エラーを報告したMemcheck86 +を試しました（テストは5回繰り返されました）。 RAMの頻度を下げると、エラーが消えました（テストを3回繰り返しました）。

しかし、私のGentooでは、3GBが使用されていると永続的に報告されており、明確な説明はありません（以下の診断レポートを参照してください）。

私はライブディストリビューション（Parted Magic）も試しましたが、これは明らかに正常に動作します（起動後に約数百の使用済みメモリ）。

考えられる原因または解決策についての提案はありますか？

編集：問題を克服できるようになりましたが、それでも説明できませんでした。これまでに追跡した内容について説明します：

  • シングルユーザーモードで起動した場合、3GBのメモリは使用されません。

  • iptablesを開始すると、3 GBが使用されますが、dmesgは次のように報告します。

    nf_conntrack：vmallocにフォールバックします

  • その後のiptablesの停止はプロセスを元に戻しません。メモリは使用されたままです。

次に、カーネル構成を変更して、nf_conntrackが組み込みではなく、モジュールとしてロードされるようにしました。再起動後、iptablesはfalling back to vmallocメッセージなしで、また3GBを消費せずに起動します。

これをどう説明できるのか、私にはわかりません。カーネル開発者の中には、この動作を正確に引き起こした原因を説明できる人もいるかもしれません。

関連レポート：

enter image description hereenter image description here

linuxmemorygentoo
5
ivan

この問題は、接続追跡テーブルとハッシュテーブルの最大サイズのサイズが正しくないことが原因である可能性があります。 Linuxカーネルは、iptablesnf_conntrackモジュールの接続テーブルを追跡するために連続したページを割り当てようとします。十分な物理メモリがないため、conntrackはvmallocにフェイルバックします。

このテーブルは、確立された接続に基づいて動的に作成されるのではなく、いくつかのカーネルパラメータに基づいて完全に割り当てられます。

いくつかの追加の症状は、/ var/log/messages（または/ var/log）で多数のnf_conntrack：vmalloc。メッセージを見つけることである可能性があります。 /kern.log、またはその両方）。

これは、接続トラックテーブルを微調整してサイズを小さくするだけで簡単に解決できます。システムの使用状況に基づいて、適切なサイジングを行う必要があります。このシステムで専用のネットワークファイアウォールを実行している場合、接続トラックテーブルは高くする必要がありますが、ネットワーク侵入から保護するためにiptablesを使用している場合は、はるかに低くなる可能性があります。

接続追跡チューニングの詳細については、 https://wiki.khnet.info/index.php/Conntrack_tuning を参照してください。

システムの値を微調整するには、最初にconntrack -L（または/sbin/sysctl net.netfilter.nf_conntrack_count）を実行して、システムが開いたままにしている接続の数を評価できます。さらに良いことに、追跡された接続の統計を長期にわたって保持し（ munin はこれを適切に実行します）、追跡された接続の最大数をベースラインとして使用します。この情報に基づいて、それに応じて/etc/sysctl.confを構成できます。

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

次に、conntrackエントリが意味をなすかどうかを確認します。ネットワークまたはファイアウォールの設定ミスが原因で、conntrackテーブルがゴミでいっぱいになることがあります。通常、これらは完全には確立されていない接続のエントリです。それは起こるかもしれません例えばサーバーが着信接続SYNパケットを取得したが、サーバーの応答がネットワーク上のどこかで常に失われたとき。

sysctl -a | grep conntrack | grep timeoutを実行してこれらの値を微調整すると、洞察が得られる場合があります。デフォルト値は非常に控えめです。一般的なタイムアウトの場合は600（10分）、確立されたTCP接続の場合は432000（5日）。システムの目的とネットワークの動作によっては、罰金が必要になる場合があります。 conntrackテーブル内のアクティブな接続の数を減らすように調整されています。これは、より低い値を定義するのに役立ちます。

ただし、逆の効果が生じる可能性があるため、conntrackテーブルのサイズを大きくしすぎないように注意してください。接続は追跡できないためiptablesによってドロップされ、ログファイルに次のようなメッセージが記録され始めます： 'カーネル：ip_conntrack：テーブルがいっぱいで、パケットをドロップしています。'

それが問題であるかどうかを確認するために、次の出力を提供してください。

cat /proc/sys/net/ipv4/ip_conntrack_max
cat /proc/sys/net/ipv4/netfilter/ip_conntrack_buckets
6
Julian Garla