3

次の起動引数を使用して JBoss を実行していますが、GC 時間が長い (>5 分) という問題があります。

-Xms116042m -Xmx116042m -XX:PermSize=256M -XX:MaxPermSize=256M -XX:+UseConcMarkSweepGC -verbose:gc -XX:+PrintGCTimeStamps -XX:+PrintGCDetails -XX:MaxHeapFreeRatio=95

GC 時間を最小限に抑える方法について何か提案はありますか?

注: これらは 16 個のクアッド コア CPU、128 GB の Linux マシンです。

GC ログ:

"CMSbailing out to foreground collection"GC ログに多くのメッセージが表示されます。

130904.206: [GC 130904.206: [ParNew: 240819K->25522K(249216K), 0.2391170 secs] 80798776K->80588205K(118799360K), 0.2395380 secs] [Times: user=2.56 sys=0.01, real=0.24 secs] 
130904.799: [GC 130904.799: [ParNew: 247018K->27648K(249216K), 0.2071170 secs] 80809700K->80601600K(118799360K), 0.2075260 secs] [Times: user=2.61 sys=0.00, real=0.21 secs] 
130905.455: [GC 130905.455: [ParNew: 249216K->27648K(249216K), 0.2808950 secs] 80823168K->80644147K(118799360K), 0.2813140 secs] [Times: user=2.66 sys=0.00, real=0.28 secs] 
130905.765: [Full GC (System) 130905.765: [**CMSbailing out to foreground collection**
131167.602: [CMS-concurrent-mark: 284.753/303.276 secs] [Times: user=909.49 sys=193.05, real=303.23 secs] 
 (concurrent mode interrupted): 80616499K->74658646K(118550144K), 554.7507700 secs] 80651365K->74658646K(118799360K), [CMS Perm : 112620K->112582K(262144K)], 554.7511550 secs] [Times: user=784.15 sys=175.10, real=554.65 secs] 
131461.127: [GC 131461.128: [ParNew: 221568K->27648K(249216K), 0.2620780 secs] 74880214K->74691531K(118799360K), 0.2624960 secs] [Times: user=2.28 sys=0.00, real=0.27 secs] 
131461.698: [GC 131461.699: [ParNew: 249216K->27647K(249216K), 0.3827130 secs] 74913099K->74807895K(118799360K), 0.3829550 secs] [Times: user=3.52 sys=0.41, real=0.39 secs] 
131462.754: [GC 131462.754: [ParNew: 249215K->27648K(249216K), 0.3022410 secs] 75029463K->74827673K(118799360K), 0.3026050 secs] [Times: user=2.36 sys=0.02, real=0.30 secs] 
131463.789: [GC 131463.790: [ParNew: 249216K->22291K(249216K), 0.2396390 secs] 75049241K->74841234K(118799360K), 0.2400980 secs] [Times: user=2.38 sys=0.06, real=0.24 secs]
4

5 に答える 5

1

conc マークを使用するか、並列 gc を使用するかに関係なく、116 Gb のデータをガベージ用にスイープするには、常に多くの時間がかかります。このドキュメントは、GC を調整するための最も役立つ情報源であると常に思っています。GC のチューニングはアプリのニーズに固有のものであり、一般的な解決策はありませんが、多くのオプションを利用できます。

G1GC を使用すると、ヒープが多数の小さな部分に分割され、個別にスイープされるため、もう少し運がよいかもしれませんが、それでもランダムな OOME の影響を受けやすい可能性があります。

GC を調整しても適切な応答時間が得られない場合は、マシンを 16 ～ 32 Gb の RAM を持つ複数の仮想マシンに分割し、クラスタ化します。それが EJB アプリケーションであり、豆を正しく焙煎すれば、見た目ほど苦痛ではないかもしれません。

于 2012-12-12T04:39:45.510 に答える
0

「concurrentmodeinterrupted」というメッセージが表示され、GCの時点でどの世代も満杯ではないように思われるため、完全なGCを引き起こす明示的なSystem.gc（）呼び出しがあると思います。JVMパラメータ-XX：+ ExplicitGCInvokesConcurrentを追加して、System.gc（）呼び出しでCMSを呼び出せるようにしてください。また、自分でSystem.gc（）を呼び出す場合は、その理由を特定し、可能であれば削除してください。

于 2012-12-12T15:13:01.957 に答える
0

フル GC が発生する理由の 1 つは、若い世代が必要以上に早くいっぱいになり、オブジェクトを古い世代にコピーする必要があるためです。したがって、次のオプションを試すことができます

  1. 若い世代の初期サイズを次のように設定します -XX:NewSize=500m -XX:MaxNewSize=500m

  2. 古い世代の係数として若い世代の比率を設定できます –XX:NewRatio=3

お役に立てれば...

于 2012-12-12T04:00:31.247 に答える