診断ガイド

アプリケーションのスループットを向上させるチューニング

アプリケーションのスループットの最大化を実現するために、どのアプリケーションにも固有の動作があり、JVM での固有の要件があります。ほとんどのアプリケーションで、Oracle JRockit JVM の動作は「標準のまま」でパフォーマンスに優れています。しかし、多くの場合、JVM をより詳細にチューニングすれば、アプリケーションのスループットをさらに上げることができるため、アプリケーションの実行が高速化します。

この章では、アプリケーションのスループットを上げるために JRockit JVM をチューニングする方法について説明します。以下の内容について説明します。

アプリケーションのスループットの測定

このドキュメントで「アプリケーションのスループット」とは、Java アプリケーションの実行速度を指します。対象のアプリケーションがトランザクション ベースのシステムである場合、高いスループットとは所定の時間中に実行されるトランザクションが多いことを示します。スループットの測定は、特定のタスクまたは計算を実行するのにかかる時間を測定して行うこともできます。

アプリケーションのスループットを測定するには、ベンチマークが必要です。ベンチマークでは、アプリケーションの実際のユース ケースをいくつかシミュレートする必要があります。さらに、JVM がウォームアップして、ガベージ コレクションを実行できるだけの時間、ベンチマークを実行する必要があります。また、結果を測定する方法も必要です。これは、特定のアクション セット全体の実行時間を測定する方法か、特定の時間に実行できるトランザクションの数を測定する方法のいずれかになります。スループットの評価を最適な状態で行うため、ベンチマークは高い負荷で実行し、データベース接続などの外部入力に依存しないことが必要です。

ベンチマークを設定したら、以下の方法のいずれかを使用して JVM の動作をモニタできます。

これで、Java アプリケーションのスループットを測定するツールが用意できました。アプリケーションのスループットを向上させるために JVM のチューニングを開始できます。

ガベージ コレクタの選択

アプリケーションのスループットを最大化するために JRockit JVM をチューニングする第 1 段階として、適切なガベージ コレクション モードまたは方式を選択します。

さまざまなガベージ コレクタのオプションの詳細については、「ガベージ コレクタの選択とチューニング」を参照してください。

スループットを優先して最適化された動的なガベージ コレクション モード

JRockit JVm のデフォルトのガベージ コレクション モード (デフォルトのサーバ モードで実行している場合) では、最大のアプリケーション スループットを実現するためにメモリ管理をチューニングします。アプリケーションの動作に応じて、世代別または非世代別パラレル ガベージ コレクション方式が選択されます。ガベージ コレクション方式が世代別の場合には、ナーサリ サイズもチューニングします。

スループットを優先して最適化された動的なガベージ コレクション モードを使用している場合、ガベージ コレクションの休止時間には厳密な時間制限がないことに注意してください。長いレイテンシの影響を受けやすいアプリケーションの場合、スループットを最大化するよりもレイテンシを低くするようにチューニングするか、レイテンシを受け入れることができる中間の方針を見いだす必要があります。

スループットを優先して最適化された動的なガベージ コレクション モードは、JRockit JVM のデフォルトのガベージ コレクタです。以下を指定して、このガベージ コレクタを明示的に有効にすることもできます。

java -XgcPrio:throughput myApplication

静的なシングルスペース パラレル ガベージ コレクション

静的なガベージ コレクタを使用する場合、アプリケーションのスループットを最大化するには、パラレル ガベージ コレクタを使用する必要があります。大きなオブジェクトと小さなオブジェクトの割り当て比率が高い場合は、シングルスペース ガベージ コレクタ (-Xgc:singlepar) を使用します。アプリケーションの JRA 記録を行うと、大きなオブジェクトと小さなオブジェクトの割り当て比率を確認できます。

静的なガベージ コレクタを使用してスループットを向上させるには、さらに -X または -XX のオプションの設定が必要な場合もあります。

静的な世代別パラレル ガベージ コレクション

アプリケーションのスループットを最大化する必要があり、大きなオブジェクトと小さなオブジェクトの割り当て比率が低い場合は、世代別パラレル ガベージ コレクタ (-Xgc:genpar) を使用します。非常に小さなナーサリを使用している場合は、大きなオブジェクトと小さなオブジェクトの割り当て比率が高くても、世代別パラレル ガベージ コレクタが適している場合もあります。アプリケーションの JRA 記録を行うと、大きなオブジェクトと小さなオブジェクトの割り当て比率を確認できます。

静的なガベージ コレクタを使用してスループットを向上させるには、さらに -X または -XX のオプションの設定が必要な場合もあります。

ヒープ サイズのチューニング

デフォルトのヒープ サイズは 64MB で、そこから 1GB まで増やすことができます。ほとんどのサーバ アプリケーションは、スループットを最適化するために大きなヒープ (少なくとも 1GB を超えるサイズ) を必要とします。このようなアプリケーションでは、-Xms (初期ヒープ サイズ) と -Xmx (最大ヒープ サイズ) のコマンドライン オプションを使用して、ヒープ サイズを手動で設定する必要があります。通常 -Xms と -Xmx を同じサイズに設定するのが、スループットが最も大きく向上するコンフィグレーションと言われています。以下に例を示します。

java -Xms:2g -Xmx:2g myApp

初期および最大のヒープ サイズの設定方法と、これらの設定値に関するガイドラインについては、「メモリ割り当てのパフォーマンスの最適化」を参照してください。

ナーサリ サイズの手動でのチューニング

ナーサリ (若い世代) とは、世代別ガベージ コレクタ (-XgcPrio:throughput、-Xgc:genpar または -Xgc:gencon) の実行時にオブジェクトが割り当てられるヒープ内の空きチャンクの領域です。Java アプリケーションのほとんどのオブジェクトは若い世代で期限切れになるため、ナーサリは非常に有益です。若い領域からガベージを収集した方が、ヒープ全体を収集するよりも有利です。コストが低くなるうえに、若い領域の大部分のオブジェクトは、コレクションが開始されたときにはすでに期限切れになっているからです。

世代別ガベージ コレクタを使用している場合は、若い世代のオブジェクトをうまく処理できるように、ナーサリの設定を変更することが必要になる場合があります。

古いコレクション (ヒープ全体のガベージ コレクション) ではなく若いコレクション (ナーサリのガベージ コレクション) によって解放されたメモリの量ができるだけ高くなるのが、効率的なナーサリ サイズです。これを実現するには、古いコレクションの後で、空きヒープの半分のサイズに近づくようにナーサリ サイズを設定する必要があります。

ナーサリのサイズを手動で設定するには、-Xns コマンドライン オプションを使用します。たとえば次のようにします。

java -Xgc:gencon -Xms:2g -Xmx:2g -Xns:512m myApp

圧縮の手動でのチューニング

圧縮は、割り当て済み領域のチャンクをヒープの最下部に移動して、連続した空きメモリをヒープの反対側に作るプロセスです。JRockit JVM では、古いコレクションの実行時にヒープの部分的な圧縮を行います。

静的ガベージ コレクタのデフォルトの圧縮設定 (-Xgc または -XXsetGC) では、圧縮時間にできるだけ「ピーク」を作らないようにする動的圧縮スキームが使用されます。この場合、ガベージ コレクションによる休止時間を均等に保ちながら良好なスループットを維持するように調節されるため、必ずしも実現可能な最高のスループットを得ることはできません。アプリケーションの特性によっては、圧縮をチューニングすることによって十分な効果が得られる場合があります。

良好なスループットを得るために圧縮をチューニングするには、圧縮領域のサイズを増やす方法と、圧縮設定の制限を大きくする方法の 2 つがあります。圧縮領域のサイズを増やすと、ヒープの断片化を減らすのに役立ちます。圧縮設定の制限を大きくすると、ガベージ コレクションのたびに大きな領域を自動的に圧縮できます。これにより、ガベージ コレクションの頻度が減って、大きなオブジェクトの割り当てが高速になるため、スループットが向上します。

これらの圧縮オプションのチューニングについては、「メモリの圧縮のチューニング」を参照してください。

スレッドローカル領域サイズのチューニング

スレッドローカル領域 (TLA) とは、オブジェクトの割り当てに使用される空きメモリのチャンクです。TLA はヒープから確保され、要求に応じて Java スレッドに与えられます。これにより、Java スレッドはオブジェクトを割り当てるときに、他の Java スレッドとの同期化を行う必要がなくなります。

推奨 TLA サイズを増やすと、各 Java スレッドが小さなオブジェクトを多数割り当てるときに小さなオブジェクトの割り当てが高速になります。これは、スレッドで新しい TLA を取得するたびに同期化する必要がないためです。

Oracle JRockit JVM R27.3 以降のリリースでは、推奨 TLA サイズによって、ナーサリ内で割り当てられたオブジェクトのサイズ制限も決まります。そのため、TLA サイズを増やすと、ナーサリ内で割り当てられるオブジェクトも大きくすることができます。これは、大きなオブジェクトを多数割り当てるアプリケーションに効果的です。以前のバージョンでナーサリ内に大きなオブジェクトを割り当てるには、TLA サイズと大きなオブジェクトの制限の両方を設定する必要があります。JRA 記録には、アプリケーションによって割り当てられた大きなオブジェクトのサイズについて統計が示されます。良好なパフォーマンスを得るための推奨 TLA サイズは、少なくともアプリケーションによって割り当てられた最大オブジェクトと同じサイズに設定できます。

TLA サイズの設定方法の詳細については、「スレッド ローカル領域のサイズを設定する」を参照してください。