「free -h」コマンド出力でバッファが増加する理由

「free -h」コマンド出力でバッファが増加する理由

私は2つの実験をしました。

最初の実験(Ubuntu 20.04、ext4ファイルシステム):

  1. コマンドの実行free -h -w:
$ free -h -w
              total        used        free      shared     buffers       cache   available
Mem:           30Gi       2,6Gi        25Gi       106Mi       126Mi       2,1Gi        27Gi
  1. コマンドの実行sudo find / | grep something
  2. コマンドを再実行して、free -h -w「バッファ」列が大幅に増加し(約1G)、「キャッシュ」列も増加することを確認します(約500M)。
$ free -h -w
              total        used        free      shared     buffers       cache   available
Mem:           30Gi       2,6Gi        24Gi       106Mi       1,2Gi       2,6Gi        27Gi

2回目の実験(同じPC):

  1. コマンドの実行free -h -w:
$ free -h -w
              total        used        free      shared     buffers       cache   available
Mem:           30Gi       2,6Gi        24Gi       106Mi       1,2Gi       2,6Gi        27Gi
  1. コマンドを実行してくださいdd if=/dev/nvme0n1p2 of=/dev/null bs=1M count=500。ここでディスクが別のディスクになります。
  2. コマンドを再実行free -h -wし、バッファが500M増加したことを確認してください。
$ free -h -w
              total        used        free      shared     buffers       cache   available
Mem:           30Gi       2,6Gi        24Gi       115Mi       1,7Gi       2,6Gi        27Gi

したがって、質問がbuffers最初のケースで熱が増加する理由と2番目のケースで増加する理由は何ですか?私はこれを読んだ無料出力のバッファ列は何ですか?しかし、ここへの答えは私には適していません。

彼らは「バッファ列にファイルのメタデータが含まれています」と言います。ただし、「キャッシュ」列はinode、dentry、およびbuffer_head(実際にはファイルのメタデータ)のスラブを計算するため、これは間違っています。man freeまた、cache熱にSReclaimable

彼らはまた、「バッファ列にブロックデバイスのブロックキャッシュが含まれています」と言います。これは事実に似ているように見え、buffersコマンドを実行すると列が増加する理由を説明しますが、実行すると列が増加するdd理由は説明しません。コマンド。この場合でも、すでにファイルキャッシュがある場合はなぜ必要ですか? DVDディスクを除いて、誰もブロックデバイスからデータを直接読み書きできません。buffersfinddd

ベストアンサー1

ここで答えを見つけました。過剰なバッファメモリ使用量の原因を特定する方法は? Linuxはファイルのinodeを2回保存するようです。 1つ目はスラブにext4_inode_cache/として保存し(コマンドを使用してこのスラブのサイズを増やすことを観察しました)、2番目はバッファに保存します(inodeがブロックデバイスから直接読み取られるため)。直接読み込まれます(ブロックデバイスはそれをバッファに保存します)、したがってコマンドを実行すると、Linuxはブロックデバイスからinodeのブロックを読み取り、それをバッファに保存し、スラブにinodeのキャッシュを生成します。これはすべて増加します。inode_cacheslabtopfindcachebuffersfree

おすすめ記事