ガーベジコレクション制御としてCMS付きパラレルGCを使用する場合は、以下の点に注意してください。
CMS付きパラレルGCが使用できるエディション
CMS付きパラレルGCによるGC制御は、以下のエディションに搭載されたJDK/JRE 5.0、6にだけ提供しています。
Interstage Application Server Enterprise Edition
アプリケーション性能低下の可能性
CMS付きパラレルGCを使用した場合に動作するCMS-GC(コンカレント・マーク・スイープGC)は、Javaアプリケーションと同時並列に動作するため、CMS-GC動作分のCPU資源がJavaアプリケーションへ渡りません。そのため、パラレルGCを使用した場合と比較し、Javaアプリケーションにおけるスループット性能/応答性能は低下する可能性があります。ただし、性能低下の度合いは、実行するJavaアプリケーションの処理内容/実行環境により大小様々です。
性能差は、Javaヒープサイズのチューニングにより緩和/解決できる可能性があります。
Javaヒープ必要量拡大の可能性
CMS付きパラレルGCを使用した場合に動作するCMS-GCにより、Old世代領域内やPermanent世代領域内の空き領域の断片化(フラグメンテーション)が発生します。そのため、パラレルGCやシリアルGC/FJGCを使用した場合よりも、Javaヒープサイズを大きくすることが必要な場合があります(パラレルGCやシリアルGC/FJGCを使用した際のJavaヒープサイズよりも、10%～20%程度大きくすることが必要となる場合があります)。
New世代領域用GCの性能差の可能性
New世代領域用GCの処理時間が、CMS付きパラレルGCを使用した場合とパラレルGCを使用した場合とでは異なる可能性があります。その時間差により、必要とされる性能がパラレルGCでしか得られない場合は、CMS付きパラレルGCではなく、パラレルGCを使用してください。
New世代領域サイズに関するチューニングの必要性
CMS付きパラレルGCにはNew世代領域およびOld世代領域の大きさを、Javaアプリケーションの実行状況によって自動的に調整する機能がありません。そのためチューニング時の観点として、Javaヒープサイズ(メモリ割り当てプールの大きさとPermanent世代領域の大きさ)の他に、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処理実行時間)を累積しても、それらの値が一致しない可能性があります。
JDK/JRE 5.0のJVMTI
JDK/JRE 5.0を使用し、GC処理としてCMS付きパラレルGCが選択されている場合、Java Virtual Machine Tool Interface(JVMTI)で、以下の権限を必要とする機能は使用できません。
can_tag_objects
can_generate_object_free_events
CMS-GCの対象をPermanent世代領域内まで拡大した場合のCMS-GC実行時間の増加
CMS-GCによる不要オブジェクトの回収対象を、Old世代領域内だけでなくPermanent世代領域内にまで拡大した場合、CMS-GCとしての処理対象域が増加することになるため、CMS-GC完了までの実行時間増加に繋がり易くなります。その結果、実行するアプリケーションや実行環境によっては、CMS-GCによる回収処理が間に合わなくなり、FullGCの発生に繋がる場合もありえます。
そのため、回収対象が「Old世代領域内」で正常動作していた環境において、回収対象を「Old世代領域内およびPermanent世代領域内」にまで拡大する場合は、再度のチューニング作業が必要となります．
CMS付きパラレルGC処理で使用される作業用メモリ域の増加
Interstage Application Server V10.0より、64ビットモードで実行されるJDK/JREにおいて、CMS付きパラレルGC処理で使用される作業用メモリ域が、従来よりも大きくなるため、その分、Javaプロセスで必要となるメモリ量が増加します。
JDK/JRE 5.0およびオブジェクト参照の圧縮機能を無効としたJDK/JRE 6の場合は、最小で32MB、最大で128MBまで増加する可能性があります。
オブジェクト参照の圧縮機能を有効としたJDK/JRE 6の場合は、最小で32MB、最大で256MBまで増加する可能性があります。
Solaris上でCMS付きパラレルGCを使用する場合の注意
SPARC Enterprise Tシリーズ上、またはSPARC Tシリーズ上で実行するJavaアプリケーションにおいて、GC処理としてCMS付きパラレルGCを使用する場合は、実行するJavaプロセス環境に対して、環境変数「LD_NOAUXFLTR=1」を設定する必要があります。
環境変数の設定方法については、各マニュアルを参照してください。
IJServerクラスタの場合
asadminコマンドまたはInterstage Java EE管理コンソールを用いて設定してください。
詳しくは、以下のマニュアルを参照してください。
Java EE運用ガイド
「定義項目一覧」-「動作環境に関する定義項目」-「プロセス制御の定義項目」
IJServer(J2EE)の場合
Interstage管理コンソールを用いて設定してください。
詳しくは、以下のマニュアルを参照してください。
J2EE ユーザーズガイド(旧版互換)
「J2EEアプリケーションの運用」-「ワークユニットの設計」-「環境変数」
Interstage管理コンソールヘルプ V10
「Interstage Application Server」-「システム」-「ワークユニット」-「ワークユニットごとの操作」-「IJServer」-「環境設定」
なお、この設定により、プラットフォーム固有に最適化されたOS処理が無効となるため、Javaアプリケーション実行時の性能が低下します。
