| Oracle® JRockitパフォーマンス・チューニング・ガイド リリースR28 B61439-02 |
|
 前 |
 次 |
この章では、JRockit JVMのチューニングの最初のステップと、各種のOracleアプリケーションに対するJVMのチューニングのベスト・プラクティスについて説明します。
各Javaアプリケーションには、固有の動作と要件があります。Oracle JRockit JVMは要件の多くに適応できますが、最適なパフォーマンスを得るには、いくつかの基本のパラメータをチューニングする必要があります。この章では、JVMをチューニングするための次のステップについて説明します。
JRockit JVMのチューニングに関する詳細は、第4章「メモリー管理システムのチューニング」および第5章「ロックのチューニング」を参照してください。
チューニングの基本手順は次のとおりです。
ヒープは、Javaオブジェクトが格納されている場所です。ヒープが大きいと、ガベージ・コレクションの頻度は少なくなりますが、ガベージ・コレクションにかかる時間は多少長くなります。通常、ヒープ・サイズには、ヒープ内のライブ・オブジェクトのサイズの2倍以上の大きさが必要です。つまり、ガベージ・コレクションごとに、ヒープの半分が解放される必要があります。サーバー・アプリケーションの場合、ページングが発生しないかぎり、システムが許容する利用可能なメモリーの最大値をヒープとして設定する必要があります。
ヒープ・サイズを設定するには、次のコマンドライン・オプションを使用します。
-Xms:size: ヒープの初期サイズと最小サイズを設定する場合
-Xmx:size: ヒープの最大サイズを設定する場合
例:
java -Xms:800m -Xmx:1000m MyServerApp
このコマンドにより、初期値が800MBで、1000MBまで拡張可能なヒープが設定されたJVMが起動します。
ヒープ・サイズの設定の詳細は、4.1.1項「ヒープ・サイズを設定する」を参照してください。
ガベージ・コレクションでは、使用されなくなったオブジェクトの領域が再構築されるため、新しいオブジェクトをこの領域に割当てできるようになります。ガベージ・コレクションの実行中はシステム・リソースが使用されます。ガベージ・コレクションをチューニングすることで、リソースをいつどのように使用するかを決定できます。JRockit JVMには、3つのガベージ・コレクションのモードと、多数の静的なガベージ・コレクション方式が用意されています。これらを使用して、アプリケーションの要件に合うように、ガベージ・コレクションをチューニングすることができます。
次のいずれかのコマンドライン・オプションを使用して、ガベージ・コレクションのモードを選択します。
-Xgc:throughputは、アプリケーションのスループットに対してガベージ・コレクションを最適化します。
-Xgc:pausetimeは、ガベージ・コレクションの休止時間を短くするようにガベージ・コレクションを最適化します。
-Xgc:deterministicは、ガベージ・コレクションの休止時間が非常に短くかつ確定的になるようにガベージ・コレクションを最適化します。
-Xgc:deterministicオプションは、Oracle JRockit Real Timeの一部としてのみ使用できます(Oracle JRockit Real Timeの詳細は『Oracle JRockit Real Time紹介』を参照)。
短いレイテンシを必要とするトランザクションベースのアプリケーションは、次のコマンドで起動できます。
java -Xgc:pauseTime MyTransactionApp
このコマンドによって起動するJVMのガベージ・コレクション・モードは、ガベージ・コレクションの休止時間を短くすることを優先して最適化されています。
ガベージ・コレクション・モードまたは静的なガベージ・コレクション方式の選択の詳細は、4.2項「ガベージ・コレクタの選択とチューニング」を参照してください。
JRockit JVMのガベージ・コレクション・モードと方式には、ナーサリを使用するものもあります。ナーサリは、新しいオブジェクトが割り当てられるヒープの領域です。ナーサリが一杯になると、若いコレクションで個別にガベージ・コレクションが行われます。若いコレクションの頻度と期間はナーサリ・サイズによって決まります。ナーサリを大きくすると、若いコレクションの頻度は減少しますが、個々のコレクションの期間は多少長くなります。
ナーサリ・サイズは、-Xgc:throughputまたは-Xgc:genparオプションを使用すると、アプリケーション・スループットを優先した最適化が行われるように自動的に調整されます。通常は、若いコレクションによる休止時間を適度に短く維持できる範囲で、ナーサリ・サイズを最大限大きく設定します。適度なナーサリ・サイズは、数メガバイトからヒープ・サイズの半分程度の範囲であり、アプリケーションに応じて任意の値を設定できます。
ナーサリ・サイズを設定するには、-Xns:sizeコマンドライン・オプションを使用します。
例:
java -Xms:800m -Xmx:1000m -Xgc:pausetime -Xns:100m MyTransactionApp
このコマンドにより、初期値が800MBで、1000MBまで拡張可能なヒープが設定されたJVMが起動します。ガベージ・コレクションは休止時間を優先して最適化するように設定されていて、ナーサリ・サイズは100MBに設定されています。
ナーサリ・サイズのチューニング方法の詳細は、4.1.2項「ナーサリおよび保持領域のサイズを設定する」を参照してください。
-Xgc:pausetimeおよび-Xgc:deterministicのコマンドライン・オプションは、目標休止時間を使用して休止時間を最適化する一方で、アプリケーションのスループットをできるだけ高く維持します。目標休止時間を長く設定すると、アプリケーションのスループットも上がります。このため、アプリケーションで許容される範囲で、できるだけ長い休止時間を設定してください。
目標休止時間を設定するには、-XpauseTarget:timeコマンドライン・オプションを使用します。
たとえば、通常のトランザクションに100ミリ秒かかり、400ミリ秒後にタイムアウトするトランザクションを持つトランザクションベースのアプリケーションは、次の設定で起動します。
java -Xgc:pausetime -XpauseTarget:250ms MyTransactionApp
起動するJVMのガベージ・コレクション・モードは、目標休止時間が250ミリ秒に設定されていて、休止時間の短さを優先するように最適化されています。ガベージ・コレクションによる250ミリ秒の休止時間によって中断されても、100ミリ秒のトランザクションがタイムアウトするまでに50ミリ秒の余裕があります。
目標休止時間のチューニングの詳細は、4.2.1.2.1項「休止時間モードの目標休止時間を設定する」を参照してください。
アプリケーションのスループットが上がるようにJVMをチューニングするには、まずスループットを評価する必要があります。アプリケーションのスループットを測定する場合、よくあるやり方としては、事前定義されたテスト・ケースを実行し、時間を測定する方法があります。テスト・ケースは、各種のユース・ケースをシミュレートし、できるかぎり実際のシナリオに近い設定であることが理想的です。さらに、JVMがウォーム・アップするだけの時間が確保できるように、テストの実行には少なくとも数分間が必要です。
次の項では、様々なアプリケーションのパフォーマンスを上げるためのオプションのパフォーマンス機能について説明します。
呼出しのプロファイリングを使用すると、コードの最適化のための高度なプロファイリングの使用を有効にし、各種アプリケーションのパフォーマンスを上げることができます。
アプリケーションでこの機能を使用するには、Javaコマンドラインに次のオプションを追加します。
-XX:+UseCallProfiling
-XX:(+|-)UseCallProfilingオプションの詳細は、『Oracle JRockitコマンドライン・リファレンス』を参照してください。
大規模ページは基本的に、プロセスのために確保されている連続的な物理メモリー・アドレスのブロックを表します。
利点
大規模ページは、大量のメモリーを必要とし、メモリーに頻繁にアクセスするアプリケーションのパフォーマンスの向上に役立ちます。
プロセスがデータをメモリーから検索する際、プロセッサはトランスレーション・ルックアサイド・バッファ(TLB)、つまりプロセッサ・メモリーに格納されている最近使用された仮想アドレスから物理アドレスへの領域変換のキャッシュを使用して、必要なデータが保持されている物理アドレス(RAMまたはハード・ディスク)を探し出します。大規模ページが有効になると、TLB内の単一のエントリが大規模で連続的な1つのアドレス領域を表すことが可能になり、場合によってはTLBの参照頻度の減少とパフォーマンスの向上ももたらされます。また、物理メモリー内の大規模ページがメモリー集約的なプロセスのために確保されているとき、CPUは小規模のページを追跡する必要があります。たとえば、2GBのヒープで実行中のプロセスは1024の大規模(2MB)ページのみで、524288の小規模(4KB)ページと対照的です。したがって、必要なデータに対する仮想アドレスから物理アドレスへの変換はTLBに存在する可能性が高くなります。TLBを使用しないとプロセッサは、メモリーに格納されている階層的なページ表を読み取るための、より速度の遅い方式に頻繁に頼らざるを得なくなります。
欠点
物理メモリーの大部分が1つのプロセスに確保されていると、システムで実行中の他のアプリケーションで過剰なページング(ハード・ディスクとRAM間でデータがスワップされること)が発生し、システムの全体的なパフォーマンスに影響する可能性があります。
大規模ページを使用するための前提条件
使用するオペレーティング・システムで大規模ページのサポートが利用可能であり、有効になっている必要があります。大規模ページの使用はSolarisではデフォルトで有効ですが、WindowsおよびLinuxの各システムでは明示的に有効にする必要があります。
各種のオペレーティング・システムで大規模ページを有効にする方法の詳細は、http://java.sun.com/javase/technologies/hotspot/largememory.jspと、使用するオペレーティング・システムのドキュメント(Windowsの場合: http://technet.microsoft.com/en-us/library/ms190730.aspx、Linuxの場合: kernelドキュメント内のvm/hugetlbpage.txtファイルを参照)を参照してください。
|
注意: 大規模ページのサポートが利用可能で有効であるオペレーティング・システムにおいても、場合によっては、ページが連続的ではないためJVMが大規模ページを確保できないときがあります。JVMで大規模ページを必ず使用できるようにするには、(たとえば起動スクリプトを使用して)システムが起動したらできるだけ早くオペレーティング・システムで大規模ページを有効にする必要があります。有効にしていないと、メモリーの使用が進むにつれて断片化が発生し、使用できる連続的な大規模ページの数の減少につながる可能性があります。システムを再起動すると問題が解決する場合があります。 |
JRockit JVMで大規模ページを有効にする手順
大規模ページがサポートされているオペレーティング・システムでJRockit JVMを実行中の際、-XX:+UseLargePagesFor[Heap|Code]オプションを使用することで大規模ページを有効にできます。詳細は、『Oracle JRockitコマンドライン・リファレンス』を参照してください。
一部のアプリケーションでは、詳細なチューニングを行うとより効果的です。アプリケーションの監視とベンチマーキングによって、チューニング結果を検証します。JRockit JVMの高度なチューニングを行うと、チューニングが適切に行われた場合はパフォーマンスが上がり、予測した動作が行われます。チューニングが不適切な場合、パフォーマンスが不規則になるか、低いパフォーマンスしか得られないか、長期にわたるパフォーマンスの低下を招くおそれがあります。
この節では、以下のトピックについて説明します。
圧縮はヒープ内のオブジェクトを移動して寄せ集めることで断片化を軽減し、JVMによるオブジェクトの割当てを容易にします。JRockit JVMでは、ガベージ・コレクション(世代別のガベージ・コレクタの場合は古いコレクション)を行うたびにヒープの部分的な圧縮を行います。
圧縮を行うと、ガベージ・コレクションの休止時間が長くなることもあります。圧縮がガベージ・コレクションの休止時間に与える影響を評価するには、-Xverbose:compactionまたは-Xverbose:gcpauseの出力を監視するか、JRockitフライト・レコーダで記録を作成してから、その記録でガベージ・コレクションの休止時間を調べます。古いコレクションによる休止時間と、「compaction」および「reference updates」という休止部分を探します。圧縮による休止時間は、圧縮率と最大参照数によって決まります。JRockitフライト・レコーダの詳細は、『Oracle JRockitフライト・レコーダ・ラン・タイム・ガイド』を参照してください。
圧縮率は、各ガベージ・コレクション(古いコレクション)で圧縮するヒープの割合を決定します。
圧縮率を設定するには、次のオプションを使用します。
-XXcompaction:percentage=percentage
圧縮によるガベージ・コレクションの休止時間が長すぎる場合は、圧縮率をチューニングできます。まず、圧縮率を1に下げてみます。
ガベージ・コレクションの時間が想定内のレベルまで戻る場合は、圧縮時間が短く維持される範囲で、徐々に圧縮率を上げてみます。適切な圧縮率の値の範囲は通常、1から20です。
圧縮率を1に設定した後もガベージ・コレクションの時間が長い場合は、3.3.1.2項の説明に従って最大参照数を変更します。
圧縮率の設定が低すぎると断片化が進行し、ダーク・マター(小さすぎてオブジェクト割当てに使用できない空き領域)が増加します。ダーク・マターの量は、JRockitフライト・レコーダの記録で確認できます。詳細は、『Oracle JRockitフライト・レコーダ・ラン・タイム・ガイド』を参照してください。
最大参照数を設定することで、圧縮領域内のオブジェクトに対して可能な参照数を規定する制限を定義できます。参照の数がこの制限を超えると、圧縮は取り消されます。
最大参照数を定義するには、次のオプションを使用します。
-XXcompaction:maxReferences=value
圧縮時のガベージ・コレクションによる時間が長すぎる場合は、最大参照数をチューニングします。まず、最大参照数の設定を10000に下げます。問題が解決した場合、圧縮時間が短く維持される範囲で、徐々に最大参照数の値を増やします。最大参照数の標準値は100000から数百万の範囲です。休止時間の制限値が小さい場合は、標準より小さな値を使用します。
最大参照数の設定が低すぎると、すべての圧縮が停止することがあります。このとき、冗長ログまたはJRockitフライト・レコーダの記録で圧縮が「skipped」として表されます。圧縮を一切行わずにアプリケーションを実行し続けると、断片化が進行し、JVMがヒープ全体の完全な圧縮を行わざるを得なくなるおそれがあります。この操作は数秒間かかります。どうしても必要な場合以外は、最大参照数を下げないようにお薦めします。
|
注意:
|
詳細は、4.3項「圧縮のチューニング」を参照してください。
スレッド・ローカル領域(TLA)のサイズを大きくすると、各スレッドが多数のオブジェクトを割り当てるマルチスレッド・アプリケーションに効果的です。TLAサイズを大きくすると、割当てオブジェクトの平均サイズが大きい場合にもTLAに大規模オブジェクトを割り当てられるため、効果的です。ただし、TLAサイズが大きすぎると、断片化が一層進行し、ガベージ・コレクションがより頻繁に行われます。アプリケーションによって割り当てられたオブジェクトのサイズを評価するには、JRockitフライト・レコーダ記録を生成し、JRockitフライト・レコーダでオブジェクト割当て統計を確認します。JRockitフライト・レコーダの詳細は、『Oracle JRockitフライト・レコーダ・ラン・タイム・ガイド』を参照してください。
TLAサイズを設定するには、次のオプションを使用します。
-XXtlaSize:min=size,preferred=size
min値には、最少TLAサイズを指定し、preferred値には、推奨サイズを指定します。TLAは、可能な場合は常にpreferredサイズに設定されますが、状況に応じてminサイズに縮小される場合もあります。通常、推奨TLAサイズには、アプリケーションで最も多く使用されている最大オブジェクトのサイズの2倍を超えない範囲の値を設定します。最少サイズを調整すると、ガベージ・コレクションのパフォーマンスに影響しますが、ほとんどの場合、調整の必要はありません。最少サイズの標準値は2KBです。
TLAサイズのチューニングの詳細は、4.4項「メモリー割当てのパフォーマンスの最適化」を参照してください。
この項では、次の各種アプリケーションに対するJRockit JVMのチューニングのベスト・プラクティスについて説明します。
Oracle WebLogic Serverはアプリケーション・サーバーであるため、高いアプリケーション・スループットを必要とします。多くの場合、アプリケーション・サーバーは、専用のマシン上の管理された環境に設定されます。Oracle WebLogic Server用のJRockit JVMのチューニングを行う場合、次の作業を実行してください。
システムで許容される範囲で、数ギガバイト程度の大きなヒープを使用します。
初期ヒープ・サイズまたは最少ヒープ・サイズ(-Xms)を最大ヒープ・サイズ(-Xmx)と同じ値に設定します。
デフォルトのガベージ・コレクション・モードの-Xgc:throughputを使用します。
Oracle Weblogic SIP Serverは、通信業界用に特化されたアプリケーション・サーバーです。通常は、適度に低いレイテンシを必要とし、専用マシン上の管理された環境で実行されます。Oracle WebLogic SIP Server用のJRockit JVMのチューニングを行う場合、次の作業を実行してください。
システムで許容される範囲で、2GB以上の大きなヒープを使用します。
初期ヒープ・サイズまたは最少ヒープ・サイズ(-Xms)を最大ヒープ・サイズ(-Xmx)と同じ値に設定します。
休止時間を優先して最適化されるガベージ・コレクション・モード(-Xgc:pausetime)、または静的な世代別コンカレント・ガベージ・コレクタ(-Xgc:gencon)を使用します。
50MB - 100MBの範囲で、適度に小さいナーサリを使用します。
圧縮率または最大参照数を低くして、圧縮による休止時間を均等にします。詳細は、3.3.1項「圧縮をチューニングする」を参照してください。
Oracle Complex Event Processingは、イベント駆動型アーキテクチャ・ベースのアプリケーションに使用されます。通常は、非常に低いレイテンシを必要とし、専用マシン上の管理された環境で実行されます。Oracle Complex Event Processing用のJRockit JVMのチューニングを行う場合、次の作業を実行してください。
ヒープ・サイズを1 GBに設定し、確定的ガベージ・コレクションのモードを最大限に活用します。
初期ヒープ・サイズまたは最少ヒープ・サイズ(-Xms)を最大ヒープ・サイズ(-Xmx)と同じ値に設定します。
低いかつ確定的なレイテンシを優先して最適化されたガベージ・コレクションのモード(-Xgc:deterministic)を使用します。確定的ガベージ・コレクションのモードはOracle JRockit Real Timeの一部としてのみ使用できます。
Eclipse IDEは、高速なレスポンス時間を必要とし、通常は他の多数のアプリケーションとともにワークステーション上で実行されます。Oracle JRockit Mission ControlをEclipse IDEプラグインとして使用することもできます。Oracle JRockit Mission ControlとEclipseツールキットの統合の詳細は、Oracle JRockit Mission Control Client Mission Controlの紹介を参照してください。
Eclipse IDE用のJRockit JVMのチューニングを行う場合、次の作業を実行してください。
システムのRAM容量から、オペレーティング・システムおよび同時に実行される各種アプリケーションのための容量を除いた残りの容量より少ない値を、最大ヒープ・サイズとして使用します。
必要なときにJVMでヒープのサイズを調整できるように、最大ヒープ・サイズ(-Xmx)よりも小さい初期ヒープ・サイズまたは最少ヒープ・サイズ(-Xms)を設定します。
短い休止時間を優先して最適化されるガベージ・コレクション・モード(-Xgc:pausetime)、またはデフォルトのガベージ・コレクション・モード(-Xgc:throughput)を使用します。
実行時間が短く、単純かつ特有の目的を持つJavaユーティリティ・アプリケーション(javacなど)は、高速な起動を必要とし、通常はあまり多くのメモリーを必要としません。この種のアプリケーション用のJRockit JVMのチューニングを行う場合、次の作業を実行してください。
小さなヒープを使用します。16MB以上で、上限はアプリケーションの用途に応じて指定します。
初期ヒープ・サイズまたは最少ヒープ・サイズ(-Xms)を最大ヒープ・サイズ(-Xmx)と同じ値に設定します。
デフォルトのガベージ・コレクション・モードの-Xgc:throughputを使用します。
大規模なデータのバッチを処理するアプリケーション(XML処理やデータ・マイニングを行うアプリケーションなど)は、アプリケーションのスループットの最大化を必要としますが、長いレイテンシの影響はあまり受けません。このようなアプリケーション用のOracle JRockit JVMのチューニングを行う場合、次の作業を実行してください。
オペレーティング・システムおよび同時に実行中の可能性のあるアプリケーションのための物理メモリーを除いて、できるかぎり大きなヒープ・サイズを設定します。
初期ヒープ・サイズまたは最少ヒープ・サイズ(-Xms)を最大ヒープ・サイズ(-Xmx)と同じ値に設定します。
デフォルトのガベージ・コレクション・モードの-Xgc:throughputを使用します。
TLAのサイズを増やします。詳細は、3.3.2項「スレッド・ローカル領域のサイズをチューニングする」を参照してください。
