28

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

質問：

ガベージ コレクション アルゴリズムを変更する必要がありますか? 何を使えばいいですか？使ったほうがいいですか-XX:+UseParallelGC or -XX:+UseConcMarkSweepGC

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

-XX:+UseParNewGC -XX:+UseConcMarkSweepGC

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

まだ理解するのが難しいと思うので、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]
4

4 に答える 4

7

GC の一時停止が非常に長いため、GC アルゴリズムの変更が役立つとは思われません。

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

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

于 2012-01-25T16:01:10.353 に答える
4

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

次の 1 つまたは複数を実行する必要があります。

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

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

于 2012-01-25T16:19:35.910 に答える
1

生存率が高い場合、ヒープが大きすぎる可能性があります。ヒープが大きければ大きいほど、JVM は GC なしで実行できる時間が長くなります。

于 2012-03-05T21:38:04.650 に答える
1

ステップ1：

  1. アプリケーションに十分なメモリが設定されていることを確認してください。
  2. アプリケーションでメモリ リークが発生していないことを確認してください。Eclipseメモリ アナライザー ツールまたはvisualvmは、アプリケーションのリークを特定するのに役立ちます。

ステップ2：

メモリ リークに関してステップ 1 で問題がない場合は、「Java ガベージ コレクタ」セクションとgctuning記事の特定のガベージ コレクション アルゴリズムのユース ケースに関する Oracle ドキュメントページを参照してください。

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

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

于 2015-12-09T18:02:21.140 に答える