Oracle JRockit Real Time の概要

     前  次    目次     
コンテンツの開始位置

リアルタイム アプリケーションでの確定的なガベージ コレクション向けのチューニング

この節には、Oracle JRockit Real Time に含まれる Oracle JRockit JVM の確定的なガベージ コレクタ向けにアプリケーションをチューニングするための以下のガイドラインが含まれています。

注意 : JRockit で使用可能な標準以外の他の起動コマンドの調整については、JRockit の「コンフィグレーションおよびチューニング ガイド」を参照してください。

 

基本的な環境のチューニング

Oracle JRockit Real Time を使用する環境をコンフィグレーションするには、以下のガイドラインを使用します。

 

基本的なアプリケーションのチューニング

Oracle JRockit Real Time 対応のアプリケーションを設計する場合は、以下のガイドラインを使用します。

 

J2EE アプリケーションのチューニング

J2EE アプリケーションを Oracle JRockit Real Time 向けにチューニングする場合は、以下のガイドラインを使用します。

 

JMS アプリケーションのチューニング

Oracle WebLogic JMS アプリケーションで JRockit Real Time を使用する場合は、以下のガイドラインを使用します。

 

リアルタイム アプリケーション向けの JVM のチューニング

JRockit JVM の確定的なガベージ コレクタを使用すると、チューニングに関する以下の推奨事項によって、さらなるパフォーマンスの向上と休止時間の削減が可能になります。確定的ガベージ コレクタの詳細については、Oracle JRockit の『診断ガイド』を参照してください。

ウォームアップ期間の許可

応答時間が目的のレベルに到達する前に、ウォームアップ期間がある場合があります。このウォームアップ時に、JRockit JVM ではクリティカル コード パスが最適化されます。ウォームアップ期間は、以下のように、アプリケーションとハードウェアに依存します。

最小/最大ヒープ サイズの調整

最小ヒープ サイズ (-Xms) を小さく設定したり、最大ヒープ サイズ (-Xmx) を大きく設定すると、ガベージ コレクションの発生頻度に影響を及ぼし、アプリケーションで使用可能なおおよその有効なデータの量が決定されます。まずはじめに、次のヒープ サイズの使用を試してください。 

   java -Xms1024m -Xmx1024m -XgcPrio:deterministic -XpauseTarget=30

詳細については、Oracle JRockit JVM 『コマンドライン リファレンス』の「-X コマンドライン オプション」を参照してください。

目標休止時間の増減

詳細については、Oracle JRockit の『コマンドライン リファレンス』の「-X コマンドライン オプション」を参照してください。

ページ サイズの設定

ページ サイズを増やすと (-XXlargePages)、TLB (Translation Look-aside Buffer) でのキャッシュ ミスを制限することにより、パフォーマンスを向上し、休止時間を削減できます。詳細については、Oracle JRockit JVM 『コマンドライン リファレンス』の「-XX コマンドライン オプション」を参照してください。

最適な負荷の決定

負荷に関して過度に用心することはありません。確定的なガベージ コレクションでは、確定による保証を損なわずにかなりの量の負荷を処理できます。負荷が少なすぎると、JVM のオプティマイザと GC のヒューリスティックで扱える情報がほとんどなくなるため、結果的にパフォーマンスが標準以下に低下します。ベスト プラクティスでは、さまざまな負荷 (確定的な GC を使用する場合と使用しない場合を含む) でベンチマークを実行し、最適な負荷を決定します。

JRockit の詳細な出力による GC 分析

JRockit JVM の詳細な出力は、通常はパフォーマンスに大きな影響を与えずに、JVM のメモリおよび GC のアクティビティの分析に非常に役立ちます。表 2-1 は、JVM のメモリおよび GC のアクティビティの分析時に推奨される詳細なオプションを定義しています。

表 2-1 JRockit JVM の詳細な出力オプション
オプション
処理内容
-Xverbose:opt,memory,memdbg,
gcpause,compact,license
GC およびメモリ分析。
-Xverboselog:verbose-jrockit.log
詳細な出力を指定されたファイルにリダイレクトします。
-Xverbosetimestamp
各詳細行の前に書式設定された日付を出力します。

ファイナライザおよび参照オブジェクトの量の制限

Soft-、Weak-、および Phantom- 参照などの、使用されるファイナライザと参照オブジェクトの量を制限してみます。これらのタイプでは特殊な処理が必要とされ、大量に発生した場合は休止時間が 30 ms よりも長くなる場合があります。

ガベージ コレクション トリガの調整

ガベージ コレクション トリガ (-XXgctrigger) を調整し、使用されるヒープ領域の容量を制限してみます。こうすることで、アプリケーションを変更せずに、より頻繁にガベージ コレクションを発生させるようガベージ コレクションに強制できます。トリガの制限に達するたびにガベージ コレクションが開始されるため、ガベージ コレクション トリガは多少確定的です。Oracle JRockit JVM の『診断ガイド』を参照してください。

注意 : トリガの値を低く設定すると、ガベージ コレクションが終了する前にヒープが満杯になる場合があり、新しいメモリを取得する前にガベージ コレクションが完了するのを待機する必要があるため、スレッドの休止時間が長くなる原因になります。通常は、ヒープの一部は空いているためメモリは常に使用可能であり、ガベージ コレクションで 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 JVM 『コマンドライン リファレンス』の「-XX コマンドライン オプション 」を参照してください。

 

その他のチューニング情報

この節では、その他のパフォーマンスおよびチューニング情報を示しています。

JRockit JVM

Oracle JRockit JVM の追加の診断情報については、Oracle JRockit JVM の『診断ガイド』を参照してください。


  ページの先頭       前  次