高い「Shmem」を診断する方法か。（例： `echo 3> drop_caches`がキャッシュを消去しないのはなぜですか？）

Question 1

私は上記の質問の著者です。まだ完全な答えはありませんが、これが最も有名な説明です。

最新のLinuxカーネルでは、Cachedこの値は/proc/meminfoディスクキャッシュの量を説明しません。しかし、カーネル開発者は現在、この設定を変更するには遅すぎると思います。。
実際に使用されるディスクキャッシュの量を実際に測定するには、Cached - Shmemそれを推定する計算を実行する必要があります。元の質問から数字を取ると15151936−14707664（kiB）（from /proc/meminfo）または（kiB）の出力が得られるため、444272システムに実際に約433MiBのディスクキャッシュがあるようです。この場合、すべてのディスクキャッシュを削除しても大量のメモリが確保されるわけではありません。すべてのディスクキャッシュを削除しても、フィールドはCached3％だけ減少します。

したがって、最良の推測は、一部のユーザーモードソフトウェアは、多くの共有メモリ（通常tmpfsまたは共有メモリマッピング）を使用して、Cachedシステムに実際にディスクキャッシュがほとんどないにもかかわらず高い値を示すことです。メモリ不足の状態が近づいています。Committed_AS私はこれがこの理論を支えるのに大きな助けになると思いますMemTotal。

linux-mm以下は、上記のリンクが後で機能しない場合に備えて、上記のリンクされたスレッドの結論の（短縮された）コピーです。

タイトル：Re：Shmemが/ proc / meminfoのキャッシュに含まれているのはなぜですか？
送信者： Vlastimil Babka @ 2021-08-30 16:05 UTC

21年8月30日午前12時44分に、Mikko Rantalainenは次のように書きました。

これは fs/proc/meminfo.c 関数 meminfo_proc_show() からすぐにはわかりませんが、 Cached: フィールドの出力には常にすべての Shmem: フィールドが含まれているようです。

だが今変えればより大きな混乱を引き起こすことができる。人々はもはや新しいカーネルの出力を最初に見ると誤解しません（IIRCの「free」コマンドもそれを使用します）。しかし、古いカーネルと新しいカーネルを使用している人は、それがある時点で変更されたことを考慮する必要があります...悪いです。

送信者: ハリド・アジズ @ 2021-08-30 19:38 UTC

2021年8月30日月曜日20:26 +0300に、Mikko Rantalainenは次のように書きました。

もちろん、1つの可能な解決策は、「キャッシュ済み」を変更せずに実際のキャッシュセマンティクスに「キャッシュ」を導入することです（つまり、（キャッシュ済み - Shmem）とメモリ対応RAMの合計を含む）。これにより、システム管理者は一意の値を持つ2つ以上の異なるフィールドを表示して文書を見つけることができます。

新しいフィールドを追加することをお勧めします。 / proc / meminfoのデータを解釈し、そのデータに対して操作を実行するためのツール/スクリプトがたくさんあるかもしれません。既存のデータの意味を変更すると、これらのツールは機能しません。新しい分野の欠点は、出力がさらに拡張されるが、既存のツールを損傷しないことです。

Answer

私は上記の質問の著者です。まだ完全な答えはありませんが、これが最も有名な説明です。

最新のLinuxカーネルでは、Cachedこの値は/proc/meminfoディスクキャッシュの量を説明しません。しかし、カーネル開発者は現在、この設定を変更するには遅すぎると思います。。
実際に使用されるディスクキャッシュの量を実際に測定するには、Cached - Shmemそれを推定する計算を実行する必要があります。元の質問から数字を取ると15151936−14707664（kiB）（from /proc/meminfo）または（kiB）の出力が得られるため、444272システムに実際に約433MiBのディスクキャッシュがあるようです。この場合、すべてのディスクキャッシュを削除しても大量のメモリが確保されるわけではありません。すべてのディスクキャッシュを削除しても、フィールドはCached3％だけ減少します。

したがって、最良の推測は、一部のユーザーモードソフトウェアは、多くの共有メモリ（通常tmpfsまたは共有メモリマッピング）を使用して、Cachedシステムに実際にディスクキャッシュがほとんどないにもかかわらず高い値を示すことです。メモリ不足の状態が近づいています。Committed_AS私はこれがこの理論を支えるのに大きな助けになると思いますMemTotal。

linux-mm以下は、上記のリンクが後で機能しない場合に備えて、上記のリンクされたスレッドの結論の（短縮された）コピーです。

タイトル：Re：Shmemが/ proc / meminfoのキャッシュに含まれているのはなぜですか？
送信者： Vlastimil Babka @ 2021-08-30 16:05 UTC

21年8月30日午前12時44分に、Mikko Rantalainenは次のように書きました。

これは fs/proc/meminfo.c 関数 meminfo_proc_show() からすぐにはわかりませんが、 Cached: フィールドの出力には常にすべての Shmem: フィールドが含まれているようです。

だが今変えればより大きな混乱を引き起こすことができる。人々はもはや新しいカーネルの出力を最初に見ると誤解しません（IIRCの「free」コマンドもそれを使用します）。しかし、古いカーネルと新しいカーネルを使用している人は、それがある時点で変更されたことを考慮する必要があります...悪いです。

送信者: ハリド・アジズ @ 2021-08-30 19:38 UTC

2021年8月30日月曜日20:26 +0300に、Mikko Rantalainenは次のように書きました。

もちろん、1つの可能な解決策は、「キャッシュ済み」を変更せずに実際のキャッシュセマンティクスに「キャッシュ」を導入することです（つまり、（キャッシュ済み - Shmem）とメモリ対応RAMの合計を含む）。これにより、システム管理者は一意の値を持つ2つ以上の異なるフィールドを表示して文書を見つけることができます。

新しいフィールドを追加することをお勧めします。 / proc / meminfoのデータを解釈し、そのデータに対して操作を実行するためのツール/スクリプトがたくさんあるかもしれません。既存のデータの意味を変更すると、これらのツールは機能しません。新しい分野の欠点は、出力がさらに拡張されるが、既存のツールを損傷しないことです。

Question 2

今書いています。メモリ問題の診断に役立つツール、の情報に基づいていくつかの式を含むRedHatのドキュメント。

ディスクキャッシュ/tmpfsに関して私が理解したことは次のとおりです。

キャッシュ = ディスクキャッシュ - スワップキャッシュ - tmpfs メモリ使用量

tmpfsはスワップに常駐する可能性があるため、最初にtmpfsの実際のメモリ使用量を計算する必要があります。

簡単な解決策：

shmem = 共有メモリセグメント + tmpfs ram

ただし、共有メモリセグメントもスワップに存在する可能性があり、shmemにはhugepage共有メモリセグメントが含まれていないようです（カーネル5.4および5.15でテスト済み）。

より正確なソリューション

shmem="4k ページ sysvipc shm rss" + tmpfs ラム使用量

「4k sysvipc shm rss」は、標準ページサイズ（4k）の共有メモリセグメントで使用されるメモリの合計なので、大きなページはありません。

以下では、メモリセグメントのRSS使用量を確認できます/proc/sysvipc/shm。

shmが4kまたは2Mページを使用しているという事実は/ procに公開されていないようですが、共有メモリセグメントに接続して物理ページ（/proc/kpageflags）をスキャンするとその情報が得られます。これを使用して、共有メモリページ数を出力に追加します。

sudo ./memstats groups
[...]
Scanning shm...
Shared memory segments (MiB):
         key           id       Size        RSS         4k/2M        SWAP   USED%        SID
============================================================================================
           0            3          9          9       2442/0            0  100.02           
           0            2          9         10          0/5            0  104.86           
[...]

Answer