ガーベジコレクション制御としてCMS付きパラレルGCを使用する場合は、以下の点に注意してください。
アプリケーション性能低下の可能性
CMS付きパラレルGCを使用した場合に動作するCMS-GC(コンカレント・マーク・スイープGC)は、Javaアプリケーションと同時並列に動作するため、CMS-GC動作分のCPU資源がJavaアプリケーションへ渡りません。そのため、パラレルGCを使用した場合と比較し、Javaアプリケーションにおけるスループット性能/応答性能は低下する可能性があります。ただし、性能低下の度合いは、実行するJavaアプリケーションの処理内容/実行環境により大小様々です。
性能差は、Javaヒープサイズ(注1)のチューニングにより緩和/解決できる可能性があります。
Javaヒープ必要量拡大の可能性
CMS付きパラレルGCを使用した場合に動作するCMS-GCにより、Old世代領域内の空き領域の断片化(フラグメンテーション)が発生します。そのため、パラレルGCやシリアルGCを使用した場合よりも、Javaヒープサイズ(注1)を大きくすることが必要な場合があります(パラレルGCやシリアルGCを使用した際のJavaヒープサイズよりも、10%～20%程度大きくすることが必要となる場合があります)。
New世代領域用GCの性能差の可能性
New世代領域用GCの処理時間が、CMS付きパラレルGCを使用した場合とパラレルGCを使用した場合とでは異なる可能性があります。その時間差により、必要とされる性能がパラレルGCでしか得られない場合は、CMS付きパラレルGCではなく、パラレルGCを使用してください。
New世代領域サイズに関するチューニングの必要性
CMS付きパラレルGCにはNew世代領域およびOld世代領域の大きさを、Javaアプリケーションの実行状況によって自動的に調整する機能がありません。そのためチューニング時の観点として、Javaヒープサイズ(注1)の他に、New世代領域の大きさに関するチューニングも必要となります。またJavaプロセスが多重に走行する場合の観点でのチューニング(システム負荷要因による変動の考慮)も必要となる可能性があります。
getCollectionTime()メソッドと-verbose:gc出力の結果不一致の可能性
CMS-GCが動作している最中にJavaヒープ不足やjava.lang.System.gc()実行などによりFull GC要求が発生した場合、Full GC処理は、実行中のCMS-GC処理の終了を待ってから開始されます。その際、CMS-GCが処理しているデータの整合性を維持させるため、CMS-GC処理の終了は強制的な打ち切り終了ではなく、CMS-GC内で打ち切り可能な処理まで完了させてからの終了になります。そのため、Full GC処理要求の発生から実際にFull GC処理が開始されるまでに、ある程度の時間差が生じる可能性があります。
CMS付きパラレルGCを使用しているJava VMに対するjava.lang.management.GarbageCollectorMXBeanクラスのgetCollectionTime()メソッドの戻り値(ガーベジコレクション処理の累積経過時間)には、Full GC処理要求の発生から実際にFull GC処理が開始されるまでの時間差も含まれます。そのため、純粋にFull GC処理としてのGC処理実行時間を出力している「-verbose:gc」オプション指定時のガーベジコレクション処理の結果ログ情報(Full GCに対するGC処理実行時間)を累積しても、それらの値が一致しない可能性があります。
CMS付きパラレルGC処理で使用される作業用メモリ域の増加
Interstage Application Server V10.0より、64ビットモードで実行されるJDK/JREにおいて、CMS付きパラレルGC処理で使用される作業用メモリ域が、従来よりも大きくなるため、その分、Javaプロセスで必要となるメモリ量が増加します。
オブジェクト参照の圧縮機能を無効としたJDK/JREは、最小で32MB、最大で128MBまで増加する可能性があります。
オブジェクト参照の圧縮機能を有効としたJDK/JREは、最小で32MB、最大で256MBまで増加する可能性があります。
Javaヒープの注意事項
メモリ割り当てプールの大きさになります。
