実行すると、cat /proc/meminfo上部に次の3つの値が表示されます。
MemTotal: 6291456 kB
MemFree: 4038976 kB
Cached: 1477948 kB
私が知る限り、「Cached」値はLinuxシステムによって生成されたディスクキャッシュであり、アプリケーションがより多くのRAMを必要とする場合はすぐに解放されるため、LinuxはMemFreeとCachedの両方がゼロになるまでメモリが不足しません。
残念ながら、/proc/meminfoは "MemAvailable"を報告しません。それはおそらく仮想サーバーで実行されているからです。 （カーネルバージョンは4.4です。）
したがって、すべての実用的な目的のためにアプリケーションで使用可能なRAMはMemFree + Cachedです。
この見方は正しいですか？
答え1
多くの実際のケースでは、これらの見解は非常に誤解を招く可能性があります。
カーネルは現場で利用可能なメモリの見積もりを提供しますMemAvailable。この値はとは大きく異なりますMemFree + Cached。
/proc/meminfo: 利用可能なメモリ推定値を提供します。[カーネル変更ノート、2014]
多くのロードバランシングおよびワークロードデプロイメントプログラムは/proc/meminfoをチェックして、使用可能なメモリ量を推定します。通常、「無料」と「キャッシュ」を追加してこれを行いますが、これは10年前は大丈夫でしたが、今日はほとんど間違いありません。
Cachedには、共有メモリセグメント、tmpfs、ramfsなどのページキャッシュで解放できないメモリが含まれており、ほとんどのアイドルシステムでほとんどのメモリを占有できる回収可能なスラブメモリが含まれていないため、これは間違っています。システムメモリのファイル。
現在、新しいワークロードに使用できるメモリ量は、MemFree、Active（ファイル）、Inactive（ファイル）、SReclaimable、および/または「低」透かしに基づいてシステムをスワップすることを強制することなく推定できます。プロセス/地域情報。ただし、これは将来変更される可能性があり、ユーザースペースは実際に使用可能なメモリー量を見積もるためにカーネルの内部を知ることを期待してはなりません。これらの推定値を/ proc / meminfoに提供する方が便利です。未来に状況が変わるならば私たちはただ一つだけ変えればいいのです。
...Documentation/filesystems/proc.txt:
...
MemAvailable: 交換なしで新しいアプリケーションを起動するために使用できるメモリ量の見積もりです。 MemFree、SReclaimable、ファイルのLRUリストサイズ、および各地域の最低透かしに基づいて計算されます。この見積もりは、システムが正常に動作するためにいくつかのページキャッシングが必要であること、およびプロジェクトが使用されているときにすべての回収可能スラブが回収可能ではないことを考慮しています。これらの要因の影響はシステムによって異なります。
1.MeM利用可能な詳細
上記のように、tmpfsやその他のShmemメモリは解放できず、スワップにのみ移動できます。Cachedこれにはスワップ可能なメモリが含まれているため、誤解を招く可能性があります。 tmpfsにファイルが多すぎると、メモリを大量に消費する可能性があります。 :-).また、一部を含めることができます/proc/meminfoShmemShmemグラフィックメモリの割り当て、これは非常に大きいかもしれません。
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％。したがって、おおよその推定だけが必要な場合は、この部分を無視してもかまいません。 :-).
実行するページキャッシュに約100 MBのプログラムコードをマッピングするときは、通常、firefoxその100 MBをRAMに保持しようとしています。それ以外の場合は、せいぜい遅延が発生し、最悪の場合、システムはすべての時間を費やします。勝つ異なるアプリケーション間。MemAvailableこれを行うには、少量のRAMも許可してください。十分に許さないかもしれませんし、寛大すぎるかもしれません。 「これらの要因の影響はシステムによって異なります。」
多くのPCワークロードの場合、「ファイル数が多い」という側面は関係がない可能性があります。それにもかかわらず、現在私のラップトップには500MBの回収可能なタブレットメモリ（8GB RAM）があります。これはext4_inode_cache（300,000を超えるオブジェクト）によるものです。最近、私のディスク容量を使用しているものを見つけるためにファイルシステム全体をスキャンする必要があるため、これが発生しました。 :-).私はコマンドを使用しましたが、df -x / | sort -n例えばGnome Disk Use Analyserは同じことをします。
2. [編集] 対照群の記憶
いわゆる "Linux コンテナ" はnamespaces、およびその他のさまざまな機能を通じて必要に応じて構築されます。 :-)cgroupsこれは、ほぼ完全なLinuxシステムのようなものを実行するのに十分な説得力のある環境を提供することができます。ホスティングサービスはこれらのコンテナを構築し、「仮想サーバー」として販売することができます。 :-).
ホスティングサーバーは、メインラインLinuxにはない機能を使用して「仮想サーバー」を構築することもできます。 オープンVZコンテナはメインラインcgroupより2年早く、「beancounters」を使用してメモリを制限できます。したがって、ドキュメントを読んだり、メインラインのLinuxカーネルについて質問したりすると、これらのメモリ制限がどのように機能するかを正確に理解することはできません。 cat /proc/user_beancounters現在の使用量と制限を表示します。 vzubcもう少しフレンドリーな形式で表現します。これ空カウンターホームページレコード行名。
制御グループには、内部プロセスのメモリ制限を設定する機能が含まれます。そのようなcgroup内でアプリケーションを実行している場合、アプリケーションはすべてのシステムメモリを使用できるわけではありません。 :-).では、この場合、使用可能なメモリをどのように確認できますか？
インターフェイスは、使用するかどうかによってさまざまな点で異なります。cgroup-v1またはcgroup-v2。
私のラップトップはcgroup-v1を使用してインストールされました。私は走ることができますcat /sys/fs/cgroup/memory/memory.stat。ファイルにはtotal_rss、、 shmem（tmpfstotal_cacheをtotal_shmem含む）を含むさまざまなフィールドがメモリ制限に含まれることを示します。total_rssの逆数だと思えばいいようですMemFree。memory.kmem.usage_in_bytesボードを含むカーネルメモリを表すファイルもあります。 （明示的に文書化されていませんが、将来の拡張memory.kmem.も含まれると仮定します。）memory.kmem.tcp.回収可能なタブレットメモリを見ることができる別のカウンタはありません。 cgroup-v1のドキュメントによると、実際にメモリ制限に達したことがわかります。いいえスラブメモリの回数をトリガします。 （文書には「旧式」なので、現在のソースコードを確認しなければならないという免責事項もあります。）
cgroup-v2は異なります。私はroot（トップレベル）cgroupがメモリ計算をサポートしていないと思います。 cgroup-v2ファイルはまだ残っていますmemory.stat。すべてのフィールドは子cgroupに対して合計されているため、total_...フィールドを照会する必要はありません。同じことが行われたとfile言う分野があります。面倒なことに、insideなどのフィールド全体はcache表示されません。個々のフィールドを追加する必要があるようです。回収可能なスラブメモリと回収不可能なスラブメモリの別々の統計があります。 v2 cgroup は、メモリが不足し始めたときにスラブを回収するように設計されているようです。rssmemory.stat
Linux cgroupは自動的に仮想化されないため/proc/meminfo（またはその中の他のファイル/proc）、システム全体の値が表示されます。 VPSのお客様には混乱する可能性があります。ただし、名前空間を使用して/proc/meminfoファイルを置き換えることはできます。特定のコンテナソフトウェアに偽造。無効な値の有用性は、特定のソフトウェアの機能によって異なります。
systemdcgroup-v1はコンテナなどに委任するのに安全とは見なされません。systemd-nspawncgroup-v1システムのコンテナの内部を見ました。それが配置されたcgroupとその中にあるメモリ空間を見ることができます。一方、インクルードはsystemdリソースを計算するための一般的なサービス固有のcgroupを設定しません。このcgroup内でメモリ計算が有効になっていないと、コンテナはそれを有効にできないようです。
cgroup-v2コンテナ内にある場合は、実際のcgroup-v2システムのルートとは異なるように見え、最上位のcgroupのメモリ領域を見ることができると仮定します。または、表示されたcgroupでメモリ統計が有効になっていない場合は、委任を受けて次のことを行うことができます。メモリ統計の有効化systemd（またはそれに対応する）。
答え2
最新の Linux カーネルでは、/proc/meminfoこのCached値にはすべてのユースケースShmemだけでなく、これらすべての項目が含まれているため、tmpfs使用するプログラムは必要に応じて事実上無料ではありません。私の経験では、Cached - Shmem実際に利用可能なメモリと非常によく一致しています。プロセスを終了せずにどちらも解放できませんが、Shmemメモリが不足している場合は交換できます。
次の値を確認することをお勧めします（例出力）。
$ grep -E "^MemTotal|^Cached|^Committed_AS|^Shmem:|^MemAvailable|^MemFree" /proc/meminfo
MemTotal: 32570668 kB
MemFree: 8245572 kB
MemAvailable: 7817776 kB
Cached: 11553648 kB
Shmem: 10604700 kB
Committed_AS: 36945628 kB
また、myはメモリの一部が断片化され、全体的なパフォーマンスが直接使用できないと推定されるため、MemAvailableより小さくなります。MemFree
実際の空き容量の別の推定値Cachedは次のとおりです。
$ sudo slabtop -sc -o | head | grep "Total Size"
Active / Total Size (% used) : 548703.26K / 672516.95K (81.6%)
私の場合、約550MBが使用されており、オフにするとシステムのパフォーマンスが低下します。
簡単に言うと：実際の目的は誤解を招く可能性がFreeあるため、名前を見ないでください。必要に応じてもっと消費できるRAMの量を見てください。CachedMemAvailable