|
|
各 Java アプリケーションには、固有の動作と要件があります。Oracle JRockit JVM は、このような動作と要件の多くに適応できますが、最適なパフォーマンスを得るには、少なくともいくつかの基本のパラメータをチューニングする必要があります。この節では、JRockit JVM のチューニングの初歩と、各種 Oracle アプリケーション用の JVM のチューニングのベスト プラクティスについて説明します。内容は以下のとおりです。
JRockit JVM のチューニングに関する詳細については、「メモリ管理システムのチューニング」および「ロックのチューニング」を参照してください。
ヒープは、Java オブジェクトが格納されている領域です。ヒープが大きいと、ガベージ コレクションの頻度は少なくなりますが、ガベージ コレクションにかかる時間は多少長くなります。通常、ヒープ サイズには、ヒープ内に生存しているオブジェクトのサイズの 2 倍以上の大きさが必要です。つまり、ガベージ コレクションごとに、ヒープの半分が解放される必要があります。サーバ アプリケーションの場合、ページングが発生しない限り、システムが許容する利用可能なメモリの最大値をヒープとして設定する必要があります。
ヒープ サイズを設定するには、以下のコマンド ライン オプションを使用します。
たとえば、2 GB の RAM 容量を持つマシン上で実行しているサーバ アプリケーションを、次の設定で起動します。
java -Xms:800m -Xmx:1000m MyServerApp
これにより、初期値が 800 MB で、1000 MB まで拡張可能なヒープが設定された JVM が起動します。
ヒープ サイズ設定の詳細については、「ヒープ サイズを設定する」を参照してください。
ガベージ コレクションは、使用されなくなったオブジェクトの領域を再構築して、新しいオブジェクトの割り当てに使用するプロセスです。ガベージ コレクションは、さまざまな方法でシステム リソースを使用します。ガベージ コレクションをチューニングすることで、リソースをいつどのように使用するかを決定できます。JRockit JVM には、3 つのガベージ コレクションのモードと、多数の静的なガベージ コレクション方式が用意されています。これらを使用して、アプリケーションの要件に合うように、ガベージ コレクションをチューニングすることができます。
以下のいずれかのオプションを使用して、ガベージ コレクションのモードを選択します。
たとえば、比較的短いレイテンシを必要とするトランザクション ベースのアプリケーションを、次の設定で起動することができます。
java -XgcPrio:pauseTime MyTransactionApp
これによって起動する JVM のガベージ コレクション モードは、ガベージ コレクションの休止時間を短くすることを優先して最適化されています。
ガベージ コレクション モードまたは静的なガベージ コレクション方式の選択の詳細については、「ガベージ コレクタの選択とチューニング」を参照してください。
JRockit JVM のガベージ コレクション モードと方式には、ナーサリを使用するものもあります。ナーサリは、新しいオブジェクトが割り当てられるヒープの領域です。ナーサリが一杯になると、若いコレクションで個別にガベージ コレクションが行われます。ナーサリ サイズは若いコレクションの頻度と期間を決定します。ナーサリを大きくすると、若いコレクションの頻度は減少しますが、個々のコレクションの期間は多少長くなります。
JRockit JVM R27.3.0 以降では、-xgcprio:throughput (デフォルト) または -xgc:genpar を使用すると、アプリケーション スループットを優先した最適化が行われるようにナーサリ サイズが自動的に調整されます。その他のガベージ コレクションのモードまたは JVM の古いバージョンでは、ナーサリ サイズを手動でチューニングしたほうがよい場合もあります。通常は、若いコレクションによる休止時間を適度に短く維持できる範囲で、ナーサリ サイズを最大限大きく設定します。適度なナーサリ サイズは、数メガバイトからヒープサイズの半分程度の範囲であり、アプリケーションに応じて任意の値を設定できます。
ナーサリ サイズを設定するには、以下のコマンド ライン オプションを使用します。
たとえば、2 GB の RAM 容量を持つマシン上で実行しているトランザクション ベースのアプリケーションを、次の設定で起動することができます。
java -Xms:800m -Xmx:1000m -XgcPrio:pausetime -Xns:100m MyTransactionApp
これにより、最小値が 800 MB で、1000 MB まで拡大可能なヒープが設定された JVM が起動します。ガベージ コレクションは休止時間を優先して最適化するように設定されていて、ナーサリ サイズは 100 MB に設定されています。動的なガベージ コレクションのモードは、ナーサリを使わずに実行することもできますが、ナーサリを使用する場合は常に 100 MB です。
ナーサリ サイズのチューニング方法の詳細については、「ナーサリおよび保持領域のサイズを設定する」を参照してください。
-XgcPrio:pausetime および -XgcPrio:deterministic は、目標休止時間を使用して休止時間を最適化する一方で、アプリケーションのスループットをできるだけ高く維持します。目標休止時間を長く設定すると、アプリケーションのスループットも上がります。このため、アプリケーションで許容される範囲で、できるだけ長い休止時間を設定してください。
目標休止時間を設定するには、以下のコマンド ライン オプションを使用します。
たとえば、通常のトランザクションに 100 ミリ秒かかり、400 ミリ秒後にタイムアウトするトランザクションを持つトランザクション ベースのアプリケーションを、次の設定で起動することができます。
java -XgcPrio:pausetime -XpauseTarget:250 MyTransactionApp
これによって起動する JVM のガベージ コレクション モードは、目標休止時間を 250 ミリ秒に設定されていて、休止時間の短さを優先するように最適化されています。ガベージ コレクションによる 250 ミリ秒の休止時間によって中断されても、100 ミリ秒のトランザクションがタイムアウトするまでに 50 ミリ秒の余裕があります。
目標休止時間の設定の詳細については、「休止時間モードの目標休止時間を設定する」を参照してください。
アプリケーションのスループットが上がるように JVM をチューニングするには、まずスループットを評価する手段が必要です。アプリケーションのスループットを測定する場合、よくあるやり方としては、事前定義されたテスト ケースを実行し、時間を測定する方法があります。テスト ケースは、各種のユース ケースをシミュレートし、できる限り実際のシナリオに近い設定であることが理想的です。さらに、JVM がウォームアップするだけの時間が確保できるように、テストの実行には少なくとも数分間が必要です。
この節では、様々なアプリケーションのパフォーマンスを上げるためのオプションのパフォーマンス機能について説明します。アプリケーションのスループットを評価する手段を準備したら、次の機能を試してみます。
JRockit JVM R27.3 以降には、遅延ロック解除という機能があります。この機能は、ロックの競合が少ない場合、同期された Java コードの実行を高速化します。
コマンド ラインに以下のオプションを追加して、アプリケーションでこの機能を試してみます。
このオプションの詳細については、「-XXlazyUnlocking」のドキュメントを参照してください。
呼び出しのプロファイリングを使用すると、コードの最適化のための高度なプロファイリングの使用を有効にし、各種アプリケーションのパフォーマンスを上げることができます。このオプションは、JRockit JVM R27.3.0 以降でサポートされています。
コマンド ラインに以下のオプションを追加して、アプリケーションでこの機能を試してみます。
このオプションの詳細については、「-XXcallProfiling」のドキュメントを参照してください。
JRockit JVM では、java ヒープおよび jvm 内の他のメモリ領域のために、大規模ページを使用することができます。大規模ページを使用するには、まずオペレーティング システムを大規模ページを扱えるように設定する必要があります。次に、Java コマンド ラインに以下のオプションを追加します。
このオプションの使い方と、大規模ページ用にオペレーティング システムを設定する方法については、「-XlargePages」のドキュメントを参照してください。
一部のアプリケーションでは、詳細なチューニングを行うとより効果的です。この場合に重要なのは、アプリケーションのモニタとベンチマークを行って、チューニング結果を検証することです。JRockit JVM の高度なチューニングを行うと、チューニングが適切に行われた場合はパフォーマンスが上がり、予測した動作が行われます。チューニングが不適切な場合、パフォーマンスが不規則になるか、低いパフォーマンスしか得られないか、長期にわたるパフォーマンスの低下を招くおそれがあります。
オブジェクトの圧縮とは、ヒープ内のオブジェクトを移動させて寄せ集めることで断片化を軽減し、JVM がオブジェクトを割り当てしやすいようにするプロセスです。JRockit JVM では、ガベージ コレクション (世代別のガベージ コレクタの場合は古いコレクション) を行うたびにヒープの部分的な圧縮を行います。
圧縮を行うと、ガベージ コレクションの休止時間が長くなることもあります。圧縮がガベージ コレクションによる休止時間に与える影響を評価するには、-Xverbose:Gcpause 出力をモニタするか、java runtime analyzer で JRA 記録を作成し、ガベージ コレクションによる休止時間を調べます (詳細は「Oracle JRockit Mission Control ツールの使用」を参照)。古いコレクションによる休止時間と、「compaction」および「reference updates」という休止部分を探します。圧縮による休止時間は、圧縮率と圧縮設定の制限によって決まります。
圧縮率は、各ガベージ コレクション (古いコレクション) で圧縮するヒープの割合を決定します。圧縮率を設定するには、次のオプションを使用します。
圧縮によるガベージ コレクションの休止時間が長すぎる場合は、圧縮率をチューニングすることもできます。まず、圧縮率を 1 に下げてみて、問題が解決したかどうかを確認します。問題が解決した場合、圧縮時間が短く維持される範囲で、徐々に圧縮率を上げてみます。圧縮率に適切な値の範囲は 1 ～ 20 ですが、これより高く設定することもできます。圧縮率を 1 に設定しても問題が解決しない場合、圧縮設定の制限を変更してみてください。
圧縮率の設定が低すぎると断片化が進行し、「ダーク マター」という、小さすぎてオブジェクト割り当てに使用できない空き領域が増加します。ダーク マターの量は、JRA 記録で確認できます。
圧縮設定の制限は、圧縮領域内のオブジェクト参照の数に制限を設定します。参照の数がこの制限を超えると、圧縮は取り消されます。圧縮設定の制限を設定するには、次のオプションを使用します。
圧縮時のガベージ コレクションによる休止時間が長すぎる場合は、圧縮設定の制限をチューニングすることもできます。まず、圧縮設定の制限を 10.000 に下げます。問題が解決した場合、圧縮時間が短く維持される範囲で、徐々に圧縮設定の制限の値を増やします。圧縮設定の制限の標準値は 100.000 から数百万の範囲ですが、休止時間の制限値が小さい場合は、標準より小さな値を使用します。
圧縮設定の制限を非常に低く設定すると、すべての圧縮が停止することがあります。このとき、JRA 記録の冗長ログには、すべての圧縮が「aborted」と記録されます。圧縮を一切行わずにアプリケーションを実行し続けると、断片化が進行し、JVM がヒープ全体に対する完全な圧縮を行わざるをえなくなるおそれがあります。完全な圧縮は数秒間かかります。このため、どうしても必要な場合を除き、圧縮設定の制限を下げないようにお勧めします。
| 注意 : | -XXcompactSetLimit は、-XgcPrio:deterministic または -XgcPrio:pausetime が使用されている場合、何の効果もありません。これらのガベージ コレクション モードを使用する場合、圧縮を手動でチューニングしないでください。代わりに、-XpauseTarget オプションを使用して、ガベージ コレクションの休止時間をチューニングしてください。 |
圧縮のチューニングの詳細については、「メモリの圧縮のチューニング」を参照してください。
スレッド ローカル領域 (TLA) は、ヒープまたはナーサリに確保された空き領域のチャンクであり、スレッドに独占的に与えられます。スレッドは、別のスレッドと同期しなくても、自分専用の TLA に小規模オブジェクトを割り当てることができます。TLA が一杯になると、このスレッドは単純に新しい TLA を要求します。TLA に割り当てられたオブジェクトはすべての Java スレッドからアクセス可能であり、割り当て後はどのような意味でも「スレッド ローカル」とは見なされません。
推奨 TLA サイズを大きくすると、各スレッドが多数のオブジェクトを割り当てるマルチスレッド アプリケーションには効果的です。TLA サイズを大きくすると、割り当てオブジェクトの平均サイズが大きい場合に TLA に大規模オブジェクトを割り当てられるため、効果的です。ただし、TLA サイズが大きすぎると、断片化が一層進行し、ガベージ コレクションがより頻繁に行われます。アプリケーションによって割り当てられたオブジェクトのサイズを評価するには、JRA 記録を生成し、Java Runtime Analyzer でオブジェクト割り当て統計を確認します。JRA の詳細については、「Oracle JRockit Mission Control ツールの使用」を参照してください。
「Min」値には、最少 TLA サイズを指定し、「preferred」値には、推奨サイズを指定します。TLA は、可能な場合は常に「preferred」サイズに設定されますが、状況に応じて「min」サイズに縮小される場合もあります。通常、推奨 TLA サイズには、アプリケーションで最も多く使用されている最大オブジェクトのサイズの 2 倍を超えない範囲の値を設定します。最少サイズを調整すると、ガベージ コレクションのパフォーマンスに影響しますが、ほとんどの場合、調整の必要はありません。最少サイズの標準値は 2 KB です。
TLA サイズのチューニングの詳細については、「メモリ割り当てのパフォーマンスの最適化」を参照してください。
JRockit JVM のチューニングに関連する情報については、「メモリ管理システムのチューニング」および「ロックのチューニング」を参照してください。
この節では、さまざまなアプリケーションおよびアプリケーション タイプに応じた JRockit JVM のチューニングに関するベスト プラクティスについて説明します。
Oracle WebLogic Server はアプリケーション サーバであるため、高いアプリケーション スループットを必要とします。多くの場合、アプリケーション サーバは、専用のマシン上の管理された環境に設定されます。Oracle WebLogic Server 用の bea JRockit のチューニングを行う場合、以下のことを試してみてください。
Oracle Weblogic SIP Server は、通信業界用に特化されたアプリケーション サーバです。通常は、適度に低いレイテンシを必要とし、専用マシン上の管理された環境で実行されます。Oracle weblogic server 用の JRockit JVM のチューニングを行う場合、以下のことを試してみてください。
-Xms) を最大ヒープ サイズ (-Xmx) と同じ値に設定します。-XgcPrio:pausetime、または静的な世代別コンカレント ガベージ コレクタ -Xgc:gencon を使用します。
Oracle Weblogic Event Server は、イベント駆動型アーキテクチャ ベースのアプリケーションのためのアプリケーション サーバです。通常は、非常に低いレイテンシを必要とし、専用マシン上の管理された環境で実行されます。Oracle weblogic server 用の JRockit JVM のチューニングを行う場合、以下のことを試してみてください。
Oracle Workshop は、多数の eclipse プラグインで構成されます。Eclipse は、高速な応答時間を必要とし、通常は、他の多数のアプリケーションと共にワークステーション上で実行されます。Oracle Workshop と共に使用する eclipse 用の JRockit JVM のチューニングを行う場合、以下のことを試してみてください。
実行時間が短く、単純かつ特有の目的を持つ javac などの Java ユーティリティ アプリケーションは、高速な起動を必要とし、通常はあまり多くのメモリを必要としません。JRockit JVM をこの種のアプリケーション用にチューニングするには、次のことを試してみてください。
大規模なバッチを処理するデータ処理アプリケーション、たとえば XML 処理やデータ マイニングを行うアプリケーションは、アプリケーションのスループットの最大化を必要としますが、長いレイテンシの影響はあまり受けません。Oracle JRockit JVM をこの種のアプリケーション用にチューニングするには、次のことを試してみてください。
-Xms) を最大ヒープ サイズ (-Xmx) と同じ値に設定します。-XgcPrio:throughput を使用します。
|