私はAppDynamicsを使用して実稼働システムを監視していますが、システムの速度が遅くなり、ほとんどフリーズしました。このイベントの直前に、AppDynamics はすべての GC アクティビティ (マイナーとメジャーを問わず) を数分間フラットラインで表示しています...その後、元に戻ります。
システムの負荷が非常に低い期間でも、JVM が何らかのGC アクティビティを実行していることがわかります。完全にフラットラインになって 0 になったことは一度もありません。
また、ネットワーク I/O は、GC/メモリのフラットラインと同じインスタンスでフラット化されます。
だから私は尋ねます：システムレベルの何かがJVMをフリーズさせたり、そのガベージコレクションをハング/フリーズさせたりすることはありますか? これは CentOS マシン上にあります。
詳細な情報がなければ、問題の正確な原因を特定することは非常に困難です。
しかし、私はあなたの質問に答えようとすることができます:
OS はガベージ コレクションをブロックできますか?
OS がスレッド ガベージ コレクタをブロックし、他のスレッドが実行される可能性はほとんどありません。そのように調べてはいけません。
OS は JVM をブロックできますか?
はい、完璧に実行でき、多くのことを実行できますが、プロセスがすべて同時に実行されていると考えるよりも高速です。
jvm は、OS の制御下にあるプロセスです。アプリケーションがハングしたときに使用される cpu を確認する必要があります (jvm ではなくサーバーで監視します)。値が非常に低い場合は、2 つの原因が考えられます (他にもあります)。
OS でスワッピングが有効になっていますか。
スワッピングが有効になっている OS ですべての RAM がいっぱいになると Java に大きな問題があることに気付きました。
私の理論はこれです：
最初はシステムに大きな影響はありませんが、大量のメモリを必要とするアプリを起動しようとすると、非常に長い時間がかかり、システムは劣化し続けます.
複数の大きな VM を使用すると、これがさらに悪化する可能性があります。私は 3 つまたは 4 つの大きな VM を実行していますが、RAM の使用率が 60 ～ 70% を超えると、システムが動かなくなり始めます。
これは推測ですが、数日間のテスト後に私が見た動作を説明しています。
その効果は、すべてのスワッピングが gc を「防止」しているように見えることです。より正確には、OS は GC 時間のほとんどをスワッピングに費やしているため、GC 中に何もせずにハングしているように見えます。
修正 - -Xmx をより低い値に設定し、スワッピングを回避するのに十分な余地ができるまでドロップします。これは常に私の問題を解決してきましたが、あなたの問題が解決しない場合、私はあなたの問題の原因について間違っています:)