その見方は、多くの実際のケースで非常に誤解を招く可能性があります。
カーネルは、MemAvailableフィールドで利用可能なメモリの見積もりを提供します。この値はとは大きく異なりMemFree + Cachedます。
/ proc / meminfo：利用可能な推定メモリを提供 [カーネル変更の説明、2014]
多くのロードバランシングおよびワークロード配置プログラムは、/ proc / meminfoをチェックして、使用可能な空きメモリの量を見積もります。彼らは通常、「free」と「cached」を合計することでこれを行います。これは10年前は問題ありませんでしたが、今日は間違いであることがほぼ保証されています。
Cachedには、ページキャッシュとして解放できないメモリ（共有メモリセグメント、tmpfs、ramfsなど）が含まれており、ほとんどがアイドル状態のシステムでシステムメモリの大部分を占める可能性のある再生可能なスラブメモリが含まれていないため、誤りですたくさんのファイル。
現在、システムをスワップにプッシュせずに新しいワークロードに使用できるメモリ量は、MemFree、Active（file）、Inactive（file）、SReclaimable、および/からの「低い」ウォーターマークから推定できます。 proc / zoneinfo。ただし、これは将来変更される可能性があり、ユーザー空間は実際にカーネルの内部を認識して空きメモリの量の見積もりを出すことを期待されるべきではありません。/ proc / meminfoでそのような見積もりを提供する方が便利です。将来的に状況が変化しても、1か所で変更すればよいだけです。
...
Documentation / filesystems / proc.txt：
...
MemAvailable：スワップせずに新しいアプリケーションを開始するために使用できるメモリの推定量。MemFree、SReclaimable、ファイルLRUリストのサイズ、および各ゾーンの最低水準点から計算されます。この見積もりでは、システムが適切に機能するためにページキャッシュが必要であること、およびアイテムが使用されているためにすべての再生可能なスラブが再生可能であるとは限らないことを考慮しています。これらの要因の影響は、システムによって異なります。
1. MemAvailableの詳細
上記のように、tmpfsとその他のShmemメモリは解放できず、スワップに移動するだけです。 このスワップ可能なメモリが含まれているため、Cachedin /proc/meminfoは非常に誤解を招く可能性がありShmemます。tmpfsにファイルが多すぎる場合、メモリの多くを占有している可能性があります:-)。 Shmemまた、非常に大きくなる可能性のあるいくつかのグラフィックスメモリ割り当てを含めることができます。
MemAvailable意図的にスワップ可能なメモリは含まれていません。スワップしすぎると、長い遅延が発生する可能性があります。スワップスペースなしで実行することを選択したり、比較的限られた量だけを許可したりすることもできます。
MemAvailable動作を再確認する必要がありました。一見すると、コードはこの違いについて言及していなかったようです。
/*
* Not all the page cache can be freed, otherwise the system will
* start swapping. Assume at least half of the page cache, or the
* low watermark worth of cache, needs to stay.
*/
pagecache = pages[LRU_ACTIVE_FILE] + pages[LRU_INACTIVE_FILE];
pagecache -= min(pagecache / 2, wmark_low);
available += pagecache;
ただし、Shmem「使用済み」メモリとして正しく処理されることがわかりました。tmpfsに1GBのファイルをいくつか作成しました。1GB増加するごとに1GBずつShmem減少MemAvailableします。したがって、「ファイルLRUリスト」のサイズには、共有メモリやその他のスワップ可能なメモリは含まれません。（これらの同じページ数が「ダーティ制限」を計算するコードでも使用されていることに気付きました）。
このMemAvailable計算では、カーネルの「最低水準点」と同等になるように少なくとも十分なファイルキャッシュを保持する必要があることも想定しています。または現在のキャッシュの半分-どちらか小さい方。（これは、再生可能なスラブについても同じ前提です）。カーネルの「最低水準点」は調整できますが、通常はシステムRAMの約2％です。したがって、大まかな見積もりだけが必要な場合は、この部分を無視できます:-)。
firefox約100MBのプログラムコードをページキャッシュにマップして実行している場合、通常はその100MBをRAMに保持する必要があります:-)。そうしないと、せいぜい遅延が発生し、最悪の場合、システムはさまざまなアプリケーション間でスラッシングに費やす時間を費やします。そのMemAvailableため、これにはわずかな割合のRAMを使用できます。それは十分ではないかもしれません、またはそれは寛大すぎるかもしれません。「これらの要因の影響はシステムによって異なります」。
多くのPCワークロードでは、「大量のファイル」に関するポイントは重要ではありません。それでも、ラップトップには現在、8 MBのRAMのうち500 MBの再利用可能なスラブメモリがあります。これはext4_inode_cache（300K以上のオブジェクト）によるものです。最近、ファイルシステム全体をスキャンして、ディスクスペースを使用しているものを見つける必要があったためです。コマンドを使用しましたdf -x / | sort -nが、たとえばGnome Disk Usage Analyzerでも同じことができます。
2. [編集]コントロールグループのメモリ
構築されている「Linuxのコンテナ」と呼ばれるnamespaces、cgroups好みに応じて、様々な他の機能:-)。彼らは、ほぼ完全なLinuxシステムのようなものを実行するのに十分な説得力のある環境を提供するかもしれません。ホスティングサービスは、このようなコンテナーを構築して、「仮想サーバー」として販売することができます:-)。
ホスティングサーバーは、メインラインLinuxにはない機能を使用して「仮想サーバー」を構築することもできます。 OpenVZコンテナーは、メインラインのcgroupより2年前にリリースされ、「beancounters」を使用してメモリを制限する場合があります。したがって、ドキュメントを読んだり、メインラインのLinuxカーネルについて質問したりするだけでは、これらのメモリ制限がどのように機能するかを正確に理解することはできません。 cat /proc/user_beancounters現在の使用量と制限を表示します。 vzubc少しわかりやすい形式で表示します。beancountersのメインページに行名が記載されています。
制御グループには、その内部のプロセスにメモリ制限を設定する機能が含まれています。このようなcgroup内でアプリケーションを実行する場合、システムメモリのすべてがアプリケーションで使用できるわけではありません:-)。では、この場合、どのようにして使用可能なメモリを確認できますか？
このためのインターフェースは、cgroup-v1またはcgroup-v2のどちらを使用するかによって、さまざまな点で異なります。
私のラップトップのインストールではcgroup-v1を使用しています。走れcat /sys/fs/cgroup/memory/memory.statます。ファイルを含む様々なフィールドを示しtotal_rss、total_cache、total_shmem。tmpfsを含むshmemは、メモリ制限にカウントされます。あなたはtotal_rssの逆の等価物として見ることができると思いますMemFree。また、memory.kmem.usage_in_bytesスラブを含むカーネルメモリを表すファイルもあります。（これは明示的に文書化されていませんが、将来の拡張memory.kmem.も含まれているmemory.kmem.tcp.と思います）。再利用可能なスラブメモリを表示するための個別のカウンターはありません。cgroup-v1のドキュメントには、メモリ制限に達してもスラブメモリの再利用はトリガーされないと記載されています。（このドキュメントには「絶望的に古くなっている」という免責事項があり、現在のソースコードを確認する必要があります）。
cgroup-v2は異なります。ルート（トップレベル）cgroupはメモリアカウンティングをサポートしていないと思います。cgroup-v2にはまだmemory.statファイルがあります。すべてのフィールドは子cgroupを合計するため、total_...フィールドを探す必要はありません。fileフィールドがありcacheます。つまり、同じことが行われました。迷惑なことに、rss内部のような全体的なフィールドは表示されませんmemory.stat。個別のフィールドを合計する必要があると思います。再利用可能なスラブメモリと再利用不可能なスラブメモリには別々の統計があります。v2 cgroupは、メモリが不足し始めたときにスラブを再利用するように設計されていると思います。
Linux cgroupは自動的に仮想化/proc/meminfo（またはの他のファイル/proc）を行わないため、マシン全体の値が表示されます。これはVPSの顧客を混乱させます。ただし、名前空間を使用して、特定のコンテナソフトウェアによって偽造され/proc/meminfoたファイルに置き換えることができます。偽の値がどれほど役立つかは、特定のソフトウェアが何をするかによって異なります。
systemdcgroup-v1をコンテナーなどに安全に委任できないと考えています。私はsystemd-nspawncgroup-v1システムのコンテナーの内部を見ました。内部に配置されたcgroupと、そのメモリアカウンティングを確認できます。一方、含まsystemdれているものは、リソースアカウンティング用の通常のサービスごとのcgroupを設定しません。このcgroup内でメモリアカウンティングが有効になっていない場合、コンテナーがそれを有効にできないと思います。
私がcgroup-v2コンテナー内にいると、実際のcgroup-v2システムのルートとは異なって見え、その最上位のcgroupのメモリアカウンティングを見ることができると思います。または、表示できるcgroupでメモリアカウンティングが有効になっていない場合は、メモリアカウンティングsystemd（または同等のもの）を有効にできるように権限が委任されることを期待します。
MemAvailable、それは3.14で追加されました。