私はAppDynamicsでプロダクションシステムを監視していますが、システムをクロールするのが遅くなり、ほとんどフリーズしました。このイベントの直前に、AppDynamicsは数分間にわたりすべてのGCアクティビティ（マイナーなものとメジャーなもの）をフラットラインで表示しています。OSはJavaプロセスをガベージ・コレクションから停止できますか？
システムに極度に負荷が軽い場合でも、私たちは依然として GC活動を行っているJVMを見ています。
また、ネットワークI/Oは、GC /メモリフラットラインと同じ時点でフラット化されています。
私は質問します。システムレベルで何かがJVMをフリーズさせるか、ガベージコレクションをハング/フリーズさせることができますか？これはCentOSマシン上にあります。
お使いのOSのスワッピングが有効になっていますか？
スワッピングが有効になっているOS上のすべてのRAMをいっぱいにすると、Javaの大きな問題に気付きました。実際にはWindowsシステムが壊れ、効率的にロックして再起動します。 OSのラムが満杯に近づい
私の理論がこれです。
最初はそれほどシステムには影響しませんが、大量のメモリを必要とするアプリケーションを起動しようとすると、かなり長い時間がかかり、システムが低下し続けるだけです。
複数の大きなVMでこれを悪化させる可能性があります。私は3つまたは4つの巨大なVMを実行し、60-70％のRAM使用率を超えると、システムが起動します。
これは推測ですが、テストした後に見た動作を説明しています。
効果は、すべてのスワッピングが「予防」するように見えることです。もっと正確に言えば、OSはほとんどのGCタイムスワッピングを費やしているので、GC中に何もしていないように見えます。
解決策：-Xmxを低い値に設定すると、スワッピングを避けるために十分な余裕ができるまでドロップします。これはあなたの問題を解決していない場合、これは私の問題を解決している場合は、私はあなたの問題の原因について間違っている:)
どのようにして、OSは正確にプロセスからメモリを要求できますか？ – user93353
私は、OSが低メモリ状態を示すと信じていますが、参照が見つかりません。私は間違っているかもしれませんが、効果は説明されているように - JavaアプリケーションがRAMの大部分を占めている場合、どれだけのスワップが利用可能であるかにかかわらず、システムがRAMから使い果たされた後に停止するようになります。私はLinuxでこれを見てきましたが、ウィンドウ上ではるかに顕著です。私が-Xmxを間違って設定したとき、マシンがラム限界に達したときにマシンをリブートしなければなりませんでした。また、OSはすべての時間を費やしているので、この時間中にGCが停止しているように見えます（これはTicketMonsterが説明したとおりです）。 –
このシグナルはどうですか？ http://msdn.microsoft.com/en-us/library/windows/desktop/aa366541(v=vs.85).aspxもしJavaがこれに応答すれば、私が記述したように動作を説明します。 –
詳細な情報がなければ、問題の正確な原因を特定することは本当に困難です。
私はあなたの質問に答えてみることができます：
OSはガベージコレクションをブロックできますか？
OSがスレッドガベージコレクタをブロックして、他のスレッドを実行させる可能性は非常に低いです。あなたはそのように調査すべきではありません。
OSはJVMをブロックできますか？
はい、それは完全に実行できますが、多くの処理を実行できますが、プロセスがすべて同時に実行されていると考えるよりも速いです。
jvmはOSの制御下にある他の人と彼のようなプロセスです。アプリケーションがハングアップしたときに使用するCPUをチェックする必要があります（jvmにないサーバーで監視している）。それは非常に低い場合、私は2つの要因（しかし、もっとあります）を参照してください。
理論上、はい、可能です。しかし、それは練習ではありません。
ほとんどのJava仮想マシンでは、アプリケーションスレッドだけが実行中のスレッドではありません。アプリケーションスレッド以外にも、コンパイルスレッド、ファイナライザスレッド、ガベージコレクションスレッドなどがあります。これらのスレッドと、マシン上で実行されている他のプログラムからの他のスレッドにCPUコアを割り当てるスケジューリングの決定は、多くのパラメータ（スレッドの優先順位、最終実行時間など）に基づいています。したがって、実際には、システム内のスレッドは、不当に長い時間CPU割当てを待つべきではなく、オペレーティングシステムは無制限の時間スレッドをブロックすべきではありません。
ガベージコレクションスレッド（および他のVMスレッド）が行う必要のあるアクティビティは最小限です。ガベージコレクションが必要かどうかを定期的に確認する必要があります。アプリケーションスレッドがすべて中断されていても、JITコンパイラスレッドやファイナライザスレッドなどの他のVMスレッドが動作し、オブジェクトを割り当ててガベージコレクションをトリガする可能性があります。これは特に、C/C++ではなくJavaでVMスレッドを実装するメタ円形JVMに当てはまります。
さらに最近のJVMは、世代別ガベージコレクタ（ヒープを別々のスペースに分割し、ヒープの異なる部分に異なる年齢のオブジェクトを配置するガベージコレクタ）を使用します。これは、オブジェクトが古くなったり古いものになるため、他の古いスペースに移動することができます。したがって、オブジェクトを収集する必要がなくても、世代別のガベージコレクタはオブジェクトをある空間から別の空間に移動させることがあります。
もちろん、ガベージコレクタの詳細はJVMとは異なります。怪我にもっと塩を入れるために、いくつかのJVMは2種類以上のガベージコレクタをサポートしています。しかし、アイドル状態のアプリケーションでガーベッジ・コレクションを最小限に抑えることは驚くべきことではありません。
_ "クロールするシステムが遅く、ほとんど凍結する" _ – phil
ええ、私はそれがそんな風に聞こえるが、時間の経過とともに利用可能なメモリの量が減少しているのを見るだろう。間違いなく良い考え。 –
Statementオブジェクトは決して閉じられていないし、しばらくしてヒープを埋めるため、前に説明したようなものを見ました。 VisualVMなどのツールを使用して、大部分のメモリを使用しているものを確認し、それが成長し続けるかどうかを確認します。 – phil