web-dev-qa-db-ja.com

Linux：echo 3> / proc / sys / vm / drop_cachesが完了するまでに数時間かかります

LinuxベースのファイルサーバーであるThecusN8900 NASがあり、NFSを介して6つのクライアントにファイルを提供しています。 Thecusサポートがまだ説明していない何らかの理由で、60秒ごとに/ proc/meminfoをチェックするスクリプトを実行し、ディスクキャッシュが使用可能なRAMの50％を超えると、「エコー3」を実行します。 >/proc/sys/vm/drop_caches "コマンドでキャッシュをフラッシュします。

それが理にかなっているかどうかの問題は別として、実際の「echo 3>/proc/sys/vm/drop_caches」コマンドは完了するのに数時間かかることがあり、それは私には長すぎるように思えます。

大きな問題は、これが発生すると、ディスク使用率と同様にマシンの負荷が急上昇し、コマンドが最終的に完了するまですべてのNFSトラフィックがクロールされ、コマンドが最終的に完了すると、再び応答することです。

NAS自体には16ギガのRAM、raid6構成の7つのドライブ（およびホットスペア）があり、ドライブの問題はまったくありません（S.M.A.R.T.テストによる） ）。

したがって、問題は、drop_cachesコマンドにこれほど時間がかかる原因は何でしょうか。

linuxnfsnetwork-attached-storagelinux-kernel
6
rmm

キャッシュを削除するのにそれほど時間はかからないはずです。そのechoコマンドから数時間本当に戻ってこないのですか？

以前はキャッシュから読み取ることができたファイルをディスクから読み取る必要があるため、キャッシュが削除された後はマシンの速度が低下することは理にかなっています。

1
sciurus

コマンド自体は即座に完了するはずです。結果、つまりすべてを再度キャッシュする必要がある場合、多くの時間がかかる可能性があります。それは意味がありません。完全に削除できるのであれば、それは良い考えです。

間違ったコマンドを見ている可能性があります。echo 3 > /proc/sys/vm/drop_cachesのように、sync; echo 3 > /proc/sys/vm/drop_cachesの前にsyncも実行されますか？ディスクへのすべての書き込みをフラッシュするsync操作は、完了するまでに少し時間がかかる場合があるためです。また、syncにもパフォーマンスの問題がありますが、突然の停電の場合にデータがすでにディスクに書き込まれているので、安全を確保するために、ある程度の意味がある場合があります。

0
pqnet