昨日の午後、Linodeインスタンスの1つ(CentOS 5.7、64ビット)のサイズを4GBインスタンスから12GBに変更しました。その再起動の直後に、バッファのメモリ使用量がめちゃくちゃ高い-これまでに触れたどのマシンでも見たよりも高いことに気づきました。最も頻繁に使用するサーバーでも、バッファーの使用量が200MBを超えることはめったにありません。このサーバーでは、現在のバッファー使用量は2桁サイズ変更して再起動する前よりも高くなっています。
移行前後のデータを含むmuninメモリグラフは次のとおりです。
Muninが表示しているデータは、「free」の出力によって裏付けられています。
[erik@Host ~]$ free -m
total used free shared buffers cached
Mem: 11967 10146 1820 0 7374 1132
-/+ buffers/cache: 1639 10327
Swap: 255 0 255
今、私はカーネルがキャッシュに未使用のメモリを使用していることをよく知っていますが、バッファについての私の理解は、バッファが異なるということです。これらは、ディスクにコミットされるまで書き込みを一時的に保存するために使用されます。それは正しい理解ですか?このサーバーにはディスクがほとんどありませんIO(Apache/php Webサーバーであり、DBは他の場所にあるため、実質のIOはaccess_logsです))、したがって、バッファの使用量はかなり少ないと思います。
同じ期間のネットワークトラフィックグラフは次のとおりです。
ご覧のとおり、サイズ変更の前後でトラフィックに実質的な変化はありません。
再起動中に、私が知っている3つのことが変更されました。
これらの変更のうち、私の勘は、バッファ使用量の増加を引き起こしているのは新しいカーネルだったということです。残念ながら、現時点では、以前のカーネルにダウングレードするために別のダウンタイムヒットを取得することはできませんが、このバッファー使用量を整理できない場合は、それが必要になる可能性があります。
それで、私はいくつかの質問があります:
この点を明確にするには:
[バッファは]書き込みがディスクにコミットされるまで一時的に保存するために使用されます。それは正しい理解ですか?
いいえ、そうではありません。
キャッシュメモリの概念を理解しているようです。ファイルがディスクから読み取られると、ファイルはキャッシュとしてメモリに保持されます。アプリケーションがこのファイルに再度アクセスする必要がある場合、アクセスはRAM)から行われます。これは、ディスクからファイルに再度アクセスするのが遅いのとは対照的です。
アプリケーションがこのファイルに書き込む必要がある場合、書き込みはRAM内のファイルに対して実行されます。これは高速であり、カーネルはそれらのメモリページを「ダーティ」としてマークします。アプリケーションに関する限り、書き込みは完了しており、アプリは実行に戻ることができます。
カーネルは、ダーティページを後でディスクにフラッシュする処理を行います。 sync
コマンドを使用して、すべてのダーティページを強制的にフラッシュできます。そうしないと、フラッシュデーモン(pdflushまたはbdflush)がときどきウェイクアップします。
cat /proc/meminfo | grep Dirty
を使用すると、ダーティメモリの量をいつでも確認できます。
理解を深めるために、クリーンなページキャッシュ(読み取られたファイル)とダーティなページキャッシュ(ディスクへの書き込みを待機しているファイル)の両方が、Linuxでは「キャッシュ」としてカウントされます。
プロセスがより多くの仮想メモリ割り当てを要求した場合、ファイルキャッシュを解放できます。共有メモリセグメントとtmpfsも「キャッシュ」として報告されますが、ファイルキャッシュのように解放することはできません。
通常、「バッファ」は、プロセスを実行することによるメモリ割り当てです。 top -a
などを調べて、RAMの大部分を占めているプロセスを確認してください。