5

ピーク時にアプリケーションの重大な問題が発生し、アプリケーションが非常に遅くなり、AppDynamics マトリックスをチェックすると、ヒープ メモリがいっぱいになり、毎分 GC が開始され、非常に遅くなります。ここに私のJava（Tomcat）の構成があります

OS version is Redhat 5 Linux

java version "1.6.0_05" 64Bit

Java オプションは-Djava.awt.headless=true -Xmx2048m -XX:MaxPermSize=256m -XX:+HeapDumpOnOutOfMemoryError -XX:+UseConcMarkSweepGC -XX:+DisableExplicitGC

1 分あたりの主要な GC 収集時間 (ミリ秒)

ここに画像の説明を入力

CMS Old Gen の使用量 (MB)

ここに画像の説明を入力

Par Eden スペース (MB)

ここに画像の説明を入力

エデンスペースと古い世代が強硬な線を打つ理由について何か提案はありますか?

アップデート

これは、ヒープ使用量と主要な GC コレクション (緑色の点) の過去 12 時間の画像です。その間、GC は非常に高かったの3:00AM to 7:00AMですが、アプリケーションを再起動すると、7:30AMすべてが良好で、アプリケーションの応答時間が非常に速かったのに、再起動によってすべてが修正されたのはなぜですか?

ここに画像の説明を入力

万歳！4GBヒープで解決した問題

4GB 後の 1 分あたりのメジャー GC 収集時間 (ミリ秒) (ゼロ メジャー GC)

ここに画像の説明を入力

4GB ヒープ後の CMS Old Gen の使用量 (MB)

ここに画像の説明を入力

4GB ヒープ後の Eden スペース (MB)

ここに画像の説明を入力

4

3 に答える 3

3

1 分間に 1 回の主要な GC は、まったく面倒ではありません。通常は約 0.5 秒かかるため、全体的な CPU 使用率の 1/120 になります。また、アプリケーションの負荷が高いとメモリ割り当てが増えるのも当然です。どうやら、しばらくの間存続するいくつかのオブジェクトを割り当てているようです (キャッシュの可能性があります)。

私の結論: 実証された GC の動作は、アプリケーションのメモリ割り当てに問題があることを証明するものではありません。

アップデート

私はあなたの図をもっと注意深く見ました（残念ながら、それらは非常に読みにくいです）。毎分 1 つの GC はありません。1 分あたり60秒の主要な GC があり、これは常に発生していることを意味します。それは大きな問題のように見えます。実際、これらの条件では、通常、「GC 時間のパーセンテージのしきい値を超えた」ために OOME が発生します。使用している CMS コレクタは、実際にはデフォルトのものより遅いことに注意してください。その利点は、「世界を止めない」ということだけです。それはあなたにとって最良の選択ではないかもしれません。ただし、メモリ リーク、またはプログラム設計の一般的な問題があるように見えます。

于 2013-08-16T15:00:12.123 に答える