| Oracle® JRockit Real Time紹介 リリース4.0 B61449-01 |
|
 前 |
 次 |
この項には、Oracle JRockit Real Time 4.0に含まれるOracle JRockit JVMの確定的なガベージ・コレクタ向けにアプリケーションをチューニングするための以下のガイドラインが含まれています。
|
注意: JRockitで使用可能なその他の非標準の起動コマンドの調整についての詳細は、Oracle Technology NetworkのOracle JRockitコマンドライン・リファレンスを参照してください。 |
JRockit Real Timeを使用する環境を構成するには、以下のガイドラインを使用します。
サーバーまたはクライアントでCPUが最大限に使用されていないことを確認する
アプリケーションでCPUの大部分が使用されている場合、確定的なGCのパフォーマンスによって平均レイテンシが実際に退行する場合があります。これは、確定的なGCではGCが継続的に実行され、GCとアプリケーションでCPUサイクルの取合いが起こるためです。最良のレイテンシを得るためには、CPUを完全に使用しないことが最善です。ベスト・プラクティスでは、様々な負荷（確定的なGCを使用する場合と使用しない場合を含む）でベンチマークを実行し、最適な負荷を決定します。
アクティブなスレッドが多すぎると、コンテキストの切替えのためにレイテンシが増加する可能性がる
「スイート・スポット」の数は通常1つの仮想CPUにつき1つのスレッドですが（つまり、デュアル・コアおよびHyperTransportは異なるCPUとして数えます）、1つのCPUをバックグラウンドのGC処理用に空けておきます。ただし、（データベースなどに）外部呼出しを行う場合は、アイドル・サイクルを利用するために追加のスレッドをいくつか割り当てることも理にかなっています。
JRockitガベージ・コレクションのスレッドの調整の詳細は、3.5.9「プロセッサのガベージ・コレクション・スレッドの量の調整」を参照してください。
JRockit Real Timeのアプリケーションを設計する場合は、以下のガイドラインを使用します。
アプリケーションのコードと、レイテンシの測定方法について理解します。
リアル・タイムの目的が損なわれるため、トランザクションの一部でバック・オフィス・システムを遅くする同時呼出しを行うことは避けます。逆に、重要でない呼出しは、作業用スレッド・プールまたはJMSの使用を通じて、必ず非同期で処理されるようにします。
メモリーの割当てを最小化します。可能であれば、チャンクでの単一トランザクションのメモリーの割当てと解放を行います。また、オブジェクトの数とサイズを最小化します。
頻繁なメモリーの割当てや、多数の大規模配列の割当てを行うことを避け、メモリーの使用を制御します。
すべてのオブジェクトを可能な限りすばやく解放します。そうしないと、DetGCにより参照されたすべての有効なオブジェクトにマークが付けられた場合、ガベージ・コレクションで参照されなくなったオブジェクトが依然として有効であるとマークされます。
Javaコードの同期されたブロックによりトランザクションがブロックされる場合があるため、コード内に長い重要なセクションを作らないようにします。
確定的なGCではこれらのオブジェクトを反復する必要があるため、リンクした長い構造を作らないようにします。
トランザクションが高度にアクティブな複数のJVMにまたがっている場合は、それらの各JVMごとに確定的なGCを実行する必要があります。たとえば、JavaクライアントJVMでトランザクションが開始され、JMSサーバーとJ2EEサーバーの両方の操作がトランザクションに含まれている場合、レイテンシ条件の最大値を確実に満たすには、これら3つのすべてのJVMで確定的なGCが必要になります。
JRockit Real TimeのJ2EEアプリケーションをチューニングする場合は、以下のガイドラインを使用します。
サーバー側のEJB、MDB、およびサーブレットで、クライアントのリクエストに直ちに応答するために十分な数の同時実行インスタンスが構成されていることを確認します（すべてのインスタンスがアクティブな場合は、クライアントのリクエストがサーバー上で相互にキューに入れられていることを示す徴候です）。
スレッドがリソースを待機することのないように、十分な数のインスタンスがリソース・プールに含まれているようにします。たとえばJ2EEでは、EJB max-beans-in-free-poolプロパティを調整し、スレッド・プール・サイズを調整します。
Oracle WebLogic JMSアプリケーションでJRockit Real Timeを使用する場合は、以下のガイドラインを使用します。
同期コンシューマではなく、非同期コンシューマの使用を検討します。
JMSコンシューマについての詳細は、WebLogic JMSのプログラミングのアプリケーションの設計に関する項を参照してください。
すべてのJMS接続ファクトリの最大メッセージ数の設定を1にチューニングします。これにより、スループットが低下するかわりに、レイテンシが向上する可能性があります。同様に、以下の設定を使用して、MDBがカスタム接続ファクトリを参照するように構成します。
最大メッセージ数 = 1
XA接続ファクトリを有効化 = enabled
クライアント確認応答ポリシー = ACKNOWLEDGE_PREVIOUS
JMS接続ファクトリの構成の詳細は、管理コンソールのオンライン・ヘルプを参照してください。
キューからの非永続メッセージのコンシューマの場合は、WebLogic JMS WLSession NO_ACKNOWLEDGE拡張の使用を検討します。
非永続メッセージのパフォーマンスの改善には、WebLogic Server 9.2の「一方向送信モード」機能の使用を検討します。WebLogic ServerパフォーマンスおよびチューニングのWebLogic JMSのチューニングに関する項を参照してください。
Spring JMSテンプレートがリソース参照プールを利用していることを確認します（そうでない場合は、各メッセージごとにJMS接続、セッション、およびプロデューサが暗黙的に作成されて閉じられるため、レスポンス時間に悪影響を及ぼします）。
|
注意: リソース参照プールは、ターゲット送り先が各呼出しで変化する場合には適していません。そのような場合は、通常のJMSを使用するようにアプリケーションのコードを変更し、JMS接続、セッション、プロデューサ、およびコンシューマをキャッシュします。 |
以下のチューニングに関する推奨事項は、JRockit JVMの確定的なガベージ・コレクタを使用する際にさらなるパフォーマンスの向上と休止時間の削減を可能にします。確定的ガベージ・コレクタについての詳細は、Oracle Technology NetworkのOracle JRockitパフォーマンス・チューニング・ガイドを参照してください。
レスポンス時間が目的のレベルに到達する前に、ウォーム・アップ期間があります。このウォーム・アップ中に、JRockit JVMではクリティカル・コード・パスが最適化されます。ウォーム・アップ期間は、以下のように、アプリケーションとハードウェアに依存します。
高速なハードウェア上で実行され、負荷の大きい、（Javaコード量の点から）小規模なアプリケーションでは、1 - 3分のウォーム・アップ期間があります。
低速なハードウェア（特に、ほとんどのSPARKハードウェア）上で実行され、負荷の小さい、（Javaコード量の点から）大規模なアプリケーションでは、約30分のウォーム・アップ期間があります。
最小ヒープ・サイズ（-Xms）を小さく設定したり、最大ヒープ・サイズ（-Xmx）を大きく設定すると、ガベージ・コレクションの発生頻度に影響を及ぼし、アプリケーションで使用可能なおおよそのライブ・データの量が決定されます。まずはじめに、次のヒープ・サイズの使用を試してください。
java -Xms1024m -Xmx1024m -XgcPrio:deterministic -XpauseTarget=30
詳細は、Oracle JRockitコマンドライン・リファレンスの-XXコマンドライン・オプションの項を参照してください。
pauseTargetオプションを指定せずに-Xgcprio:deterministicを指定すると、デフォルト値に設定されます。このリリースでは、30ミリ秒です。
ハードウェアの速度が遅い、ヒープ・サイズが異なる、実データが多いなどの条件下では、確定的な動作が破綻することもあります。そのような場合は、-XpauseTargetオプションを使用して、デフォルトの目標休止時間（30ミリ秒）を増やす必要がある場合もあります。pauseTargetオプションの現在許容される最大値は5000ミリ秒です。
逆に、アプリケーションで可能な最小休止時間をテストする場合は、デフォルトの-XpauseTarget値を最小値まで減らすことができます。このリリースでは、最小値は10ミリ秒です。
詳細は、Oracle JRockitコマンドライン・リファレンスの-XXコマンドライン・オプションの項を参照してください。
ページ・サイズを増やすと（-XXlargePages）、TLB（Translation Look-aside Buffer）でのキャッシュ・ミスを制限することにより、パフォーマンスを向上し、休止時間を削減できます。Oracle JRockit JVMコマンドライン・リファレンスの-XXコマンドライン・オプションを参照してください。
負荷に関して過度に用心することはありません。確定的なガベージ・コレクションでは、確定による保証を損なわずにかなりの量の負荷を処理できます。負荷が少なすぎると、JVMのオプティマイザとGCのヒューリスティックで扱える情報がほとんどなくなるため、結果的にパフォーマンスが標準以下に低下します。ベスト・プラクティスでは、様々な負荷（確定的なGCを使用する場合と使用しない場合を含む）でベンチマークを実行し、最適な負荷を決定します。
JRockit JVMの詳細な出力は、通常はパフォーマンスに大きな影響を与えずに、JVMのメモリーおよびGCのアクティビティの分析に非常に役立ちます。表3-1に、JVMのメモリーおよびGCのアクティビティの分析時に推奨されるverboseオプションを示します。
Soft-、Weak-、およびPhantom-参照などの、使用されるファイナライザと参照オブジェクトの量を制限してみます。これらのタイプでは特殊な処理が必要とされ、大量に発生した場合は休止時間が30msよりも長くなる場合があります。
ガベージ・コレクション・トリガー（-XXgctrigger）を調整し、使用されるヒープ領域の容量を制限してみます。こうすることで、アプリケーションを変更せずに、より頻繁にガベージ・コレクションを発生させるようガベージ・コレクションに強制できます。トリガーの制限に達するたびにガベージ・コレクションが開始されるため、ガベージ・コレクション・トリガーは多少確定的です。Oracle Technology NetworkのOracle JRockitパフォーマンス・チューニング・ガイドを参照してください。
|
注意: トリガーの値を低く設定すると、ガベージ・コレクションが終了する前にヒープが満杯になる場合があり、新しいメモリーを取得する前にガベージ・コレクションが完了するのを待機する必要があるため、スレッドの休止時間が長くなる原因になります。通常は、ヒープの一部は空いているためメモリーは常に使用可能であり、ガベージ・コレクションでJavaアプリケーションが停止しても休止は短くて済みます。 |
現在では高度な処理を行う各種のハードウェアが入手可能であるため（HyperTransport、Strands、デュアル・コアなど）、JRockit JVMでは開始すべき適切なGCスレッドの数を決定できない場合があります。現在は、1つの物理CPUにつき1つのスレッドを開始することが推奨されます。つまり、コアでなく1つのチップにつき1つのスレッドです。ただし、ガベージ・コレクション・スレッドが多すぎる場合は、システムで実行中のスレッドが増えるほどCPUが飽和状態になり、Javaアプリケーションが影響を受けるため、アプリケーションのレイテンシに影響を及ぼします。逆に、スレッドが少なすぎる場合は、並行処理が減るためにGCのマーク・フェーズが増加します。たとえば、4コアのデュアル・コアIntel Woodcrestマシンで推奨されるGCスレッドの数は2つです。これは、マシンのプロセッサの数と同じです。
JRockit JVMがマシンで使用しているガベージ・コレクション・スレッドの数を表示するには、-verbose:memdbgを使用してJRockit JVMを開始し、起動時に出力される以下の行をチェックします。
[memdbg ] number of oc threads: <num> [memdbg ] number of yc threads: <num>
必要に応じて、-XXgcthreads:<# threads>パラメータを使用してGCスレッドの数を調整します。
詳細は、Oracle JRockitコマンドライン・リファレンスの-XXコマンドライン・オプションの項を参照してください。
パフォーマンスおよびチューニングの詳細は、Oracle Technology NetworkのOracle JRockitパフォーマンス・チューニング・ガイドを参照してください。
