Linuxでキャッシュをドロップする理由

私たちのサーバーでは、深夜にキャッシュをドロップする習慣があります。

sync; echo 3 > /proc/sys/vm/drop_caches

コードを実行すると、多くのRAMが解放されるようですが、本当にそうする必要がありますか。空きRAMは無駄ではありませんか？

あなたは100％正しいです。RAMを解放することはお勧めできません。これは、貨物カルトシステム管理の例です。

はい、キャッシュをクリアするとRAMが解放されますが、カーネルはキャッシュではなくディスク上のファイルを探すため、パフォーマンスの問題が発生する可能性があります。

通常、利用可能なRAMが使い果たされると、カーネルはキャッシュをクリアします。pdflushを使用して、汚れたコンテンツを頻繁にディスクに書き込みます。

このようなキャッシュをドロップする理由は、ディスクパフォ​​ーマンスのベンチマークのためであり、存在する唯一の理由です。

I / Oを多用するベンチマークを実行する場合、試行するさまざまな設定がすべて実際にディスクI / Oを実行していることを確認する必要があるため、Linuxでは完全な再起動ではなくキャッシュをドロップできます。

ドキュメントから引用するには：

このファイルは、さまざまなカーネルキャッシュ（inode、dentries、pagecacheなど）の増加を制御する手段ではありません。これらのオブジェクトは、システムの他の場所でメモリが必要になると、カーネルによって自動的に回収されます。

このファイルを使用すると、パフォーマンスの問題が発生する場合があります。キャッシュされたオブジェクトを破棄するため、特にオブジェクトが頻繁に使用されている場合は、ドロップされたオブジェクトを再作成するために大量のI / OとCPUが必要になる場合があります。このため、テスト環境またはデバッグ環境以外での使用は推奨されていません。

ここでの基本的な考え方はおそらくそれほど悪くはありません（非常に単純で誤解を招くだけです）：キャッシュされているファイルがあり、近い将来アクセスされる可能性が非常に低いファイル、たとえばログファイルがあります。これらの「食べ尽くす」ラムは、OSが必要に応じて何らかの方法で後で解放する必要があります。

swappiness、ファイルアクセスパターン、メモリ割り当てパターンなどの予測不可能な設定に応じて、これらのキャッシュを解放しないと、後で再利用を余儀なくされる場合があります。未使用メモリのプールからメモリを割り当てます。最悪の場合、Linuxのswappiness設定によりプログラムメモリがスワップアウトされます。これは、これらのファイルがプログラムメモリよりも近い将来に使用される可能性が高いとLinuxが判断するためです。

私の環境では、Linuxはほとんどの場合間違っていると推測し、ほとんどのヨーロッパ証券取引所（現地時間0900年頃）の開始時にサーバーは1日に1回だけ処理を開始します。ログファイル、圧縮、コピーなどにより、キャッシュをいっぱいにして、スワップアウトする必要がありました。

しかし、キャッシュの削除はこの問題の解決策ですか？明確にそうではありません。ここでの解決策は、Linuxに知らないことを伝えることです。これらのファイルはおそらくもう使用されないでしょう。これは、アプリケーションを作成することによって、posix_fadvise()またはcmd lineツールなどをvmtouch使用して実行できます（これは、キャッシュファイルだけでなく、物事を調べるのにも使用できます）。

これにより、不要になったデータをキャッシュから削除し、キャッシュする必要のあるものを保持できます。すべてのキャッシュをドロップすると、ディスクから多くのものを再読み込みする必要があるためです。そして、それは最悪の瞬間に：それが必要なとき; アプリケーションの遅延が顕著になり、多くの場合許容できない。

必要なのは、メモリ使用パターン（たとえば、何かがスワップしている場合）を監視し、それに応じて分析し、それに応じて行動するシステムです。解決策は、vtouchを使用して1日の終わりにいくつかの大きなファイルを削除することです。サーバーの1日のピーク使用量はそれだけなので、RAMを追加することもできます。

多数の仮想マシンを起動するときにドロップキャッシュが役立つことがわかりました。または、一部のデータベースサーバーなど、ラージページを使用するその他のもの。

Linuxのラージページは、ページに入れる2MBの連続した物理RAMを見つけるために、RAMをデフラグする必要があります。ファイルキャッシュをすべて解放すると、このプロセスが非常に簡単になります。

しかし、ファイルキャッシュを毎晩ドロップする一般的な正当な理由がないという点で、他のほとんどの回答に同意します。

これは、実際に問題を見つけるスキルや経験のある人がいなかったときにシステムを安定させる方法として制定された可能性があります。

リソースの解放

キャッシュをドロップすると、本質的にいくつかのリソースが解放されますが、これは、システムが実行しようとしていることを実際に難しくするという副作用があります。システムがスワップしている場合（実際に対応できる速度よりも高速にディスクスワップパーティションの読み書きを試みる場合）、キャッシュを定期的にドロップすることで症状を緩和できますが、原因を解決することはできません。

何がメモリを消費しているのですか？

キャッシュの削除が機能しているように見える大量のメモリ消費の原因を特定する必要があります。これは、不適切に構成されたサーバープロセス、または単純に誤って使用されたサーバープロセスが多数あるために発生します。たとえば、あるサーバーで、Magento Webサイトが15分以内に特定の数の訪問者に到達したときに、メモリ使用率が最大になるのを目撃しました。これは、Apacheが多すぎるプロセスを同時に実行できるように構成されていることが原因でした。多くのメモリを使用するプロセスが多すぎる（Magentoは獣である場合があります）=スワッピング。

ボトムライン

それが必要なものだと思ってはいけません。それがなぜあるのかを積極的に見つけ、他の人がそれが間違っていると示唆した場合はそれを無効にする勇気を持ち、システムを観察します-実際の問題が何であるかを学び、それを修正します。

Linux / m68kには実際にはカーネルバグがあり、kswapdが夢中になって100％CPU（Debianバイナリパッケージautobuilder-vulgo buildd-既に実行中のような他のCPUバウンドタスクがある場合は50％）を消費します。常にではありません）数時間ごとにこの特定のコマンドを実行することにより軽減されます。

そうは言っても…あなたのサーバーはおそらくm68k（Atari、Amiga、Classic Macintosh、VME、Q40 / Q60、Sun3）システムではありません;-)

この場合、線を入れた人は、疑わしい、またはせいぜい時代遅れのアドバイスに従ったか、RAMの使い方を間違えたという考えを得ました（実際には、「フリーRAMはRAMが浪費されている」と言ってキャッシュを提案します） 、または、これが他の場所で別の問題を「修正」することを「発見」しました（そして、適切な修正を探すのが面倒でした）。

1つの理由は、サイトが何らかの種類の監視を実行しており、フリーラムの量をチェックし、フリーラムが特定の割合を下回ったときに管理者に警告を送信することです。その監視ツールが、フリーRAMの計算にキャッシュを含めないほど愚かな場合、誤った警告を送信する可能性があります。キャッシュを定期的に空にすることで、これらの警告を抑制しながら、「実際の」RAMが少なくなったときにツールが通知できるようにすることができます。

もちろん、この種の状況では、実際の解決策は、監視ツールを修正して、フリーRAM計算にキャッシュを含めることです。キャッシュのクリーニングは単なる回避策であり、悪いプロセスでもあります。プロセスがディスクにアクセスすると、キャッシュがすぐに補充されるからです。

したがって、私の仮定が真実であっても、キャッシュクリーニングは理にかなったものではなく、主な問題を解決するのに十分な能力を持たない誰かによる回避策です。

これを毎晩のcronジョブで行うもっともらしい理由を考えることができます。

大規模なシステムでは、キャッシュを定期的に削除して、メモリの断片化を解消すると便利な場合があります。

カーネルの透過的なhugepageサポートは、メモリの定期的なスイープを実行して、小さなページをhugepageに結合します。縮退状態では、これによりシステムが1、2分停止する可能性があります（これに関する私の経験はRHEL6にありました。うまくいけば改善されます）。キャッシュを削除すると、hugepage Sweeperで作業する余地ができます。

これが透過的なhugepagesを無効にする正当な理由であると主張するかもしれません。透明なhugepagesによる全体的なパフォーマンスの改善は価値があり、1日1回キャッシュを失う代償を払う価値があると信じているかもしれません。

cronジョブではありませんが、あなたがそれをしたいと思う別の理由を考えました。仮想化システムがVMを新しいハードウェアに移行する直前は、このための非常に良い時期です。新しいホストにコピーするメモリの内容が少なくなります。もちろん、最終的にはストレージから読み取る必要がありますが、おそらくそのトレードオフを取るでしょう。

virtソフトウェアのいずれかが実際にこれを行うかどうかはわかりません。

2セントを追加するだけです。システムは、これらのメモリページがキャッシュであることをよく知っており、アプリケーションがメモリを要求すると、必要なだけドロップします。

関連する設定は/proc/sys/vm/swappiness、新しいメモリ割り当て中にカーネルにメモリキャッシュのドロップまたは「アイドル」割り当てられたメモリページのスワップを優先させることです。

質問は2014年のものですが、今日までいくつかの隠されたCentos 6.8バックエンドに問題が存在するため、それは誰かにとってはまだ役に立つかもしれません。

https://github.com/zfsonlinux/zfs/issues/1548 は、zfsの問題について説明しています。そこでは、削除されたファイルのためにディスクスペースが解放されません。なぜなら、nfsがzfsの上で使用された場合、ファイルのiノードはカーネルのiノードキャッシュから削除されないからです。

バグスレッドから引用して、behlendorf、2015年1月6日は次のように書いています。

現在の推測では、何らかの理由でNFSサーバーがキャッシュバージョンのファイルハンドルを保持しています。NFSサーバーがこのファイルハンドルをドロップするまで、ZFSはこのファイルのリンクを解除できません。いくつかの軽いテストでは、サーバーにキャッシュをドロップすると、この参照が（NFSファイルハンドルのように）ドロップされ、その時点でスペースが正しく解放されることが示されています。また、メモリが圧迫されると、メモリが削除される可能性があります。

すなわち、夜間エコー3> / proc / sys / vm / drop_cachesは、zfsを再構築するためのダウンタイムを望まない場合、そのバグの最も簡単な修正です。

だから、カルトカルト管理ではないかもしれませんが、かなり良いデバッグがその理由でした。

これは、通常、各CPU（ソケット）がすべてのメモリに透過的にアクセスできるが、並列HPCアプリケーションに関連して他のソケットのメモリよりも高速にアクセスできるNUMA（非均一メモリアクセス）システムでは意味があります。

多くの単純な並列アプリケーションは、単一プロセスからファイルI / Oを実行する傾向があるため、ディスクキャッシュに割り当てられた単一NUMAノードのメモリの大部分を終了時に残します。これらの状況では、Linuxカーネルのキャッシュ再利用プロセスは、私が知る限り、まだNUMAに対応していないため、キャッシュにメモリが割り当てられているNUMAノードで実行されているプロセスは、他のNUMAノードにメモリを強制的に割り当てます。他のノードに空きRAMがある限り、パフォーマンスが低下します。

ただし、HPCシステムでは、cronを使用した特定の時間ではなく、新しいユーザージョブを開始する前にキャッシュを消去する方が賢明です。

非並列アプリケーションの場合、この問題はほとんど発生しません。

ページキャッシュが非常に大きく（現在のスワップ使用量よりもはるかに大きい）、スワップインとスワップアウトが交互に発生する場合は、キャッシュをドロップする必要があります。Ubuntu 16.04LTSを実行しているMariaDBデータベースサーバーの1つでメモリ使用量が増加し、Linuxが未使用のページキャッシュを削除する代わりにスワップ使用量を増やすことを選択した場合を見てきました。TokuDBで無効にする必要があるため、システムで透過的なhugepagesはすでに無効になっています。とにかくそれはバグではないかもしれませんが、まだこの動作をしているLinuxは私にとって非常に困惑しています。さまざまなソースが、アプリケーションが要求したときにLinuxがページキャッシュを削除すると述べています。

• https://www.linuxatemyram.com/
• https://www.thomas-krenn.com/en/wiki/Linux_Page_Cache_Basics

しかし、現実はそれほど単純ではありません。回避策は次のいずれかです。

1. ドロップキャッシュを定期的に実行する
2. 必要に応じてドロップキャッシュを実行します（アクティビティのスワップアウトにvmstat 1を使用して監視します）
3. 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

PAEカーネルで実行されている16GBのRAMを搭載したデスクトップマシンがあります。1〜2時間後、キャッシュをドロップするまでディスクのパフォーマンスが劇的に低下するため、単純にcronに入れます。これがPAEカーネルの問題なのか、十分なメモリがある場合にキャッシュの実装が非常に遅いのかはわかりません。