| Oracle® JRockitパフォーマンス・チューニング・ガイド リリースR28 B61439-02 |
|
 前 |
 次 |
この章では、アプリケーションのスループットを上げるためにJRockit JVMをチューニングする方法について説明します。
アプリケーションのスループットの最大化を実現するために、どのアプリケーションにも固有の動作があり、JVMでの固有の要件があります。Oracle JRockit JVMの標準の動作は、ほとんどのアプリケーションでパフォーマンスに優れています。ただし、JVMをさらにチューニングしてアプリケーションのスループットを向上させることもできます。
この章の内容は次のとおりです。
このドキュメントでアプリケーションのスループットとは、Javaアプリケーションの実行速度を指します。対象のアプリケーションがトランザクションベースのシステムである場合、高いスループットとは所定の時間中に実行されるトランザクションが多いことを示します。スループットの測定は、特定のタスクまたは計算を実行するのにかかる時間を測定して行うこともできます。
アプリケーションのスループットを測定するには、ベンチマークが必要です。ベンチマークでは、アプリケーションの実際のユース・ケースをいくつかシミュレートする必要があります。さらに、JVMがウォーム・アップして、ガベージ・コレクションを実行できるだけの時間、ベンチマークを実行する必要があります。また、結果を測定する方法も必要です。これは、特定のアクション・セット全体の実行時間を測定する方法か、特定の時間に実行できるトランザクションの数を測定する方法のいずれかになります。スループットの評価を最適な状態で行うため、ベンチマークは高い負荷で実行し、データベース接続などの外部入力に依存しないことが必要です。
ベンチマークを設定したら、以下の方法のいずれかを使用してJVMの動作をモニターできます。
Oracle JRockit Mission Control内のJRockitフライト・レコーダを使って、実行時分析を作成します。フライト・レコーダ・ツールでは、ガベージ・コレクションの頻度と、ガベージ・コレクションが起動した理由も表示されます。この情報からメモリー管理をチューニングするためのヒントを得ることができます。フライト・レコーダ・レポートの作成および分析の詳細は、Oracle JRockit Mission Controlオンライン・ヘルプを参照してください。
-Xverboseオプションを使用して、冗長出力を作成します。たとえば、-Xverbose:memdbg,gcpause,gcreportオプションを使用すると、ガベージ・コレクションの頻度や期間などのメモリー管理データが表示されます。-Xverbose:memdbgオプションを使用すると、ガベージ・コレクションの起動の理由も表示されます。これは、ガベージ・コレクションの動作の理解に役立ちます。
これで、Javaアプリケーションのスループットを測定するツールが用意できました。アプリケーションのスループットを向上させるためにJVMのチューニングを開始できます。
アプリケーションのスループットを最大化するためにJRockit JVMをチューニングする第1段階として、適切なガベージ・コレクション・モードまたは方式を選択します。使用できるオプションは次のとおりです。
スループットを優先して最適化された動的なガベージ・コレクション・モード
これは、JRockit JVMのデフォルトのガベージ・コレクション・モードです。このモードによって、最大のアプリケーション・スループットを実現する最適なガベージ・コレクション方式が選択されます。
動的なガベージ・コレクション・モードを使用したくない場合は、かわりに、このガベージ・コレクションを使用してもよいでしょう。世代別パラレル・ガベージ・コレクタは、多数の一時オブジェクトを割り当てるアプリケーションに高いスループットを提供します。
動的なガベージ・コレクション・モードを使用したくない場合は、かわりに、このガベージ・コレクションを使うこともできます。シングル・スペース・パラレル・ガベージ・コレクタは、主に大規模オブジェクトを割り当てるアプリケーションに高いスループットを提供します。
ガベージ・コレクタのオプションの詳細は、4.2項「ガベージ・コレクタの選択とチューニング」を参照してください。
JRockit JVMのデフォルトのガベージ・コレクション・モード(デフォルトのサーバー・モードで実行している場合)では、最大のアプリケーション・スループットを実現するためにメモリー管理をチューニングします。デフォルトでは、世代別パラレル・ガベージ・コレクション方式が選択されます。ガベージ・コレクション方式が世代別の場合には、ナーサリ・サイズもチューニングされます。
スループットを優先して最適化された動的なガベージ・コレクション・モードを使用している場合、ガベージ・コレクションの休止時間には厳密な時間制限がないことに注意してください。長いレイテンシの影響を受けやすいアプリケーションの場合、スループットを最大化するよりもレイテンシを低くするようにチューニングするか、レイテンシを受け入れることができる中間の方針を見いだす必要があります。
スループットを優先して最適化された動的なガベージ・コレクション・モードは、JRockit JVMのデフォルトのガベージ・コレクタです。次のように指定して、このガベージ・コレクタを明示的に有効にすることもできます。
java -Xgc:throughput myApplication
静的なガベージ・コレクタを使用する場合、アプリケーションのスループットを最大化するには、パラレル・ガベージ・コレクタを使用する必要があります。大きなオブジェクトと小さなオブジェクトの割当て比率が高い場合は、シングルスペース・ガベージ・コレクタ(-Xgc:singlepar)を使用します。アプリケーションのフライト・レコーダ記録を行うと、大きなオブジェクトと小さなオブジェクトの割当て比率を確認できます。
アプリケーションのスループットを最大化する必要があり、大きなオブジェクトと小さなオブジェクトの割当て比率が低い場合は、世代別パラレル・ガベージ・コレクタ(-Xgc:genpar)を使用します。非常に小さなナーサリを使用している場合は、大きなオブジェクトと小さなオブジェクトの割当て比率が高くても、世代別パラレル・ガベージ・コレクタが適している場合もあります。アプリケーションのフライト・レコーダ記録を行うと、大きなオブジェクトと小さなオブジェクトの割当て比率を確認できます。
デフォルトのヒープ・サイズは64MBで、そこから3GB(64ビット・システムの場合)または1GB(32ビット・システムの場合)まで増やすことができます。ほとんどのサーバー・アプリケーションは、スループットを最適化するために大きなヒープ(少なくとも1GBを超えるサイズ)を必要とします。このようなアプリケーションでは、-Xms(初期ヒープ・サイズ)と-Xmx(最大ヒープ・サイズ)のコマンドライン・オプションを使用して、ヒープ・サイズを手動で設定する必要があります。通常、-Xmsと-Xmxを同じサイズに設定するのが、スループットが最も大きく向上する構成であると言われています。
例:
java -Xms:2g -Xmx:2g myApplication
初期および最大のヒープ・サイズの設定方法と、これらの設定値に関するガイドラインについては、4.4項「メモリー割当てのパフォーマンスの最適化」を参照してください。
ナーサリ(若い世代)とは、世代別ガベージ・コレクタ(-Xgc:throughput、-Xgc:genparまたは-Xgc:gencon)の実行時にオブジェクトが割り当てられるヒープ内の空きチャンクの領域です。Javaアプリケーションのほとんどのオブジェクトは若い世代で期限切れになるため、ナーサリは非常に有益です。若い領域からガベージを収集した方が、ヒープ全体を収集するよりも有利です。コストが低くなるうえに、若い領域の大部分のオブジェクトは、コレクションが開始されたときにはすでに期限切れになっているからです。
世代別ガベージ・コレクタを使用している場合は、若い世代のオブジェクトをうまく処理できるように、ナーサリの設定を変更することが必要になる場合があります。
-Xgc:throughputおよび-Xgc:genparを指定すると、ナーサリ・サイズが実行時に動的に変更されます。手動でチューニングした方が効率的なナーサリ・サイズになる場合もあります。
-Xgc:genconを指定すると、かなり低い静的なナーサリ・サイズ設定になります。このガベージ・コレクタを使用する場合、多くのアプリケーションでナーサリ・サイズを手動でチューニングしたほうがよい場合があります。
古いコレクション(ヒープ全体のガベージ・コレクション)ではなく若いコレクション(ナーサリのガベージ・コレクション)によって解放されたメモリーの量ができるだけ高くなるのが、効率的なナーサリ・サイズです。これを実現するには、古いコレクションの後で、空きヒープの半分のサイズに近づくようにナーサリ・サイズを設定する必要があります。
ナーサリのサイズを手動で設定するには、-Xnsオプションを使用します。
例:
java -Xgc:gencon -Xms:2g -Xmx:2g -Xns:512m myApplication
圧縮は、割当て済み領域のチャンクをヒープの最下部に移動して、連続した空きメモリーをヒープの反対側に作るプロセスです。JRockit JVMでは、古いコレクションの実行時にヒープの部分的な圧縮を行います。
ガベージ・コレクタのデフォルトの圧縮設定(-Xgc)では、圧縮時間にできるだけピークを作らないようにする動的圧縮方式が使用されます。この場合、ガベージ・コレクションによる休止時間を均等に保ちながら良好なスループットを維持するように調節されるため、必ずしも実現可能な最高のスループットを得ることはできません。アプリケーションの特性によっては、圧縮をチューニングすることによって十分な効果が得られる場合があります。
良好なスループットを得るために圧縮をチューニングするには、圧縮領域のサイズを増やす方法と、最大参照数を大きくする方法の2つがあります。圧縮領域のサイズを増やすと、ヒープの断片化を減らすのに役立ちます。最大参照数を大きくすると、ガベージ・コレクションのたびに大きな領域を自動的に圧縮できます。これにより、ガベージ・コレクションの頻度が減って、大きなオブジェクトの割当てが高速になるため、スループットが向上します。
これらの圧縮オプションのチューニングの詳細は、4.3項「圧縮のチューニング」を参照してください。
推奨TLAサイズを増やすと、各Javaスレッドが小さなオブジェクトを多数割り当てるときに小さなオブジェクトの割当てが高速になります。これは、スレッドで新しいTLAを取得するたびに同期化する必要がないためです。
Oracle JRockit JVMでは、推奨TLAサイズによって、ナーサリ内で割り当てられたオブジェクトのサイズ制限も決まります。そのため、TLAサイズを増やすと、ナーサリ内で割り当てられるオブジェクトも大きくすることができます。これは、大きなオブジェクトを多数割り当てるアプリケーションに効果的です。JRockitフライト・レコーダ記録には、アプリケーションによって割り当てられた大きなオブジェクトのサイズについて統計が示されます。良好なパフォーマンスを得るための推奨TLAサイズは、少なくともアプリケーションによって割り当てられた最大オブジェクトと同じサイズに設定できます。
TLAサイズの設定方法の詳細は、4.4.1項「スレッド・ローカル領域のサイズを設定する」を参照してください。
