若い世代のJavaガベージコレクションはどのような場合に最後になりますか？

Question

昨日、私たちは1台のJBossアプリケーションサーバの当社のサーバーログに次のGC出力を持っていた：

51628.286: [GC 51628.288: [ParNew: 1843200K->204800K(1843200K), 21.3196040 secs] 
5177730K->3743415K(7987200K), 21.3217870 secs] 
[Times: user=1.38 sys=0.33, real=21.32 secs] 

私はこのような出力を理解する：若い世代はサイズ1843200Kです。生成前のサイズは1843200Kで、サイズは204800K以降でした。コレクションは21.3秒持続した。

通常、私たちの若い世代のコレクションは、最後に< 1秒です。どのような状況では、ygコレクションは長続きするのですか？

当社のJVMのparams：

-server 
-verbose:gc 
-XX:+PrintGCTimeStamps 
-XX:+PrintGCDetails 
-XX:NewRatio=3 
-XX:+UseConcMarkSweepGC 
-XX:+UseParNewGC 
-XX:+UseCMSCompactAtFullCollection 
-XX:CMSInitiatingOccupancyFraction=60 
-XX:MaxPermSize=256m 
-Xss512k 
-Xms8000m 
-Xmx8000m 

Javaバージョン：私たちは〜2分続いたガベージコレクションを持っていたTomcatサーバーを持っていた

java version "1.6.0_29" 
Java(TM) SE Runtime Environment (build 1.6.0_29-b11) 
Java HotSpot(TM) 64-Bit Server VM (build 20.4-b02, mixed mode) 

おかげで、 マルセル

Answer 1

。結局のところ、私たちは、システム上に物理メモリを持っていたよりも、-Xmxを使ってJVMにもっと多くのメモリを割り当てていたことが分かりました。これはガベージコレクション中にページングを引き起こし、ガベージコレクションが終了しました。

また、同じ物理マシン上で複数のVMを実行していました。サーバー上の物理メモリより多くのメモリをすべてのVMに割り当てていないことを確認してください。詳細については

、Tuning the Memory Management System, section Setting the Heap Size（私の強調）を参照してください。

コマンドラインオプション：-Xms：-Xmx：

ヒープサイズが割り当て速度に影響を与え、ガベージコレクション 周波数をし、ガベージコレクション時間。小さなヒープは完全に になり、より頻繁にガベージコレクションされる必要があります。 断片化が発生しやすくなり、オブジェクトの割り当てが遅くなります。大きなヒープ は、ガベージコレクションの時間に若干のオーバーヘッドを導入します。 ヒープがシステム内の使用可能な物理メモリより大きい場合は、アクセス時間が長くなり、さらには のアプリケーションがフリーズし、特にガベージコレクション中にの間にディスクにページアウトされる可能性があります（ ）。

Answer 2

私はそれが壁時計の時間を計算していると考えています。そのため、他のプロセスがGCを中断してしばらく実行すると、それは誤って報告されます。

若い世代ではコレクションに長時間かかることはないはずです.GCのコストは到達可能なアイテムの数に比例し、数字にはまだ分数しか到達できないことが示されています。

参照キュー管理と実行中のファイナライザは、かなりの時間を要する可能性がありますが、その数には数えません（？）。

http://www.oracle.com/technetwork/java/javase/gc-tuning-6-140523.htmlには、GCチューニングに関するヒントがあります。

Answer 3

別のスレッドで実行される同時ガベージコレクタ（-XX:+UseConcMarkSweepGC）を使用しています。投稿したTimes出力から、ガベージコレクタ自体が長く動かなかったようです。私はあなたのシステムは、GCが実行するために残っているCPU時間が十分ではなかったと推測します。したがって、GCが必要なCPU時間を1秒で得るのに20秒かかりました。並列GCを使用する場合は、アプリケーションがすべてのCPU時間を消費しないようにする必要があります。

他のことが起こる可能性があります。同時コレクタが十分なメモリを解放できず、一定のバリアに達した場合、他のすべてのスレッドをブロックし、多くの時間を消費するFull GCを行います。このフルGCはわずかに異なる出力を持っています（GCの代わりにFull GCと表示されます）。だから私はこれがあなたの問題ではないと思います。私はちょうど巨大なメソッドを持つことが、長いGCの一時停止を引き起こす可能性があることを言ってarticleつまずい

Answer 4

（それは最後のセクションです）抜粋：

メソッドがコンパイルされると、コンパイラが生成し、オブジェクト参照に関する情報を保存しますlive （これはGCに役立ち、oopマップと呼ばれます）特定のサイズを超えるメソッドは、ホットスポットではJITされません。 ...メソッドがJITされていない場合、GCはGC中にoopマップ自体を生成する必要があります。 ...大規模なメソッドは、oopマップを生成するための抽象的な解釈時間が長いことを意味します。 ....ところで、巨大な方法は2500行のようなものだったので、それは私が巨大と呼ぶものでした。

（太字のテキストが挿入された）