Linuxでキャッシュを削除する理由
私たちのサーバーでは、午前0時にキャッシュをドロップする習慣があります。
sync; echo 3 > /proc/sys/vm/drop_caches
コードを実行すると、多くのRAMが解放されるように見えますが、本当にそうする必要があるのでしょうか。無料ではありませんRAM無駄ですか？
あなたは100％正解です。 not RAMを解放するのは良い習慣です。これは、おそらく貨物カルトシステム管理の例です。
はい、キャッシュをクリアするとRAMが解放されますが、カーネルがキャッシュ内ではなくディスク上のファイルを検索するため、パフォーマンスの問題が発生する可能性があります。
通常、カーネルは、利用可能なRAM=が使い果たされるとキャッシュをクリアします。汚れたコンテンツをpdflushを使用してディスクに頻繁に書き込みます。
このようにキャッシュを削除する理由は、ディスクのパフォーマンスをベンチマークするためであり、それが存在する唯一の理由です。
I/O集約型のベンチマークを実行する場合、試行するさまざまな設定がすべて実際にディスクI/Oを実行していることを確認する必要があるため、Linuxでは、完全な再起動ではなくキャッシュを削除できます。
documentation から引用するには：
このファイルは、さまざまなカーネルキャッシュ（inode、dentries、pagecacheなど）の増大を制御する手段ではありません。これらのオブジェクトは、システムの他の場所でメモリが必要になったときに、カーネルによって自動的に再利用されます。
このファイルを使用すると、パフォーマンスの問題が発生する可能性があります。キャッシュされたオブジェクトを破棄するため、特に頻繁に使用されている場合は、削除されたオブジェクトを再作成するために大量のI/OとCPUを消費する可能性があります。このため、テストまたはデバッグ環境以外での使用はお勧めしません。
ここでの基本的な考え方はおそらくそれほど悪くはありません（非常に単純で誤解を招くだけです）。ログファイルなど、キャッシュされているファイルがあり、近い将来アクセスされる可能性が非常に低い場合があります。これらの「食い尽くす」RAMは、必要なときにOSによって何らかの方法で後で解放する必要があります。
Swappiness、ファイルアクセスパターン、メモリ割り当てパターンなどの予測不可能なことの設定によっては、これらのキャッシュを解放しないと、後で強制的に再利用される場合があり、これよりも少し時間がかかります未使用のメモリのプールからメモリを割り当てます。最悪の場合、linuxのswappiness設定により、プログラムメモリがスワップアウトされます。これは、linuxは、これらのファイルがプログラムメモリよりも近い将来使用される可能性が高いと考えているためです。
私の環境では、Linuxはかなり間違った推測をしており、ほとんどのヨーロッパの証券取引所（現地時間0900頃）の開始時に、サーバーは1日に1回だけ行う処理を開始します。ログファイル、それらの圧縮、それらのコピーなどは、物事を交換しなければならないところまでキャッシュを満たしていました。
しかし、ドロップするとキャッシュがこの問題の解決策になりますか？間違いなく。ここでの解決策は、Linuxに知らないことを伝えることです。これらのファイルはおそらく使用されなくなるでしょう。これは、posix_fadvise()のようなものを使用して、またはvmtouchなどのcmd行ツールを使用して、アプリケーションを作成することで実行できます（これは、キャッシュファイルだけでなく、ものの調査にも使用できます）。
こうすることで、不要になったデータをキャッシュから削除し、キャッシュする必要のあるデータを保持できます。これは、すべてのキャッシュを削除すると、多くのデータをディスクから再度読み取る必要があるためです。そして、それは最悪の可能性のある瞬間に：それが必要なとき。アプリケーションで遅延が発生し、それが顕著になり、許容できないことがよくあります。
必要なのは、メモリ使用パターンを監視し（何かがスワップしている場合など）、それに応じて分析し、それに応じて動作するシステムです。解決策は、vtouchを使用して1日の終わりにいくつかの大きなファイルを削除することです。サーバーの毎日のピーク使用量はそれだけなので、RAMを追加することもできます。
大量の仮想マシンを起動するときにドロップキャッシュが役立つことがわかりました。または、一部のデータベースサーバーなど、ラージページを使用するもの。
Linuxの大きなページでは、ページに挿入する2MBの連続した物理RAMを見つけるために、RAMをデフラグする必要があることがよくあります。すべてのファイルキャッシュを解放すると、このプロセスが非常に簡単になります。
しかし、ファイルキャッシュを毎晩削除するのに一般的に適切な理由はないという点で、他のほとんどの回答に同意します。
これは、問題を実際に発見するスキルや経験のある人がいないときにシステムを安定させる方法として制定された可能性があります。
リソースを解放する
キャッシュを削除すると、基本的に一部のリソースが解放されますが、これにより、システムが実際に実行しようとしていることを実行するのが難しくなるという副作用があります。システムがスワッピングしている場合（ディスクスワップパーティションから実際に読み込めるよりも速く読み書きしようとする場合）、キャッシュを定期的に削除すると症状は緩和されますが、。
記憶を食い尽くしているのは何ですか？
ドロップキャッシュが機能しているように見えるメモリ消費の原因を特定する必要があります。これは、適切に構成されていない、または単に正しく使用されていないサーバープロセスがいくつもあることが原因である可能性があります。たとえば、1台のサーバーで、MagentoのWebサイトが15分間隔で特定の数の訪問者に到達したときに、メモリ使用率の最大値を確認しました。これは、Apacheが多すぎるプロセスを同時に実行できるように構成されていることが原因でした。プロセスが多すぎて、大量のメモリを使用している（Magentoは時々獣です）=スワッピング。
ボトムライン
それが必要なものだと思い込まないでください。なぜそれが存在するのかを事前に見つけ、他の人が間違っていると示唆した場合はそれを無効にする勇気を持ってもらい、システムを観察します-実際の問題が何であるかを学び、それを修正します。
Linux/m68kには実際にカーネルのバグがあり、kswapdが狂ってCPUを100％消費します（Debianバイナリパッケージオートビルダーのような他のCPUにバインドされたタスクがある場合は50％-vulgo buildd –すでに実行中）。常にではありませんが）数時間ごとにこの特定のコマンドを実行することで軽減できます。
とはいえ、サーバーはm68k（Atari、Amiga、Classic Macintosh、VME、Q40/Q60、Sun3）システムではない可能性が高いです;-)
この場合、行を入れた人は、疑わしいか、せいぜい時代遅れのアドバイスに従うか、RAMの使い方を間違っているべきだという考えを得ました（現代の思考は確かに「無料RAM is RAM wasted "and caches cache）]、またはこれが「修正」することを「発見」[sic！]他の場所での別の問題（そして怠惰すぎて適切な修正を検索してください）。
私はこれを毎晩のcronジョブで実行するもっともらしい理由の1つと考えることができます。
大規模なシステムでは、定期的にキャッシュを削除して、メモリの断片化を解消できると便利な場合があります。
カーネルの透過的なヒュージページのサポートは、定期的にメモリをスイープして、小さなページをヒュージページに合体させます。縮退した状態では、これによりシステムが1〜2分休止する可能性があります（これに関する私の経験はRHEL6でしたが、うまくいけば改善されます）。キャッシュを削除すると、ヒュージページスイーパーで作業する余地ができます。
これが透過的な巨大ページを無効にする良い理由だとあなたは主張するかもしれません。 OTOHあなたは、透過的な巨大ページによる全体的なパフォーマンスの向上は、1日1回キャッシュを失う代価を払う価値があると信じているかもしれません。
私はあなたがそれをやりたいと思う別の理由を考えましたが、cronジョブではありません。仮想化システムがVMを新しいハードウェアに移行する直前です。これには非常に良いタイミングです。新しいホストにコピーするメモリの内容が少なくなります。最終的にはストレージから読み取る必要があります。代わりに、もちろん、しかし、私はおそらくそのトレードオフを取るでしょう。
Virtソフトウェアのいずれかが実際にこれを行うかどうかはわかりません。
理由の1つは、サイトが何らかの種類の監視を実行している可能性があります。これは、空きRAMの量をチェックし、空きRAMが特定の割合を下回ると管理者に警告を送信します。その監視ツールが、キャッシュを空きRAM計算に含めないように十分に機能していない場合、誤った警告を送信する可能性があります。キャッシュを定期的に空にすることで、これらの警告を抑制しながら、「実際の」RAMが少なくなったときにツールが通知できるようにすることができます。
もちろん、このような状況での実際の解決策は、監視ツールを変更して、キャッシュを空きRAM計算に含めることです。キャッシュのクリーニングは単なる回避策であり、プロセスがディスクにアクセスするときにキャッシュがすぐに補充されるため、同様に悪いものです。
したがって、私の仮定が真実であっても、キャッシュクリーニングは意味のあるものではなく、主な問題を修正するのに十分な能力がない人による回避策です。
私の2セントを追加するだけです。システムknowsこれらのメモリページはキャッシュであり、アプリケーションがメモリを要求すると、必要なだけドロップされます。
関連する設定は/proc/sys/vm/swappinessは、新しいメモリ割り当て時にカーネルにメモリキャッシュを削除するか、「アイドル」に割り当てられたメモリページをスワップするように指示します。
問題は2014年からですが、この問題は一部の非表示のcentos 6.8バックエンドに現在も存在しているため、まだ誰かにとって役立つ可能性があります。
https://github.com/zfsonlinux/zfs/issues/1548 はzfsの問題を説明しています。そこでは、nfsがzfsの上で使用される場合、ファイルのiノードがカーネルのiノードキャッシュから削除されないため、削除されたファイルのためにディスク領域は解放されません。
バグスレッドから引用するために、2015年1月6日のbehlendorfは次のように書いています。
現在の推測では、何らかの理由でNFSサーバーがファイルハンドルのキャッシュバージョンを保持しているとのことです。 NFSサーバーがこのファイルハンドルを削除するまで、ZFSはこのファイルのリンクを解除できません。いくつかの簡単なテストでは、サーバー上のキャッシュを削除すると、この参照が削除され（NFSファイルハンドルなど）、その時点でスペースが正しく解放されることが示されています。また、メモリ不足により、メモリが低下する可能性があります。
つまり、夜間エコー3>/proc/sys/vm/drop_cachesは、zfsを再構築するためのダウンタイムが必要ない場合、そのバグの最も簡単な修正です。
したがって、貨物カルト管理ではないかもしれませんが、かなり良いデバッグがいくつかの理由でした。
ページキャッシュが非常に大きい（現在のスワップ使用量よりもはるかに大きい）場合、スワップインとスワップアウトが交互に発生します。これは、キャッシュを削除する必要がある場合です。 Ubuntu 16.04LTSを実行しているMariaDBデータベースサーバーの1つでメモリ使用量が増加するケースを見てきました。Linuxは、未使用のページキャッシュを削除するのではなく、スワップ使用量を増やすことを選択しました。 TokuDBで無効にする必要があるため、透明な巨大ページはすでにシステムで無効になっています。とにかくそれはバグではないかもしれませんが、Linuxがまだこの動作をしているのは私にとってかなり困惑しています。 Linuxがアプリケーションが要求したときにページキャッシュを削除するとさまざまな情報筋が述べました。
しかし、現実はそれほど単純ではありません。回避策は次のいずれかです。
- 定期的にドロップキャッシュを実行する
- 必要に応じてドロップキャッシュを実行します（アクティビティのスワップアウトにはvmstat 1を使用して監視します）
- Ddやpython-fadviseなどのユーティリティを使用して、Apacheログファイルなどの特定のファイルをキャッシュから削除するようにLinuxに指示します。 https://unix.stackexchange.com/questions/36907/drop-a-specific-file-from-the-linux-filesystem-cache を参照してください
Dd runの例：
dd if=/var/log/Apache2/access_log.1 iflag=nocache count=0
Python-fadviseの例：
pyadvise -d /var/log/Apache2/access_log.1
これは、通常、各CPU（ソケット）はすべてのメモリに透過的にアクセスできますが、並列HPCアプリケーションに関連して、他のソケットのメモリよりも高速に独自のメモリにアクセスできるNUMA（非均一メモリアクセス）システムでは意味があります。
多くの単純な並列アプリケーションは、単一のプロセスからファイルI/Oを実行する傾向があるため、ディスクキャッシュに割り当てられた単一のNUMAノードでメモリの大部分を終了し、他のNUMAノードではメモリがほとんど解放される可能性があります。これらの状況では、Linuxカーネルのキャッシュ再利用プロセスは、私が知る限り、まだNUMA対応ではないため、キャッシュにメモリが割り当てられているNUMAノードで実行されているプロセスは、他のNUMAノードにメモリを割り当てざるを得ません。他のノードに無料のRAM=がある限り、パフォーマンスが停止します。
ただし、HPCシステムでは、cronを使用して特定の時間ではなく、新しいユーザージョブを開始する前にキャッシュを消去する方が賢明です。
非並列アプリケーションの場合、この問題が発生することはほとんどありません。