web-dev-qa-db-ja.com

UseConcMarkSweepGCとUseParallelGC

現在、ガベージコレクション時間が非常に長い問題があります。以下を参照してください。現在の設定では、-Xms1gと-Xmx3gを使用しています。私のアプリケーションはJava 1.4.2。ガベージコレクションフラグを設定していません。見た目では、3GBでは不十分で、ガベージコレクションするオブジェクトがたくさんあります。 。

質問：

ガベージコレクションアルゴリズムを変更する必要がありますか？何を使うべきですか？ -XX:+UseParallelGC or -XX:+UseConcMarkSweepGCを使用する方が良いですか

またはこの組み合わせを使用する必要があります

-XX:+UseParNewGC -XX:+UseConcMarkSweepGC

メモリを占有するのは、主にレポートデータであり、キャッシュデータではありません。また、マシンには16GBのメモリがあり、ヒープを8GBに増やす予定です。

私はまだ理解するのが難しいと思うので、2つのオプションの違いは何ですか。マシンには複数のプロセッサがあります。私は最大5秒のヒットを取ることができますが、30〜70秒は本当に難しいです。

助けてくれてありがとう。

  Line 151493: [14/Jan/2012:11:47:48] WARNING ( 8710): CORE3283: stderr: [GC 1632936K->1020739K(2050552K), 1.2462436 secs]
    Line 157710: [14/Jan/2012:11:53:38] WARNING ( 8710): CORE3283: stderr: [GC 1670531K->1058755K(2050552K), 1.1555375 secs]
    Line 163840: [14/Jan/2012:12:00:42] WARNING ( 8710): CORE3283: stderr: [GC 1708547K->1097282K(2050552K), 1.1503118 secs]
    Line 169811: [14/Jan/2012:12:08:02] WARNING ( 8710): CORE3283: stderr: [GC 1747074K->1133764K(2050552K), 1.1017273 secs]
    Line 175879: [14/Jan/2012:12:14:18] WARNING ( 8710): CORE3283: stderr: [GC 1783556K->1173103K(2050552K), 1.2060946 secs]
    Line 176606: [14/Jan/2012:12:15:42] WARNING ( 8710): CORE3283: stderr: [Full GC 1265571K->1124875K(2050552K), 25.0670316 secs]
    Line 184755: [14/Jan/2012:12:25:53] WARNING ( 8710): CORE3283: stderr: [GC 2007435K->1176457K(2784880K), 1.2483770 secs]
    Line 193087: [14/Jan/2012:12:37:09] WARNING ( 8710): CORE3283: stderr: [GC 2059017K->1224285K(2784880K), 1.4739291 secs]
    Line 201377: [14/Jan/2012:12:51:08] WARNING ( 8710): CORE3283: stderr: [Full GC 2106845K->1215242K(2784880K), 30.4016208 secs]


xaa:1: [11/Oct/2011:16:00:28] WARNING (17125): CORE3283: stderr: [Full GC 3114936K->2985477K(3114944K), 53.0468651 secs] --> garbage collection occurring too often as noticed in the time. garbage being collected is quite low and if you would notice is quite close the the heap size. during the 53 seconds, this is equivalent to a pause.
xaa:2087: [11/Oct/2011:16:01:35] WARNING (17125): CORE3283: stderr: [Full GC 3114943K->2991338K(3114944K), 58.3776291 secs]
xaa:3897: [11/Oct/2011:16:02:33] WARNING (17125): CORE3283: stderr: [Full GC 3114940K->2997077K(3114944K), 55.3197974 secs]
xaa:5597: [11/Oct/2011:16:03:00] WARNING (17125): CORE3283: stderr: [Full GC[Unloading class Sun.reflect.GeneratedConstructorAccessor119]
xaa:7936: [11/Oct/2011:16:04:36] WARNING (17125): CORE3283: stderr: [Full GC 3114938K->3004947K(3114944K), 55.5269911 secs]
xaa:9070: [11/Oct/2011:16:05:53] WARNING (17125): CORE3283: stderr: [Full GC 3114937K->3012793K(3114944K), 70.6993328 secs]
javaperformancegarbage-collectiong1gcconcurrent-mark-sweep
27
grassbl8d

GCの休止時間が非常に長いため、GCアルゴリズムの変更が役立つとは思わない。

完全なコレクションしか持っていないことは非常に疑わしいことに注意してください。おそらく、若い世代および/または生存者スペースのサイズを増やす必要があります。

以下も参照してください：

7
axtavt

ヒープが小さすぎます。一時停止は非常に大きいため、収集するものを必死に探してヒープ全体を繰り返しスキャンしているためです。

次の1つ以上を実行する必要があります。

  • メモリリークを見つけて修正する
  • より少ないメモリを使用するようにアプリケーションを調整します
  • jVMが大きなヒープを使用するように構成する

何らかの理由で1.4.2に縛られていますか？それ以来、GCの実装は本当に進んでいるので、可能であればアップグレードを検討する必要があります。これは些細なことではないかもしれませんが、とにかく検討する価値があります。

4
Matt

ステップ1：

  1. アプリケーションに十分なメモリが設定されていることを確認してください。
  2. アプリケーションにメモリリークがないことを確認してください。 Eclipse Memory Analyzer Tool または visualvm は、アプリケーションのリークを識別するのに役立ちます。

ステップ2：

メモリリークに関して手順1で問題がない場合は、「Javaガベージコレクタ」セクションの特定のガベージコレクションアルゴリズムのユースケースに関するOracleドキュメント page および gctuning 記事。

より大きなヒープ（> = 8 GB）を構成することにしたので、G1GCは問題なく動作するはずです。重要なパラメーターの微調整については、この関連するSEの質問を参照してください。

Java 7（JDK 7）ガベージコレクションとG1に関するドキュメント

1
Ravindra babu

生存率が高い場合、ヒープが大きすぎる可能性があります。ヒープが大きいほど、JVMがGCを実行しなくても長くなるため、一度ヒットすると、移動する余地が非常に多くなります。

1
nilskp