|
|
全体のスループットは良好でも、長いレイテンシが原因で動作が不安定になるアプリケーションもあります。たとえば、トランザクション ベースのシステムの場合、指定時間内に実行されるトランザクション数という点では適切に処理が行われているように見えますが、低い負荷でもトランザクションがタイムアウトして均等な動作にならないことがあります。アプリケーションまたはアプリケーションの実行環境でレイテンシが発生すると、このようにパフォーマンスが不均等になったり低下したりする場合があります。Java コード内の競合によって発生するすべての事象がレイテンシの原因となる可能性があり、データベース サーバへのネットワーク接続が遅くなります。レイテンシは JVM によって発生する場合もあります。たとえば、どのように JVM がチューニングされているかに応じて、ガベージ コレクション中に発生します。この節では、レイテンシを低下させるために Oracle JRockit JVM をチューニングする方法について説明します。内容は以下のとおりです。
大半のアプリケーション開発者には、各自のアプリケーションについてパフォーマンスを測定する手段があります。たとえば、シミュレートした一連のユース ケースを実行して、その実行にかかった時間、1 分間に実行された特定の種類のトランザクション数、平均トランザクション時間、特定のしきい値を上回るまたは下回るトランザクション時間の割合などを測定できます。レイテンシを低下させるためにチューニングするときは、特定のしきい値を上回るトランザクション時間を測定することが最大の関心事になります。最適なチューニング結果を得るためには、できる限り現実的で多様なベンチマークを用意し、実行時間を長くしなければなりません。多くの場合、最短の実行時間は 20 分間です。数時間実行しないと、チューニングの効果を完全に確認できないこともあります。
長いレイテンシが発生する状況を確認したら、次の方法を使用して JRockit JVM のモニタを開始することができます。
-Xverbose:gcpause を指定して JVM を起動すると、JRockit JVM でガベージ コレクションの休止時間を表示できる。-Xverbose:memdbg,gcpause を使用するとガベージ コレクションによる休止時間を表示できる。パラメータ memdbg を使用すると、ガベージ コレクション中に発生したページ フォールトに関する詳細な出力も表示されます。
これで、チューニングの結果を確認するツールの用意ができました。
レイテンシを低下させるために JRockit JVM をチューニングする第 1 段階として、ガベージ コレクションの休止時間が短いガベージ コレクション モードを選択します。次の 2 つの動的なガベージ コレクション モード、または 1 つの静的なガベージ コレクション方式のいずれかが最適です。これらについては、この節で詳しく説明します。
これは、非常に短く確定的なガベージ コレクションの休止時間を実現するために設計されたガベージ コレクション モードです。Oracle JRockit Real Time の一部として使用できます。
これは、短いガベージ コレクションの休止時間を実現するために設計されたガベージ コレクション モードです。
この静的なガベージ コレクション モードでは、ガベージ コレクションの休止時間が非常に短くなりますが、特定の目標休止時間を優先した最適化は行いません。このガベージ コレクタを選択した場合は、さらにナーサリ サイズおよび圧縮のチューニングが必要になることもあります。
さまざまなガベージ コレクタのオプションの詳細については、「ガベージ コレクタの選択とチューニング」を参照してください。
レイテンシを最小限にする必要があるアプリケーション (電気通信業界や金融業界で使用するアプリケーションなど) の場合、一般的なガベージ コレクション方式による休止時間を予測できないと、この休止時間を守ることができません。このような長すぎる休止時間を回避するため、JRockit JVM では動的なガベージ コレクション モードである「確定的な」ガベージ コレクションが導入されました。これにより、ガベージ コレクションの休止時間が短く確定的なものとして維持されます。
次のようにコマンドラインで確定的なガベージ コレクタを設定します。
java-XgcPrio:deterministic-Xms:1g -Xmx:1gmyApplication
ガベージ コレクタは、ガベージ コレクションの休止時間を所定の目標休止時間以内に抑えることを目指します。これをどの程度まで達成できるかは、アプリケーションおよびハードウェアによって異なります。たとえば、ヒープが 1GB で、コレクション時のライブ データが平均で 30% 以下のアプリケーションを以下のハードウェアで実行する場合、目標休止時間は 30 ミリ秒で検証されます。
低速なハードウェアでアプリケーションを実行している、ヒープ サイズが異なる、ライブ データが多いなどの条件下では、確定的な動作が維持されなかったり、時間の経過に応じてパフォーマンスが低下するおそれがあります。高速なハードウェアを使用するか、ライブ データを少なくすると、目標休止時間を低く設定することができます。
確定的モードの目標休止時間はデフォルトで 30 ミリ秒に設定されていますが、コマンド ライン オプション -XpauseTarget:<time> を使用して変更することもできます。次に例を示します。
java -XgcPrio:deterministic -Xms:1g -Xmx:1g -XpauseTarget:40ms MyApplication
これにより、確定的かつ短い休止時間と、目標休止時間の 40 ミリ秒を優先して最適化されたガベージ コレクション モードで JVM が起動します。
詳細については、「-XpauseTarget」のドキュメントを参照してください。
確定的なガベージ コレクタは、所定の目標休止時間を優先して圧縮を最適化し、ナーサリを使用しません。したがって、確定的なガベージ コレクタを使用する場合は、圧縮およびナーサリ サイズをチューニングする必要がありません。
短い休止時間を優先して最適化された動的なガベージ コレクション モードは、確定的なガベージ コレクタが保証するほど短く確定的な休止時間を必要としないアプリケーションの場合に役立ちます。このガベージ コレクション モードでは、ガベージ コレクションの休止時間を所定の目標休止時間 (デフォルトは 500 ミリ秒) 未満に抑えるようにガベージ コレクション方式を選択します。圧縮によって発生する休止時間を抑えるように、圧縮も自動的に調整されます。
java-XgcPrio:pausetimemyApplication
休止時間の優先順位の使用時にデフォルト (500 ミリ秒) では長すぎるとわかった場合は、-XpauseTarget オプションを使って休止時間の目標値を指定できます。次に例を示します。
java -XgcPrio:pausetime-XpauseTarget=200msmyApplication
短い休止時間と、アプリケーションのスループットは両立しません。ガベージ コレクションの休止時間を短くすると、ブックキーピングのオーバーヘッドが増加することになり、パフォーマンスを低下させる断片化がさらに発生する場合があります。アプリケーションで 500 ミリ秒より長い休止時間を許容できる場合、アプリケーションのパフォーマンスを向上させるために目標休止時間を増やすことができます。
目標値は休止時間の達成目標として、動的なガベージ コレクタが自身をより正確にコンフィグレーションし、休止時間を目標値に近づけるために使用されます。このオプションを使用すると、200 ミリ秒から 5 秒の間で目標休止時間を指定できます。目標休止時間を指定しない場合、デフォルトは 500 ミリ秒のままになります。
短い休止時間を優先するガベージ コレクション モードでは、所定の目標休止時間を目指して圧縮を最適化します。そのため、追加で圧縮をチューニングする必要はありません。ナーサリ サイズは自動的に調整されますが、パフォーマンスを均等化するために、ナーサリ サイズを手動でチューニングしなければならない場合があります。R27.3 以降のリリースでは、このガベージ コレクション モードの場合、ナーサリ サイズは静的であるため、手動でチューニングすることが必要になります。
静的なガベージ コレクタを使用していても休止時間を最低限にする必要がある場合は、コンカレント ガベージ コレクタを使用します。一般に、世代別ガベージ コレクタを使用する方が、シングルスペース ガベージ コレクタを使用するよりも有利です。なぜなら、世代別ガベージ コレクタの方が、より高いアプリケーションのスループットが得られるからです。
世代別コンカレント ガベージ コレクタを使用するには、次のコマンドラインを入力します。
java-Xgc:genconmyApplication
シングルスペース コンカレント ガベージ コレクタを使用するには、次のコマンドラインを入力します。
java -Xgc:singlecon myApplication
静的なガベージ コレクタを使用するときは、ナーサリ サイズと圧縮を手動でチューニングする必要があります。
ヒープ サイズを変更するには、JRockit JVM の起動時にコマンドライン オプションの -Xms (初期最小ヒープ サイズ) と -Xmx (最大ヒープ サイズ) を使用します。通常、初期ヒープ サイズと最大ヒープ サイズは同じ値に設定できます。ヒープ サイズを大きくすると、ガベージ コレクションの頻度が少なくなります。また、ヒープが大きくなると、ガベージ コレクションにかかる時間は若干長くなりますが、一般にヒープ サイズが数ギガバイトに達するまでは、それほど大きな影響はありません。
ヒープ サイズをチューニングする方法として最適なのは、さまざまなヒープ サイズを使用してアプリケーションのベンチマークを測定することです。「レイテンシの測定」に示すようにガベージ コレクションの休止時間をモニタして、アプリケーションの指定可能な最大ヒープ サイズを決定します。
唯一の例外となるのが、確定的なガベージ コレクタです。確定的なガベージ コレクタは約 1GB のヒープを使用して検証され、このサイズのヒープで動作が最適になります。
ヒープ サイズを設定するには、-Xms オプションと -Xmx オプションを使用します。次に例を示します。
java-Xms:1g -Xmx:1gmyApp
詳細については、「メモリ割り当てのパフォーマンスの最適化」を参照してください。
-XgcPrio:pausetime または -Xgc:gencon を実行している場合、ナーサリ サイズを手動でチューニングできます。
-XgcPrio:pausetime を使用する場合、ナーサリのサイズは実行時に動的に変更されますが、ナーサリのサイズを手動で設定すると動作がより均等になります (動的なガベージ コレクタを使用している場合、シングルスペース ガベージ コレクションの使用中は、ナーサリが完全に無効になる可能性があります)。
| 注意 : | Oracle JRockit JVM R27.3 および以降のバージョンでは、-XgcPrio:pausetime を指定して実行されている場合、ナーサリ サイズは静的です。多くの場合、ナーサリ サイズを手動でチューニングすると、休止時間とアプリケーション スループットの両方に有益です。 |
-Xgc:gencon のデフォルト ナーサリ サイズは静的であるため、すべてのアプリケーションに最適な値ではないことがあります。カスタム ナーサリ サイズを手動で設定すると効果的な場合があります。ナーサリはできる限り大きくする必要がありますが、若いコレクション (ナーサリ ガベージ コレクション) によって生じる休止時間が長すぎる場合は、ナーサリ サイズを減らしてください。「レイテンシの測定」に示すように、ガベージ コレクションの休止時間をモニタしながら、いくつかの異なるナーサリ サイズを使用してアプリケーションのベンチマークを測定し、ナーサリ サイズをチューニングします。
ナーサリのサイズを設定するには、-Xns オプションを使用します。たとえば次のようにします。
java-XgcPrio:pausetime-Xns:64mmyApp
静的なガベージ コレクタの使用時は、圧縮を手動でチューニングするとレイテンシを改善できます。圧縮は、ガベージ コレクションの休止時間中に実行されるため、圧縮時間はガベージ コレクションの休止時間に影響します。デフォルトで、静的なガベージ コレクタは、圧縮時間を均等に保つことを目指す圧縮スキームを使用しますが、圧縮時間に上限は設けません。
圧縮を手動で制限するには、静的な圧縮領域サイズを設定する (-XXcompactRatio)、または圧縮によって更新される可能性のある参照数を制限する (-XXcopactSetLimit) ことができます。どちらの方法を使用しても、圧縮時間の上限は保証されませんが、圧縮時間が長くなるリスクは減少します。
圧縮率を低く設定すると、ヒープでは断片化が徐々に進行し、最後にはオブジェクトの割り当てが可能な空き領域を見つけられなくなることに注意してください。ヒープは、「ダーク マター」(基本的には重度の断片化) と呼ばれるもので一杯になります。この状態に陥ると、完全な圧縮 (ヒープ全体の圧縮) が実行されます。その結果、最長で 30 秒間の休止時間が生じます。ダーク マターは、JRA 記録にヒープ関連の情報として報告されます。
圧縮を制限する方法の詳細については、「圧縮を調整する」を参照してください。
-XXgcTrigger オプションを使って、ヒープの空き領域がどこまで減った時点でコンカレント ガベージ コレクションを開始するかを設定できます。コンカレント ガベージ コレクション中にヒープが一杯になると、Java アプリケーションはガベージ コレクションがメモリを解放するまでメモリを割り当てることができません。このため、アプリケーションは休止状態になります。ヒープが一杯にならないようにトリガ値は実行時に自動的にチューニングされますが、この自動のチューニングに時間がかかりすぎることがあります。この機能に頼らずに、-XXgcTrigger オプションを使って、ガベージ コレクションのトリガ値をアプリケーションに適した値に最初から設定できます。
コンカレント マーク フェーズの途中でヒープが一杯になると、スイープ フェーズはパラレル スイープに戻ります (-XXnoParSweep を指定した場合を除く)。この動作が頻繁に起こり、これを回避するためにガベージ コレクションのトリガ値が自動的に増えない場合、-XXgcTrigger を使ってガベージ コレクションのトリガ値を手動で増やしてください。次に例を示します。
java -XXgcTrigger myApp
ガベージ コレクションの現在のトリガ値は、トリガ値が変わった時点で
-Xverbose:memdbg の出力に表示されます。
|