解決策 1:
「キャッシュされた」合計には、tmpfs ファイルシステムなど、他のメモリ割り当ても含まれます。これを実際に確認するには、次を試してください:
mkdir t
mount -t tmpfs none t
dd if=/dev/zero of=t/zero.file bs=10240 count=10240
sync; echo 3 > /proc/sys/vm/drop_caches; free -m
umount t
sync; echo 3 > /proc/sys/vm/drop_caches; free -m
RAM ベースのファイルシステムにコピーした 100Mb 分の「キャッシュ」値が表示されます (十分な空き RAM があると仮定すると、マシンが既にオーバーコミットされている場合、その一部がスワップされていることに気付くかもしれません)。のメモリ使用量)。 free への各呼び出しの前の「sync; echo 3> /proc/sys/vm/drop_caches」は、すべての書き込みバッファー (同期) で保留中のものをすべて書き込み、メモリからキャッシュ/バッファーされたすべてのディスク ブロックをクリアする必要があるため、free は他の読み取りのみを行います。 「キャッシュされた」値の割り当て。
仮想マシン (VMWare で実行されているものなど) によって使用される RAM も、現在開いているメモリ マップ ファイルによって使用される RAM と同様に、free の「キャッシュされた」値にカウントされる場合があります (これは、使用しているハイパーバイザー/バージョンによって異なります。おそらくカーネルのバージョン間でも)。
そのため、「保留中のファイル/ネットワーク書き込みをバッファがカウントし、将来の物理読み取りを保存するために RAM に保持されている最近読み取り/書き込みブロックをキャッシュ カウントする」ほど単純ではありませんが、ほとんどの目的では、この単純な説明で十分です。
解決策 2:
ひっかけ問題。空き容量を計算するとき、実際にはバッファとキャッシュの両方を合計する必要があります.これは私が見つけたものです
バッファは、まだディスクに「書き込まれていない」ものです。キャッシュは、ディスクから「読み取られ」、後で使用するために保存されたものです。
http://visualbasic.ittoolbox.com/documents/difference-between-buffer-and-cache-12135
解決策 3:
バッファに関するより明確な説明を探していたところ、 "Professional Linux® Kernel Architecture 2008" で見つかりました
第 16 章:ページとバッファのキャッシュ
インタラクション
ページとバッファ間のリンクを設定しても、カーネルの他の部分にメリットがなければ、ほとんど役に立ちません。すでに述べたように、ブロックデバイスとの間の一部の転送操作は、基盤となるデバイスのブロックサイズに依存するサイズの単位で実行する必要がある場合がありますが、カーネルの多くの部分はページの粒度で I/O 操作を実行することを好みます。 — 特にメモリ管理に関して。このシナリオでは、バッファは 2 つの世界の間の仲介者として機能します。
解決策 4:
RedHat による説明 :
キャッシュ ページ:
キャッシュは、データを透過的に格納するメモリの一部であり、そのデータに対する将来の要求をより高速に処理できるようにします。このメモリは、カーネルがディスク データをキャッシュし、I/O パフォーマンスを向上させるために利用されます。
Linux カーネルは、可能な限り多くの RAM を使用して、ローカルおよびリモートのファイルシステムとディスクから情報をキャッシュするように構築されています。システムでさまざまな読み取りと書き込みが実行されると、カーネルは、システムで実行されているさまざまなプロセスのデータ、または近い将来に使用される関連プロセスのデータをメモリに保存しようとします。キャッシュは、プロセスが停止/終了した時点では再利用されませんが、他のプロセスが空きメモリよりも多くのメモリを必要とする場合、カーネルはヒューリスティックを実行してキャッシュ データを保存し、そのメモリを新しいプロセスに割り当てることでメモリを再利用します。
任意の種類のファイル/データが要求されると、カーネルはユーザーが操作しているファイルの一部のコピーを探し、そのようなコピーが存在しない場合は、キャッシュ メモリの新しいページを 1 つ割り当て、それをディスクから読み出された適切なコンテンツ。
キャッシュ内に格納されているデータは、以前に計算された値であるか、ディスクの別の場所に格納されている元の値の複製である可能性があります。一部のデータが要求されると、最初にキャッシュがチェックされ、そのデータが含まれているかどうかが確認されます。データは、元のソースから取得するよりもキャッシュからの方が高速に取得できます。
SysV 共有メモリ セグメントもキャッシュとして考慮されますが、ディスク上のデータを表すものではありません。共有メモリ セグメントのサイズは、ipcs -m コマンドを使用してバイト列を確認することで確認できます。
バッファ:
バッファーは、ページ キャッシュに格納されているデータのディスク ブロック表現です。バッファには、ページ キャッシュの下に存在するファイル/データのメタデータが含まれます。例:ページ キャッシュに存在するデータの要求がある場合、カーネルはまず、ページキャッシュに含まれる実際のファイル/データ。メタデータからファイルの実際のブロック アドレスがわかると、処理のためにカーネルによって取得されます。
解決策 5:
バッファ/キャッシュの解放
警告 これは、実稼働サーバーでは推奨されない強力な方法を説明しています!したがって、何か問題が発生した場合でも、私を責めないでください.
理解するために、強制できます システムはできるだけ多くのメモリを cache に委譲します キャッシュされたファイルを削除するより:
テストを行う前に、ヒットした別のウィンドウを開くことができます:
$ vmstat -n 1
procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
r b swpd free buff cache si so bi bo in cs us sy id wa
0 1 39132 59740 39892 1038820 0 0 1 0 3 3 5 13 81 1
1 0 39132 59140 40076 1038812 0 0 184 0 10566 2157 27 15 48 11
...
スワップの進化をリアルタイムで追跡するため。
注意: 現在のディレクトリの空きディスクをできるだけ多く処分する必要があります。mem+swap があります
デモ$ free
total used free shared buffers cached
Mem: 2064396 2004320 60076 0 90740 945964
-/+ buffers/cache: 967616 1096780
Swap: 3145720 38812 3106908
$ tot=0
$ while read -a line;do
[[ "${line%:}" =~ ^(Swap|Mem)Total$ ]] && ((tot+=2*${line[1]}))
done </proc/meminfo
$ echo $tot
10420232
$ dd if=/dev/zero of=veryBigFile count=$tot
10420232+0 records in
10420232+0 records out
5335158784 bytes (5.3 GB) copied, 109.526 s, 48.7 MB/s
$ cat >/dev/null veryBigFile
$ free
total used free shared buffers cached
Mem: 2064396 2010160 54236 0 41568 1039636
-/+ buffers/cache: 928956 1135440
Swap: 3145720 39132 3106588
$ rm veryBigFile
$ free
total used free shared buffers cached
Mem: 2064396 1005104 1059292 0 41840 48124
-/+ buffers/cache: 915140 1149256
Swap: 3145720 39132 3106588
Nota、私がこれを行ったホストは強く使用されています。これは、非常に静かなマシンではより重要になります。