syncコマンドは何をしますか？

私はそれが何をしているのか知っています...私が継承したアプリケーションの問題をなぜ修正しているのか興味があります。FlexクライアントのRed5サーバーとして機能するかなり大きなtomcatアプリケーションを引き継ぎ、リアルタイムの相互作用データの多くを処理し、最終的にRails APIにフラッシュされます。この問題は、これらのクライアントへの応答が3〜400ミリ秒に増加し、通常は100ミリ秒未満でしたが、時間の経過とともに多くの負荷がかかっていました。クライアントは、メモリの問題であると疑いましたが、実際には確認できませんでした。ある日、ステージングサーバーiが負荷テストを実行していたので、リクエストの取り込みがほとんど停止したか、非常に遅くなりました。気まぐれに

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

そして魔法のように、サーバーは活気を取り戻し、これらの接続をフルスピードで実行し始めました。これは偶然の一致でしたか、またはこの動作は理にかなっており、なぜですか？

ハードディスクはRAMよりも桁違いに遅いため、linuxはファイルシステムのデータをキャッシュするために浮遊している可能性のある予備のRAMを使用します。ただし、ハードディスクに何か問題があるか、サーバー上のサービスがデータをキャッシュまたは取得できないほど長い間、サーバー上のサービスがそのような高速でデータを書き込もうとしていない限り、これは実際にパフォーマンスの問題を引き起こすことはありません。また、ハードディスクが寿命に近づいていることを示している可能性もあります。

とにかく：

• 実行man syncすると、同期の実行内容がわかります[FSバッファをフラッシュ]
• 「linux drop_caches」をグーグルで検索すると、3番目の数字をエコーすると、キャッシュから不要なメモリページがすべて解放されます[これは正常なシステムでは必要ないはずです]
• command1 && command2 「command1が正常に終了し、command2を実行する場合」に分類されます。
  • これのパートナーはcommand1 || command2、「command1が失敗した場合にcommand2を実行する」という別名です。

与えられたコマンドは、せいぜい一時的な修正であり、システムに何か他の問題があることを示しています。ディスクが寿命に達しているか、システムのパワーが不足しているか、またはその両方です。

AWSは気弱な人向けではなく、その理由の1つに出会ったばかりです。AWSでのディスクI / Oの貧弱な状況はよく知られており、その上にアプリケーションを構築する人にとって考慮すべき主要な要因の1つです。ディスクを最適化したインスタンスと、EBSボリュームからRAID 0を構築するなどのいくつかのトリックがあり、これらを改善することができます。カーネルがディスクI / Oをバッファリングできるように、必ずより大きいインスタンス（少なくともm1.large）を使用してください。