「キャッシュされた」メモリは事実上無料ですか?


11

を実行cat /proc/meminfoすると、上部に次の3つの値が表示されます。

MemTotal:        6291456 kB
MemFree:         4038976 kB
Cached:          1477948 kB

私の知る限り、「キャッシュ」の値はLinuxシステムによって作成されたディスクキャッシュであり、アプリケーションがより多くのRAMを必要とするとすぐに解放されるため、MemFreeとCachedの両方がゼロになるまでLinuxがメモリ不足になることはありません。

残念ながら、 "MemAvailable"は/ proc / meminfoによって報告されません。これは、おそらく仮想サーバーで実行されているためです。(カーネルバージョンは4.4)

したがって、すべての実用的な目的のために、アプリケーションで使用可能なRAMはMemFree + Cachedです。

その見方は正しいですか?


1
私はこれを金槌で打たれたくはありませんが、この質問は重複していなくても関係があります。あなたが持っていないことに驚いていますMemAvailable、それは3.14で追加されました。
Stephen Kitt

その質問から受け入れられた回答は/ proc / zoneinfoを使用していますが、これは私のvserverでも使用できません
Roland Seuhs

uname -a:Linux host 4.4.0-042stab134.8#1 SMP Fri Dec 7 17:16:09 MSK 2018 x86_64 x86_64 x86_64 GNU / Linux
Roland Seuhs

これは、4.4ではなく実際に2.6.32に基づいているカーネルを備えたOpenVZシステムだと思います。
Stephen Kitt

1
@sourcejediと4.4カーネルと同時にコンパイルされました!
Stephen Kitt

回答:


10

その見方は、多くの実際のケースで非常に誤解を招く可能性があります。

カーネルは、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のコンテナ」と呼ばれるnamespacescgroups好みに応じて、様々な他の機能:-)。彼らは、ほぼ完全な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_rsstotal_cachetotal_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(または同等のもの)を有効にできるように権限が委任されることを期待します。



1
かっこいいな。コミットを含む最初のリリースが表示されるため、GitHubリンクを使用します(と同様git describe --contains)。SUの質問によってTL; DRとしてリンクされていることがわかりました。これは、proc.txtに追加されたセクションを引用しているだけです。しかし、この質問では、コミットの説明は完璧なIMOです:-)。
sourcejedi

MemAvailableはほとんどの仮想サーバーで利用できないようです...次に何をしますか?
Roland Seuhs

@RolandSeuhsはおそらく「beancounters」を学びます。太字の編集を参照してください。お手数ですが、ご不明な点がございましたら、新たにご質問いただければ幸いです。このリンクからいつでもリンクできますが、詳細は、メインラインLinuxカーネルを使用する読者にはおそらく関係ありません。
sourcejedi
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.