スワップなしでLinuxワークステーションを実行していて、RAMが不足している場合にいくつかのプロセスを自動的に強制終了する earlyoom
デーモンをインストールしました。 earlyoom
はカーネルのMemAvailable
値を監視することで機能し、使用可能なメモリが十分に少なくなると、重要度の低いプロセスを強制終了します。
これは長い間問題なく機能していましたが、突然、私はMemAvailable
がシステムの他の部分と比較して突然非常に低くなっている状況に直面しています。例えば:
$ grep -E '^(MemTotal|MemFree|MemAvailable|Buffers|Cached):' /proc/meminfo
MemTotal: 32362500 kB
MemFree: 5983300 kB
MemAvailable: 2141000 kB
Buffers: 665208 kB
Cached: 4228632 kB
MemAvailableがMemFree
+ Buffers
+ Cached
よりもはるかに低いことに注意してください。
これが発生する理由をさらに調査するために実行できるツールはありますか?システムパフォーマンスが通常よりも少し悪いと感じ、停止する必要がありましたearlyoom
サービスは、そのロジックがMemAvailable
が安定していない限り機能しません(つまり、ユーザーモードプロセスで使用可能なメモリを正しく記述しているため)。
https://superuser.com/a/980821/100154 によると、MemAvailableは、スワップせずに新しいアプリケーションを開始するために使用できるメモリの推定量です。私にはスワップがないので、これはどういう意味ですか?これは、OOM Killerがトリガーされる前に新しいプロセスが取得できるメモリの量を意味しているはずですか(「スワップがいっぱい」の状況に論理的にヒットするため)。
MemAvailable
> = MemFree
は常にtrueであると想定していました。ここではありません。
追加情報:
インターネットを検索すると、原因はファイルシステムによってサポートされていない開いているファイルであり、その結果、メモリから解放できないことが考えられます。コマンドSudo lsof | wc -l
は653100
を出力するので、手動でそのリストを確認することはできません。
Sudo slabtop
の上部には、
Active / Total Objects (% used) : 10323895 / 10898372 (94.7%)
Active / Total Slabs (% used) : 404046 / 404046 (100.0%)
Active / Total Caches (% used) : 104 / 136 (76.5%)
Active / Total Size (% used) : 6213407.66K / 6293208.07K (98.7%)
Minimum / Average / Maximum Object : 0.01K / 0.58K / 23.88K
OBJS ACTIVE USE OBJ SIZE SLABS OBJ/SLAB CACHE SIZE NAME
4593690 4593656 99% 1.06K 153123 30 4899936K ext4_inode_cache
3833235 3828157 99% 0.19K 182535 21 730140K dentry
860224 551785 64% 0.06K 13441 64 53764K kmalloc-64
515688 510872 99% 0.66K 21487 24 343792K proc_inode_cache
168140 123577 73% 0.20K 8407 20 33628K vm_area_struct
136832 108023 78% 0.06K 2138 64 8552K pid
...
私には普通に見えます。
lsof
の大まかな要約を作成する
$ Sudo lsof | awk '{ print $2 }' | sort | uniq -c | sort -h | tail
6516 1118
7194 2603
7884 18727
8673 19951
25193 28026
29637 31798
38631 15482
41067 3684
46800 3626
75744 17776
virtualBoxインスタンスであるPID 17776をポイントします。 (開いているファイルが多い他のプロセスはChrome、OperaとThunderbirdです)。だから、この問題の主な原因はVirtualBoxだけであるため、後でこの問題の主な原因がVirtualBoxであることを考えても、それほど驚かされません。本当にカーネルを台無しにするもの。
ただし、virtualboxをシャットダウンしてChromeを終了しても、問題は解決しませんOperaおよびThunderbird。
あなたが参照している記事で見たように、MemAvailableに関する一連の計算はすべて、スワッピングを引き起こさずに自由に使用できるメモリの量を計算することを中心に構築されています。 MemAvailable = MemFree-LowWaterMark +(PageCache-min(PageCache/2、LowWaterMark))というMemAvailable番号を実装した 実際のパッチ で確認できます。
この式は、システムのMemAvailableが低い可能性を示しています。これは、ローウォーターマーク(システムが作業領域として必要と考える空きメモリの量)が非常に高いためです。これは、システムがメモリ不足を心配するスワップレス環境では理にかなっています。現在の最低水準点を確認できます。
$ cat /proc/sys/vm/min_free_kbytes
あなたの場合、これはかなり高いと思います。
Linuxのメモリ管理のほとんどすべてのヒューリスティックは、ある程度のスワップスペースで操作することを前提としています。
これが発生する理由をさらに調査するために実行できるツールはありますか?
不一致は、間違った計算を使用していることが原因である可能性があります。あなたがリンクした答えはこれを強調していませんが、リンクされたコミットメッセージを見てください:
[People]は通常、「free」と「cached」を合計してこれを行います。これは10年前は問題ありませんでしたが、今日は間違いであることがほぼ保証されています。
Cached
には、ページキャッシュとして解放できないメモリ(共有メモリセグメント、tmpfs、ramfsなど)が含まれているため、これは誤りです。
ページキャッシュ(ため息)として解放できないCached
の部分は、/proc/meminfo
ではShmem
としてカウントされます。
free
を実行して、「共有」列を確認することもできます。
多くの場合、これはマウントされたtmpfs
が原因です。 df -h -t tmpfs
を確認してください。