web-dev-qa-db-ja.com

MemAvailableがMemFree + Buffers + Cachedよりもはるかに少ないのはなぜですか？

スワップなしで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。

linuxkernelmemory-usagedebugging
2
Mikko Rantalainen

あなたが参照している記事で見たように、MemAvailableに関する一連の計算はすべて、スワッピングを引き起こさずに自由に使用できるメモリの量を計算することを中心に構築されています。 MemAvailable = MemFree-LowWaterMark +（PageCache-min（PageCache/2、LowWaterMark））というMemAvailable番号を実装した 実際のパッチ で確認できます。

この式は、システムのMemAvailableが低い可能性を示しています。これは、ローウォーターマーク（システムが作業領域として必要と考える空きメモリの量）が非常に高いためです。これは、システムがメモリ不足を心配するスワップレス環境では理にかなっています。現在の最低水準点を確認できます。

 $ cat /proc/sys/vm/min_free_kbytes

あなたの場合、これはかなり高いと思います。

Linuxのメモリ管理のほとんどすべてのヒューリスティックは、ある程度のスワップスペースで操作することを前提としています。

2
Kurt Fitzner

これが発生する理由をさらに調査するために実行できるツールはありますか？

不一致は、間違った計算を使用していることが原因である可能性があります。あなたがリンクした答えはこれを強調していませんが、リンクされたコミットメッセージを見てください：

[People]は通常、「free」と「cached」を合計してこれを行います。これは10年前は問題ありませんでしたが、今日は間違いであることがほぼ保証されています。 Cachedには、ページキャッシュとして解放できないメモリ（共有メモリセグメント、tmpfs、ramfsなど）が含まれているため、これは誤りです。

ページキャッシュ（ため息）として解放できないCachedの部分は、/proc/meminfoではShmemとしてカウントされます。

freeを実行して、「共有」列を確認することもできます。

多くの場合、これはマウントされたtmpfsが原因です。 df -h -t tmpfsを確認してください。

0
sourcejedi