ガベージコレクタ：CMSのプリクリーニングの問題を中止しますか？

Question

ヒープメモリに問題があります。毎日のメモリが100MB増えて増え続け、FULL GCが1.5GBの制限の後に実行されましたが、それでも回復しませんでした。 ログを確認した後、CMS：precleanを中止しますか？これが要因になる可能性があります。 助けていただければ幸いです。

CMS：時間のためにプリクリーニングを中止しますか？任意のアイデアをどのようにこれを解決するには？

環境：Javaの1.6

Here are my GC params: 


-Dfile.encoding=UTF-8 \ 
    -Duser.timezone=US/Eastern \ 
    -Dsun.net.inetaddr.ttl=60 \ 
    -Dsun.net.inetaddr.negative.ttl=60 \ 
    -Xms1024m \ 
    -Xmx1536m \ 
    -Xss512k \ 
    -verbose:gc \ 
    -Xloggc:$CATALINA_BASE/logs/gc_log \ 
    -XX:+DisableExplicitGC \ 
    -XX:+HeapDumpOnOutOfMemoryError \ 
    -XX:+PrintGCDetails \ 
    -XX:+PrintGCTimeStamps \ 
    -XX:+UseConcMarkSweepGC \ 
    -XX:+UseParNewGC \ 
    -XX:CMSInitiatingOccupancyFraction=50 \ 
    -XX:GCTimeRatio=99 \ 
    -XX:MaxNewSize=512m \ 
    -XX:MaxTenuringThreshold=30 \ 
    -XX:NewSize=512m \ 
    -XX:SurvivorRatio=6 \ 
    -XX:TargetSurvivorRatio=90 \ 

**495747.455: [CMS-concurrent-mark-start] 
495749.159: [CMS-concurrent-mark: 1.705/1.705 secs] [Times: user=1.91 sys=0.05, real=1.71 secs] 
495749.159: [CMS-concurrent-preclean-start] 
495749.166: [CMS-concurrent-preclean: 0.006/0.007 secs] [Times: user=0.01 sys=0.00, real=0.00 secs] 
495749.166: [CMS-concurrent-abortable-preclean-start] 
495752.728: [GC 495752.728: [ParNew: 432226K->29458K(458752K), 0.0462900 secs] 1419590K->1016821K(1507328K), 0.0464200 secs] [Times: user=0.08 sys=0.00, real=0.04 secs] 
CMS: abort preclean due to time 495754.230: [CMS-concurrent-abortable-preclean: 2.067/5.063 secs] [Times: user=2.43 sys=0.11, real=5.06 secs] 
495754.230: [GC[YG occupancy: 146431 K (458752 K)]495754.230: [Rescan (parallel) , 0.0446310 secs]495754.275: [weak refs processing, 0.0000080 secs] [1 CMS-remark: 987363K(1048576K)] 1133794K(1507328K), 0.0447400 secs] [Times: user=0.07 sys=0.00, real=0.05 secs]** 

Answer 1

abortable前洗浄はabortableです。それは問題かもしれませんが、私はあなたの心配が最も少ないと思っています。

このメモリがどこかに保持されているため、フルGC後にメモリがクリーンアップされない場合。なぜ私はこのメモリが保持されているかを見るためにヒープダンプを行います。つまり、あなたが保持しているリソースがあります。

私が利用可能なメモリを増やすことを検討している間、あなたは調査中です。例えば新しいサイズは2 GB、テナントスペースは2 GBです。若い世代のサイズが大きくなると、テナント空間に入るオブジェクトの数が減少し、後でクリーンアップする必要があります。

JVMがかなり効率的に構成できるので、私はあまりにも多くのパラメータを調整しようとはしません。

Answer 2

は、私は、問題が2つのパラメータ

古い世代の占有率がこの値を超えた場合、同時コレクションが呼び出され

-XX:CMSInitiatingOccupancyFraction=50 

であると思いthis question

の重複のように見えます。占有率が50％を超えて一貫してコレクションを繰り返し呼び出している場合、完全なGCにつながる可能性があります。 GC時間比が1％であり、前洗浄phace 5秒から約2秒をとっている、ように

-XX:GCTimeRatio=99 

エラー理由は、このパラメータのかもしれない（これのデフォルトは68％）で前洗浄タイムアウトのために中止された可能性があります。

Xmxを増やすと問題は解決するはずですが、Peter Lawreyは、フラグが動作にどのように影響するかについて非常に分かっていない限り、JVMをあまり調整してはいけないと同意します。 （同時モード故障）： もthis link on GC tuning