
私は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番目のケースではなぜ増加したのか?私はこれを読んだfree からの出力の buffers 列とは何ですか?しかし、ここでの回答は私には適切ではありません。
これらは、「buffers 列にはファイルに関するメタデータが含まれています」と言っていますが、これは誤りです。なぜなら、inode、dentry、buffer_head (実際にはファイルのメタデータ) のスラブをカウントするのは「cache」列だからです。また、列に が含まれているman free
ことも示しています。cache
SReclaimable
また、「バッファ列にはブロック デバイスからのブロックのキャッシュが含まれています」とも表示されます。これは真実に近いように見えますが、 をbuffers
実行したときに増加した理由は説明されていますが、 コマンドを実行したときに列が増加したdd
理由は説明されていません。 の場合でも、ファイル キャッシュがすでにある場合、なぜそれが必要なのでしょうか。 DVD ディスクを除いて、ブロック デバイスから直接読み取り/書き込みを行う人はいません。buffers
find
dd
答え1
答えはここに見つかりました:バッファメモリ使用量が大きくなる原因を特定するにはどうすればよいですか?
Linux はファイルの inode を 2 回保存するようです。1 回目はext4_inode_cache
/としてinode_cache
スラブに保存し (slabtop
コマンドでこれらのスラブのサイズが増加するのを確認しました)、2 回目はバッファーに保存します (inode はブロック デバイスから直接読み取られ、ブロック デバイスから直接読み取られたすべてのブロックはバッファーに保存されるため)。そのため、コマンドを実行すると、Linux はブロック デバイスから inode のブロックを読み取り、バッファーに保存してから、スラブに inode のキャッシュを作成します。その結果、出力の列と列find
の両方が増加します。cache
buffers
free