出力で「バッファ」をどのように説明または説明しますかfree？
$ free -h
total used free shared buff/cache available
Mem: 501M 146M 19M 9.7M 335M 331M
Swap: 1.0G 85M 938M
$ free -w -h
total used free shared buffers cache available
Mem: 501M 146M 19M 9.7M 155M 180M 331M
Swap: 1.0G 85M 938M
このシステムには（既知の）問題はありません。私は「バッファ」が「キャッシュ」（155M対180M）ほど高いという事実に驚いたと思います。 「キャッシュ」とは、ファイル内容のページキャッシュを意味し、「キャッシュ/バッファ」で最も重要な部分である傾向があると思います。 「バッファ」とは何か分からない。
たとえば、RAMはより多くのラップトップと比較しました。私のラップトップでは、「バッファ」の数字は「キャッシュ」よりはるかに小さい（200M対4G）。 「バッファ」が何であるかを理解することで、より小さいシステムでバッファがそれほど大きな割合で増加する理由を調べることができます。
man proc（私は「big」の古い定義を無視しています）：
バッファ%lu
RAWディスクブロックの相対的な一時記憶領域は大きくなりすぎません（20MB程度）。
キャッシュ%lu
ディスクから読み取られたファイルのメモリ内キャッシュ（ページキャッシュ）。 SwapCachedは除外されます。
$ free -V
free from procps-ng 3.3.12
$ uname -r # the Linux kernel version
4.9.0-6-marvell
$ systemd-detect-virt # this is not inside a virtual machine
none
$ cat /proc/meminfo
MemTotal: 513976 kB
MemFree: 20100 kB
MemAvailable: 339304 kB
Buffers: 159220 kB
Cached: 155536 kB
SwapCached: 2420 kB
Active: 215044 kB
Inactive: 216760 kB
Active(anon): 56556 kB
Inactive(anon): 73280 kB
Active(file): 158488 kB
Inactive(file): 143480 kB
Unevictable: 10760 kB
Mlocked: 10760 kB
HighTotal: 0 kB
HighFree: 0 kB
LowTotal: 513976 kB
LowFree: 20100 kB
SwapTotal: 1048572 kB
SwapFree: 960532 kB
Dirty: 240 kB
Writeback: 0 kB
AnonPages: 126912 kB
Mapped: 40312 kB
Shmem: 9916 kB
Slab: 37580 kB
SReclaimable: 29036 kB
SUnreclaim: 8544 kB
KernelStack: 1472 kB
PageTables: 3108 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 1305560 kB
Committed_AS: 1155244 kB
VmallocTotal: 507904 kB
VmallocUsed: 0 kB
VmallocChunk: 0 kB
$ sudo slabtop --once
Active / Total Objects (% used) : 186139 / 212611 (87.5%)
Active / Total Slabs (% used) : 9115 / 9115 (100.0%)
Active / Total Caches (% used) : 66 / 92 (71.7%)
Active / Total Size (% used) : 31838.34K / 35031.49K (90.9%)
Minimum / Average / Maximum Object : 0.02K / 0.16K / 4096.00K
OBJS ACTIVE USE OBJ SIZE SLABS OBJ/SLAB CACHE SIZE NAME
59968 57222 0% 0.06K 937 64 3748K buffer_head
29010 21923 0% 0.13K 967 30 3868K dentry
24306 23842 0% 0.58K 4051 6 16204K ext4_inode_cache
22072 20576 0% 0.03K 178 124 712K kmalloc-32
10290 9756 0% 0.09K 245 42 980K kmalloc-96
9152 4582 0% 0.06K 143 64 572K kmalloc-node
9027 8914 0% 0.08K 177 51 708K kernfs_node_cache
7007 3830 0% 0.30K 539 13 2156K radix_tree_node
5952 4466 0% 0.03K 48 124 192K jbd2_revoke_record_s
5889 5870 0% 0.30K 453 13 1812K inode_cache
5705 4479 0% 0.02K 35 163 140K file_lock_ctx
3844 3464 0% 0.03K 31 124 124K anon_vma
3280 3032 0% 0.25K 205 16 820K kmalloc-256
2730 2720 0% 0.10K 70 39 280K btrfs_trans_handle
2025 1749 0% 0.16K 81 25 324K filp
1952 1844 0% 0.12K 61 32 244K kmalloc-128
1826 532 0% 0.05K 22 83 88K trace_event_file
1392 1384 0% 0.33K 116 12 464K proc_inode_cache
1067 1050 0% 0.34K 97 11 388K shmem_inode_cache
987 768 0% 0.19K 47 21 188K kmalloc-192
848 757 0% 0.50K 106 8 424K kmalloc-512
450 448 0% 0.38K 45 10 180K ubifs_inode_slab
297 200 0% 0.04K 3 99 12K eventpoll_pwq
288 288 100% 1.00K 72 4 288K kmalloc-1024
288 288 100% 0.22K 16 18 64K mnt_cache
287 283 0% 1.05K 41 7 328K idr_layer_cache
240 8 0% 0.02K 1 240 4K fscrypt_info
ベストアンサー1
- 「バッファ」と他のタイプのキャッシュの違いは何ですか？
- このような区別がなぜそんなに目立つのか？ファイル内容のキャッシングについて話すとき、何人かの人々が「バッファキャッシュ」と言うのはなぜですか？
- それは何の
Buffersために使用されますか？ Buffersなぜ私たちは特に大きくなったり小さくなったりするのですか？
1. 「バッファ」と他のタイプのキャッシュの違いは何ですか？
Buffersブロックデバイスで使用されるページキャッシュの量を表示します。 「ブロック装置」は、最も一般的なタイプのデータ記憶装置である。
カーネルは報告するとき、ページキャッシュの残りの部分から意図的にこの量を減らす必要がありますCached。バラよりmeminfo_proc_show():
cached = global_node_page_state(NR_FILE_PAGES) -
total_swapcache_pages() - i.bufferram;
...
show_val_kb(m, "MemTotal: ", i.totalram);
show_val_kb(m, "MemFree: ", i.freeram);
show_val_kb(m, "MemAvailable: ", available);
show_val_kb(m, "Buffers: ", i.bufferram);
show_val_kb(m, "Cached: ", cached);
2. なぜこのような区別が目立つのでしょうか。ファイル内容のキャッシングについて話すとき、何人かの人々が「バッファキャッシュ」と言うのはなぜですか？
ページキャッシュは通常、最小4096バイトのMMUページサイズで動作します。これは、mmap()メモリマップされたファイルアクセスに重要です。 [1][2] 別々のプロセス間でロードされたプログラム/ライブラリコードページを共有し、要求に応じて個々のページをロードできるように設計されています。 （他のコンテンツにスペースが必要で、最近使用されていない場合はページをアンロードするのにも役立ちます。）
[1]メモリマップされたI/O- GNU Cライブラリのマニュアル。
[2]mmap- ウィキペディア。
初期のUNIXにはディスクブロックの「バッファキャッシュ」がありましたが、mmap（）はありませんでした。明らかに、mmap（）が最初に追加されたときに、ページキャッシュを一番上に新しいレイヤーとして追加しました。混乱して聞こえます。結局のところ、UNIXベースのオペレーティングシステムは別のバッファキャッシュから離れていました。これで、すべてのファイルキャッシュはページに基づいています。ページは、ディスクの場所ではなく（ファイル、オフセット）に基づいて照会されます。これを「統合バッファキャッシュ」といいます。それはおそらく、人々が「バッファキャッシュ」に精通しているからです。 [サム]
[サム]UBC：NetBSD用の効率的な統合I / Oおよびメモリキャッシュサブシステム
（「Linuxで追加された興味深い変更は、ページが格納されているディスクのデバイスブロック番号が構造リスト形式でページと共にキャッシュされることです。）修正されたページがディスクに書き戻されるとbuffer_head、送信することができ、ページデータを書き込む位置を決定するために間接ブロックを読み取る必要はありません。
Linux 2.2には書き込み用の独立した「バッファキャッシュ」がありますが、読み取り用のものはありません。 「ページキャッシュはバッファキャッシュを使用してデータを書き換えるため、追加のデータコピーが必要になり、一部の書き込みロードのメモリ要件が2倍になります。」 [4]詳細について心配する必要はありませんが、これらの記録はBuffersLinuxが別々に使用量を報告する理由の1つです。
[4]Linux 2.4 メモリ管理のページ交換、リック・ヴァン・リエル。
一方、Linux 2.4 以降では追加のコピーは存在しません。 「システムはページキャッシュページ間で直接ディスクIOを実行します。」 [4] Linux 2.4は2001年にリリースされました。
3.Buffers用途は何ですか？
ブロックデバイスはファイルとして扱われるため、ページキャッシュがあります。これは、「ファイルシステムメタデータとRAWブロックデバイスのキャッシュ」に使用されます。 [4] ただし、現在のバージョンのLinuxでは、ファイルシステムはそれを介してファイルの内容をコピーしないため、「デュアルキャッシュ」はありません。
Buffersページキャッシュの一部はLinuxバッファキャッシュだと思います。一部のソースでは、この用語に同意しない場合があります。
ファイルシステムが使用するバッファキャッシュの量（存在する場合）は、ファイルシステムの種類によって異なります。問題のシステムはext4を使用します。 ext3/ext4は、Linuxバッファキャッシュを使用して、ログ、ディレクトリの内容、およびその他のメタデータを保存します。
一部のファイルシステム（ext3、ext4、ocfs2を含む）は、jbdまたはjbd2層を使用して物理ブロックロギングを処理します。この層はデフォルトでバッファキャッシュを使用します。
- 電子メールで記事を送信する渡すテッド・ジョー、2013
Linuxカーネルバージョン2.4以前は、Linuxに別々のページキャッシュとバッファキャッシュがありました。 2.4以降では、ページキャッシュとバッファキャッシュが統合されており、ページキャッシュ
Buffersに表現されない生のディスクブロック、つまりファイルデータではありません。...
ただし、カーネルはまだページではなくブロック単位でブロックI / Oを実行する必要があるため、バッファキャッシュはまだ存在します。ほとんどのブロックはファイルデータを表しているため、ほとんどのバッファキャッシュはページキャッシュで表されます。ただし、少量のブロックデータにはファイルサポート（メタデータやネイティブブロックI / Oなど）がないため、バッファキャッシュとしてのみ表示されます。
-カップルのQuoraの答え渡すロバート・ラブ、2013年に最後に更新されました。
どちらの著者もLinux開発者であり、Linuxカーネルのメモリ管理作業を行ってきました。最初の情報源は、技術的な詳細をさらに詳しく説明します。 2番目のソースは、いくつかの詳細で矛盾し、時代遅れである可能性があるより一般的な要約です。
実際、ファイルシステムは、キャッシュがページインデックス化されていても、部分ページメタデータ書き込みを実行できます。ユーザープロセスも使用中に部分ページ書き込みを実行できますwrite()（とは逆にmmap()）。少なくともブロックデバイスへの直接書き込みは可能である。これは読み取りではなく書き込みのみに機能します。ページキャッシュを読み取ると、ページキャッシュは常にページ全体を読み込みます。
リヌスは轟音するのが好きブロックサイズの書き込みを実行するためにバッファキャッシュは必要なく、ファイルシステムは、ページキャッシュがブロックデバイスではなく独自のファイルに接続されていても、部分ページメタデータ書き込みを実行できます。私は彼がext2がこれを行うことができると言うのが正しいと確信しています。 ext3/ext4 およびそのロギングシステムの場合はそうではありません。このデザインの原因が何であるかは不明です。彼が叫んだ人々は説明に疲れました。
ext4_readdir() は Linus の好言状を満たすために変更されていません。私はまた、彼が他のファイルシステムのreaddir（）で使用したい方法を見ることができません。私の考えでは、XFSもディレクトリにバッファキャッシュを使用しているようです。 bachefsはreaddir（）のページキャッシュをまったく使用せず、独自のbtreeキャッシュを使用します。 btrfsについてよくわかりません。
Buffers4.私たちが特に大きくまたは小さく成長したいのはなぜですか？
この場合、ext4 ログサイズ私のファイルシステムは128Mです。したがって、これは1）私のバッファキャッシュが128Mをわずかに超えるレベルに安定することができ、2）バッファキャッシュが私のラップトップのより大きなRAMに比例して拡張されない理由を説明します。
その他の考えられる原因については、以下を参照してください。無料出力のバッファ列は何ですか？ 報告された「バッファ」は、実際にfree回収可能なカーネルスラブメモリの組み合わせです。Buffers
ログ書き込みがバッファキャッシュを使用していることを確認するために、高速RAM（tmpfs）でファイルシステムをシミュレートし、さまざまなログサイズの最大バッファ使用量を比較しました。
# dd if=/dev/zero of=/tmp/t bs=1M count=1000
...
# mkfs.ext4 /tmp/t -J size=256
...
# LANG=C dumpe2fs /tmp/t | grep '^Journal size'
dumpe2fs 1.43.5 (04-Aug-2017)
Journal size: 256M
# mount /tmp/t /mnt
# cd /mnt
# free -w -m
total used free shared buffers cache available
Mem: 7855 2521 4321 285 66 947 5105
Swap: 7995 0 7995
# for i in $(seq 40000); do dd if=/dev/zero of=t bs=1k count=1 conv=sync status=none; sync t; sync -f t; done
# free -w -m
total used free shared buffers cache available
Mem: 7855 2523 3872 551 237 1223 4835
Swap: 7995 0 7995
# dd if=/dev/zero of=/tmp/t bs=1M count=1000
...
# mkfs.ext4 /tmp/t -J size=16
...
# LANG=C dumpe2fs /tmp/t | grep '^Journal size'
dumpe2fs 1.43.5 (04-Aug-2017)
Journal size: 16M
# mount /tmp/t /mnt
# cd /mnt
# free -w -m
total used free shared buffers cache available
Mem: 7855 2507 4337 285 66 943 5118
Swap: 7995 0 7995
# for i in $(seq 40000); do dd if=/dev/zero of=t bs=1k count=1 conv=sync status=none; sync t; sync -f t; done
# free -w -m
total used free shared buffers cache available
Mem: 7855 2509 4290 315 77 977 5086
Swap: 7995 0 7995
この答えの歴史：私がこの雑誌を見る方法
当初、Ted TsoのEメールを発見し、その内容が何を強調しているのか疑問に思いました。書く隠れ家。 「汚い」なら驚くだろう書かれていないデータはシステムRAMの最大30％を占めることができます。 sudo atop10秒間隔で問題のシステムは常に1 MBだけを書くようです。関連ファイルシステムはこの速度に100倍以上従うことができます。 （USB2ハードドライブにあり、最大スループットは約20MB / sです。）
btrace -w 10 /dev/sdaデータはほとんど読み取られないため、blktrace（）を使用してキャッシュされているIOが書き込みであることを確認してください。これもmysqld唯一ユーザースペースプロセスはIOを実行します。
書き込み（icinga2がmysqlへの書き込み）を担当するサービスを停止して再確認しました。 「バッファ」が20M以下に落ちることを確認しました。これについての説明はありません。そのまま維持します。ライターを再起動すると、10秒間隔で約0.1M増加する「バッファ」が表示されます。私はそれが70M以上までこの速度を維持することを観察しました。
echo 3 | sudo tee /proc/sys/vm/drop_caches「バッファ」を再び4.5Mに下げるだけで十分でした。これは、私が蓄積したバッファが「きれいな」キャッシュで、Linuxが必要なときにすぐに削除できることを証明します。このシステムは蓄積されません。書かれていないデータ。 （drop_caches書き込み保存が行われていないため、ダーティページは削除できません。syncキャッシュを最初にクリーンアップするテストを実行したい場合は、このコマンドを使用できます。）
完全なmysqlディレクトリは150Mにすぎません。累積バッファは、mysqlが作成したメタデータチャンクを表す必要があり、データにメタデータチャンクが多すぎるという事実に驚きました。