私はカーネル4.3.3-hardened-r4を使ってGentoo Hardened AMD64を実行しています。私のシステムはwpa_supplicant、cron、DHCPなどのいくつかの基本デーモンだけを実行し、XセッションはWindowmaker、GKrellM、xtermのみを開いたので、時間の経過とともにLinuxは約8〜8時までますます多くのRAMを消費し始めました。 RAMとカーネルパニック誘発。これは、LinuxがバッファおよびファイルシステムキャッシュのRAM使用量を報告することとは何の関係もありません。これは、top、htop、およびGKrellMがすべてこれを考慮し、プロセスが実際にどのくらいのRAMを使用しているかを示すためです。最近まで、私はこれが私のBitcoin Coreクライアントに接続していると思いましたが、そうではありませんでした。 （私はLinuxシステムの起動時に誤ってアプリケーションを実行しました。）
emerge -NDu --with-bdeps=y @world場合によっては、アップデート全体がリリースされたときにRAMの使用量が突然正常に戻ることがわかりましたが、（）この回避策を再現できませんでした。
これまで、次の修正を試しました。
vm.zone_reclaim_mode=1私のカーネルでNUMAサポートをコンパイルし（Gentooのgenkernelはデフォルトでそれを有効にしません）、私のsysctlに追加します。役に立たない。- 私はsysctlに追加されてい
vm.drop_caches=1ません。 - tmpfsのインストールがいっぱいであることを確認してください。私のtmpfsマウントは、1MBを超えるファイルシステム使用量をほとんど記録しません。
この動作の証拠は、次のスクリーンショットで見ることができます。
付録I：その中で実行される唯一のメモリ消費プロセスはFirefox、GKrellm、Xであり、Linuxはほぼ3GBのコアを消費しました。 メモ:ここではスワップスペースを有効にしていません（内蔵ハードドライブが古くて遅いため、USB 3.0外付けハードドライブにあります）。ただし、スワップスペースが有効になっていても、Bitcoin Coreを8時間以上オンにしてもOOMが発生します。カーネルパニック走る。
添付B：htopとGKrellmに欠陥がある場合は、topとして再確認しました。同じ結果。
添付C：私のtmpfsマウント使用統計、私の出力freeと私のコンテンツ/proc/meminfo ここで見つけることができます。
この投稿は最近の調査結果を反映するためにたくさん編集されました。古い投稿は以下にあります。このペーストビンはここにあります。。
ベストアンサー1
メモリサポートなどのSHMベースのインストールはありますか/tmp？/var/tmpプロセスが終了した後も一時ファイルが生成される可能性があり、これらのファイルはメモリを消費します。これらのファイルは、削除されるかシステムが再起動されるまでメモリに残ります。マウント/etc/fstabとmounttmpfsエントリを確認してください。
また、一時ディレクトリに大きなファイルが生成される可能性があるため、ログの回転を確認してください。 systemdを使用している場合は、ログを消去することをお勧めします。たとえば、
journalctl --vacuum-size=500M