AmazonEC2のメモリキャッシュをクリアする
私たちのプロジェクトでは、約3〜4時間連続して実行されるいくつかのテストがあります。やがて、十分なメモリが見つからなかったため、テストは失敗します。グーグルで、次のコマンドを実行すると、テストを再開するのに役立つことがわかりました。
sync; echo 3 > /proc/sys/vm/drop_caches
ただし、これらは夜間のテストであり、手動で介入せずに実行できれば、非常に役立ちます。
私はこれを成し遂げるためのオプションを見ているだけです。
私はいくつかのリンクを見つけました 1 と 2 見た目から、それは役に立つかもしれません。
先に進んでcronタブを更新する前に、他のオプションを知りたかっただけです。
キャッシュを定期的にクリーンアップしても大丈夫ですか？それは他の問題を引き起こしますか？
RAMを増やすことは役に立ちますか？私の代替手段は何ですか？
RAMを増やすことは役に立ちますか？
これらの2つのコマンド（syncとdrop_caches）を実行した後、テストが成功する理由を知らずに言うのは難しいです。 TBH遅延の問題が原因でテストが失敗しない限り、ファイルシステムキャッシュを削除しても、テストが機能するとは思いません。カーネルがmin_free_kbytesを下回ることに気付いた場合キャッシュから最も古いエントリの削除を開始して、実際に空きメモリを少なくともmin_free_kbytesに戻します。このプロセスの唯一の例外は、「ダーティ」とマークされたページの場合です。したがって、ファイルシステムキャッシュの存在は通常ありません。アプリケーションがカーネルがPruneへのエントリを見つけるよりも速くメモリを割り当てていない限り、問題が発生します（この場合、min_free_kbytesを増やすのが適切です）。
おそらく最も効果的なコマンドはsyncコマンドです。これは、非同期ディスクI/Oに使用されるバッファー専用のメモリを解放します（ファイルシステムのすべてのエントリからdirtyを削除します）。キャッシュ、低メモリ状態でのエビクションの候補にします）。
RAMが役立つを追加する確率は約80〜90％ですが、実行しているテストがわからないので、できます」確かに言う。
キャッシュを定期的にクリーンアップしても大丈夫ですか？それは他の問題を引き起こしますか？
ここで行っているのは、基本的にパフォーマンスチューニングです（または、少なくともその目的で使用できるようになっているチューナブルで遊んでいます）。調整可能ファイルは通常、「正しい」答えが一般に不可能/非現実的であると考えられる場合に利用可能になります。物事をどのように実行するかについての一般的なルールを作成することが可能である場合、それらはソフトウェアにそのことを実行させるだけであり、システム管理者を問題から除外します。
それがあなたに問題を引き起こさないということを絶対に確実に言うことはできないと言っても過言ではありません。 itおそらくは機能の喪失を引き起こさないと言うことができますしかし、確かではありません。ファイルシステムキャッシュはパフォーマンスを向上させるように設計されているため、アプリケーションが何かを読み取るたびにディスクからデータが来るのを待つように強制することは、おそらく望ましくありません（可能性はありますが）時には望ましくないが必要です）。
編集：
@Emmanuelのコメントを読んでください。彼は良い点を挙げています。未使用のスワップスペースがある場合は、vm.swappinessを増やして、使用頻度の低いアプリケーションメモリをスワップアウトするカーネルの設定を増やすことをお勧めします。より多くのスワップスペースが必要な場合（またはスワップスペースがない場合）は、スワップパーティションとスワップファイルを作成するための手順をオンラインで見つけることができます。
編集＃2
私はこれを試したことがありませんが、カーネルのドキュメントを見ると、カーネルが独自のsyncを実行する前に、メモリに保持されるダーティデータの量を制御するdirty_ratiosysctl調整可能ファイルがあります。これを下げて、ファイルシステムキャッシュ内の「ダーティ」とマークされたページが少なくなり、メモリが必要になったときに削除できるようにすることができます。