web-dev-qa-db-ja.com

Old Genヒープがいっぱいで、EdenとSurvivorが低く、ほとんど空です

実稼働環境は最近非常に遅くなりました。プロセスのCPUは200％かかりました。しかし、動作し続けました。サービスを再起動すると、再び正常に機能しました。いくつかの症状があります：パーサバイバースペースヒープが長い間空であり、ガベージコレクションがCPU時間の約20％を要しました。

JVMオプション：

X:+CMSParallelRemarkEnabled, -XX:+HeapDumpOnOutOfMemoryError, -XX:+UseConcMarkSweepGC, -                XX:+UseParNewGC, -XX:HeapDumpPath=heapdump.hprof, -XX:MaxNewSize=700m, -XX:MaxPermSize=786m, -XX:NewSize=700m, -XX:ParallelGCThreads=8, -XX:SurvivorRatio=25, -Xms2048m, -Xmx2048m

     Arch   AMD64
     Dispatcher Apache Tomcat
     Dispatcher Version 7.0.27
     Framework  Java
     Heap initial (MB)  2048.0
     Heap max (MB)  2022.125
     Java version   1.6.0_35
    Log path    /opt/newrelic/logs/newrelic_agent.log
    OS  Linux
    Processors  8
    System Memory   8177.964, 8178.0

添付の写真の詳細情報ヒープ以外で問題が発生すると、使用済みコードキャッシュと使用済みcms perm genが半分になりました。

Newrelicから情報を取得しました。enter image description here

問題は、サーバーの動作が非常に遅くなる理由です。

サーバーが完全に停止する場合もありますが、PDFをアップロードする際にPDFBoxに問題があり、フォントが含まれているとJVMがクラッシュすることがあります。

詳細：旧世代が毎日いっぱいになっていることに気付きました。今、私は毎日サーバーを再起動します。再起動後はすべてナイスでダンディですが、古い世代は翌日までいっぱいになり、サーバーは再起動が必要になるまで遅くなります。

javagarbage-collectionjvm
22
Bogdan

デフォルトでは、OldGenが70％の場合、CMSは同時に収集を開始します。この境界より下のメモリを解放できない場合、永続的に並行して実行され、操作が大幅に遅くなります。 OldSpaceが完全にOldGenの使用に近づいている場合、パニックに陥り、非常に長い（20秒など）可能性のある世界停止GC一時停止にフォールバックします。 OldGenには、おそらくより多くのヘッドルームが必要です（アプリがメモリをリークしないようにしてください！）。さらに、しきい値を下げて、同時収集を開始できます（デフォルトは70％）。

-XX：+ UseCMSInitiatingOccupancyOnly -XX：CMSInitiatingOccupancyFraction = 50

これにより、使用率が50％から始まる同時収集がトリガーされ、CMSが時間内にGCを終了する可能性が高くなります。これは、割り当て率が高すぎる場合にのみ役立ちます。チャートからは、十分でないheadrooom/memleak +高すぎるXX：CMSInitiatingOccupancyFractionのように見えます。少なくとも500MB〜1 GBのOldGenスペースを追加します

26
R.Moeller