私は2つの実験をしました。
最初の実験(Ubuntu 20.04、ext4ファイルシステム):
- コマンドの実行
free -h -w
:
$ free -h -w
total used free shared buffers cache available
Mem: 30Gi 2,6Gi 25Gi 106Mi 126Mi 2,1Gi 27Gi
- コマンドの実行
sudo find / | grep something
- コマンドを再実行して、
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):
- コマンドの実行
free -h -w
:
$ free -h -w
total used free shared buffers cache available
Mem: 30Gi 2,6Gi 24Gi 106Mi 1,2Gi 2,6Gi 27Gi
- コマンドを実行してください
dd if=/dev/nvme0n1p2 of=/dev/null bs=1M count=500
。ここでディスクが別のディスクになります。 - コマンドを再実行
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ディスクを除いて、誰もブロックデバイスからデータを直接読み書きできません。buffers
find
dd
ベストアンサー1
ここで答えを見つけました。過剰なバッファメモリ使用量の原因を特定する方法は?
Linuxはファイルのinodeを2回保存するようです。 1つ目はスラブにext4_inode_cache
/として保存し(コマンドを使用してこのスラブのサイズを増やすことを観察しました)、2番目はバッファに保存します(inodeがブロックデバイスから直接読み取られるため)。直接読み込まれます(ブロックデバイスはそれをバッファに保存します)、したがってコマンドを実行すると、Linuxはブロックデバイスからinodeのブロックを読み取り、それをバッファに保存し、スラブにinodeのキャッシュを生成します。これはすべて増加します。inode_cache
slabtop
find
cache
buffers
free