|
以下の節では、エンジン層のサーバにおいて Java 仮想マシン (JVM) のガベージ コレクションのパフォーマンスをチューニングする方法について説明します。
一般に、プロダクション環境の Oracle Communications Converged Application Server では、サーバ負荷のピーク時も含めて常時、クライアントに対して非常に短い応答時間 (50 ミリ秒未満) で応答できる必要があります。短い応答時間を維持するための重要な要件の 1 つは、Oracle Communications Converged Application Server のエンジン層のインスタンスで使用する JVM のガベージ コレクション (GC) アルゴリズムを正しく選択し、かつ適切な状態にチューニングすることです。
一部のチューニング方式はガベージ コレクションの平均時間を最短にすることや完全なガベージ コレクションの実行頻度を最小に抑えることを目的として設計されていますが、これらの方式では、長短の GC 間隔を組み合わせて総合的に GC の影響を軽減する方針が採用されているので、結果的に 1 回または数回、非常に時間のかかる (数秒間に及ぶことが多い) ガベージ コレクションが発生することがあります。プロダクション環境の SIP Server では、応答時間の目標を維持するために、長い GC 間隔が一切発生しないようにする必要があります。
以下の節では、JRockit を使用する場合と Sun の JVM を使用する場合のそれぞれについて、応答時間が最短となる最適なパフォーマンスを一般的に実現できるチューニング方式を説明します。
Oracle Communications Converged Application Server エンジンとレプリカを起動するためにカスタムの起動スクリプトを使用する場合、次のセクションで説明されている、推奨される JVM オプションを含むようにスクリプトを編集します。
新しいドメインをコンフィグレーションする場合、コンフィグレーション ウィザードではデフォルトの起動スクリプトもインストールされます。これらのスクリプトはデフォルトで BEA_HOME/user_projects/domains/domain_name/bin のディレクトリにインストールされており、以下が含まれています。
エンジンとレプリカを起動するために Oracle のインストールしたスクリプトを使用する場合、コマンド シェルで USER_MEM_ARGS の環境変数をはじめに設定することで JVM メモリ引数をオーバーライドすることができます。
| 注意 : | USER_MEM_ARGS の環境変数を設定することで Oracle のインストールしたスクリプトで指定されたすべてのデフォルトの JVM メモリ引数をオーバーライドすることができます。常に使用する意向がある JVM メモリ引数の完全なリストに USER_MEM_ARGS を設定します。たとえば、デフォルトのヒープ領域 (-Xms、-Xmx) パラメータだけ変更する意向がある場合でも、Sun JVM を使用する場合、常に -XX:MaxPermSize=128m を USER_MEM_ARGS の値に追加します。 |
JRockit には、任意の時点の JVM ヒープを分析するために役立つ次のようなモニタリング ツールが用意されています。
JVM の設定は、制御された環境でこれらのツールを使用することによって、その設定の効果や影響を事前に確認した上で、実際のプロダクション環境に適用してください。JRockit および JRockit のプロファイリング ツールの詳細については、「BEA JRockit 1.4.2 SDK ドキュメント」を参照してください。
以下の節では、JROCKIT JVM で使用する提案された起動時の JVM オプションについて説明します。定的ガベージ コレクションで JRockit を使用すると(推奨)、Oracle JRockit Real Time の使用 (確定的ガベージ コレクション) で説明されたオプションを使用します。
非常に短い応答時間が確定的ガベージ コレクションを実装する JRockit Real Time の使用によって達成される。確定的ガベージ コレクションとのチューニングに関する基本的な情報については、Oracle WebLogic Real Time ドキュメントの「Real-Time アプリケーションの JVM チューニング」を参照してください。
レプリケートされたクラスタ コンフィグレーションのエンジン層サーバに以下の JVM 引数を使用することをお勧めします。
-Xms1024m -Xmx1024m -XgcPrio:deterministic -XpauseTarget=30ms -XXtlasize:min=8k -XXnosystemgc
| 注意 : | コンフィグレーション ウィザードを使用して JRockit JVM による新しいドメインを作成する場合、上記の設定はデフォルトで $WLSS_HOME/common/bin/wlssCommenv.sh ファイルにコンフィグレーションします。 |
| 注意 : | アロケーション インテンシブなアプリケーションに対して、-XpauseTarget 値を高める必要がある可能性があります。この値は、より小さいアプリケーションに対して軽負荷の下で減らすことができます。 |
| 注意 : | デプロイ済みアプリケーションで使用される実データの量に応じて、ヒープ サイズを調整します。開始点として、ヒープ サイズをアプリケーションが必要とする合計の 2 から 3 倍まで設定します。必要な合計の 3 倍に近い値は、通常、最良のパフォーマンスをもたらします。 |
レプリカ サーバのため、利用可能なメモリの容量を増大させます。
-Xms3072m -Xmx3072m -XgcPrio:deterministic -XpauseTarget=30ms -XXtlasize:min=8k -XXnosystemgc
これらの設定はヒープ サイズを固定して、確定的ガベージ コレクションとともにダイナミック ガベージ コレクタを有効にします。-XpauseTarget は、最大の休止時間を設定し、-XXtlasize=3k はスレッド ローカルの領域サイズを設定します。-XXnosystemgc で System.gc() アプリケーションの呼をガベージ コレクションの強制から防ぎます。
確定的ガベージ コレクションなしで Oracle JRockit を使用すると (プロダクション デプロイメントには勧められない)、世代の同時ガベージ コレクタを使用することで最適な応答時間パフォーマンスが取得されます。
エンジン層サーバの起動オプション例の一覧は以下のとおりです。
-Xms1024m -Xmx1024m -Xgc:gencon -XXnosystemgc -XXtlasize:min=3k -XXkeeparearatio=0 -Xns:48m
| 注意 : | デプロイ済みアプリケーションで使用される実データの量に応じて、ヒープ サイズを微調整します。 |
レプリカ サーバの起動オプション例の一覧は以下のとおりです。
-Xms3072m -Xmx3072m -Xgc:gencon -XXnosystemgc -XXtlasize:min=3k -XXkeeparearatio=0 -Xns:48m
Sun の JDK を使用する場合、ガベージ コレクションのパフォーマンス チューニングの目標は、完全なガベージ コレクションの 1 サイクルの実行に要する時間を短縮することです。完全なガベージ コレクションの発生頻度を最小限に抑えようとすると、多くの場合、結果的に、完了までに数秒を要する強制的なガベージ コレクション サイクルの発生を招くことになるので、JVM に対してそのようなチューニングを行うことは避けてください。
プロダクション サーバのライフタイムにおけるガベージ コレクション時間の短縮を実現する最も単純で信頼性の高い方法は、ヒープのサイズを固定してデフォルト コレクタと若い世代用の並行コレクタを使用することにより、新しい世代のサイズを最大でもヒープ全体の 1/3 までに制限することです。
ほとんどのエンジン層サーバには以下の JVM 設定例をお勧めします。
-server -Xmx1024m -XX:MaxPermSize=128m -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:+UseTLAB -XX:+CMSIncrementalMode -XX:+CMSIncrementalPacing -XX:CMSIncrementalDutyCycleMin=0 -XX:CMSIncrementalDutyCycle=10 -XX:MaxTenuringThreshold=0 -XX:SurvivorRatio=256 -XX:CMSInitiatingOccupancyFraction=60 -XX:+DisableExplicitGC
-server -Xmx3072m -XX:MaxPermSize=128m -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:+UseTLAB -XX:+CMSIncrementalMode -XX:+CMSIncrementalPacing -XX:CMSIncrementalDutyCycleMin=0 -XX:CMSIncrementalDutyCycle=10 -XX:MaxTenuringThreshold=0 -XX:SurvivorRatio=256 -XX:CMSInitiatingOccupancyFraction=60 -XX:+DisableExplicitGC
-XX:+UseTLAB - スレッド ローカルのオブジェクト割り当てブロックを使用します。これにより、共有ヒープ ロックに対する競合の発生が減少して、同時実行性が向上します。-XX:+UseParNewGC - 同時 mark-and-sweep コレクタとともに、若い世代用の並行バージョンのコピー コレクタを使用します。これにより、使用可能なすべての CPU が並行して使用されるようになり、休止時間を最小限に抑えられます。この若い世代用のコレクタは、デフォルト コレクタおよび同時マーク アンド スイープ (CMS) コレクタのどちらとも併用できます。-Xms, -Xmx - ヒープ サイズに境界を設け、ガベージ コレクションが予測どおりに実行される可能性を高めます。レプリカ サーバでヒープ サイズが制限されているので、完全な GC の実行時にも SIP の再送信が発生することがなくなります。-Xms ヒープの拡張を原因とする休止の発生を防ぐように起動時のヒープ サイズを設定します。-XX:MaxTenuringThreshold=0 - すべての NewGC サイクルで NewSize の全体を使用できるようにして、寿命の長いオブジェクト (tenured object) の評価を不要にすることにより、休止時間を短縮します。より技術的に言えば、この設定は、生存しているすべてのオブジェクトを (コピーするのではなく) 古い世代に昇格することを意味します。-XX:SurvivorRatio=128 - 上記のゼロのしきい値の指定によって、生存しているすべてのオブジェクトを寿命の長いオブジェクトと見なすように設定した場合は、このように SurvivorRatio を高く設定することによって、実際には存在しない Survivor オブジェクトのために大きな領域が確保されることを防止できます。
|