|
|
Java 仮想マシン (JVM) は、マイクロプロセッサ上で Java クラス ファイルのバイト コードを実行する仮想の「実行エンジン」インスタンスです。JVM のチューニングは、WebLogic Server とアプリケーションのパフォーマンスに影響を与えます。
以下の節では、WebLogic Server 用の JVM チューニング オプションについて説明します。
表 5-1 は、WebLogic Server における JVM のチューニングに関する一般的な考慮事項を示しています。
この節では Windows、UNIX、および Linux プラットフォーム用の Sun Microsystems J2SE 5.0 JVM について説明しますが、サーバサイド アプリケーション用に開発され、Intel アーキテクチャ向けに最適化された JRockit JVM を使用すると、Java アプリケーションの信頼性、スケーラビリティ、管理容易性、柔軟性を向上できます。Windows および Linux プラットフォームで JRockit を使用する利点については、『JRockit JDK の紹介』を参照してください。
JVM の一般的な情報については、「Introduction to the JVM specification」を参照してください。JVM チューニングの関連情報へのリンクについては、「関連情報 : パフォーマンス ツールと情報」を参照してください。
ドメインを作成するときに、そのコンフィグレーションのカスタマイズを選択すると、WebLogic Server がインストールした JDK のリストがコンフィグレーション ウィザードに表示されます。そのリストからドメインを実行する JVM を選択し、ウィザードはその選択に基づいて Oracle 起動スクリプトをコンフィグレーションします。ドメインを作成した後で、使用する JVM を変更する場合は、「サーバを実行する JVM の変更」を参照してください。
ガベージ コレクションは、Java ヒープ内の使用されていない Java オブジェクトを解放する VM のプロセスです。以下の節では、VM のガベージ コレクションのチューニングに関する情報を示します。
Java ヒープは、Java プログラムのオブジェクトが存在する場所です。ライブ オブジェクト、デッド オブジェクト、およびフリー メモリのリポジトリです。実行中のプログラムでどのポインタからもアクセスされなくなると、オブジェクトは「ガベージ (廃棄物)」と見なされ、コレクションの対象となります。ベスト プラクティスとしては、ガベージ コレクションに費やされる時間を、実行時間の 5% 以内にチューニングします。
JVM ヒープ サイズによって、ガベージ コレクションを行う頻度とその時間が決定されます。ガベージ コレクションの適切な実行頻度はアプリケーションによって異なるので、ガベージ コレクションの実際の時間と頻度を解析して調整する必要があります。大きいヒープ サイズを設定した場合、ガベージ コレクション全体は低速化しますが、実行頻度が低くなります。メモリのニーズに合わせてヒープ サイズを設定した場合、ガベージ コレクション全体は高速化しますが、実行頻度が高くなります。
ヒープ サイズのチューニングの目標は、WebLogic Server で所定の時間に処理できるクライアントの数を最大限に増やしつつ、JVM によるガベージ コレクションの実行時間を最小限に抑えることです。ベンチマーク時に最高のパフォーマンスを確保するには、大きいヒープ サイズ値を設定し、ベンチマークの実行中にガベージ コレクションが実行されないようにします。
ヒープ領域が不足している場合、次の Java エラーが表示されます。
java.lang.OutOfMemoryError <<no stack trace available>>
java.lang.OutOfMemoryError <<no stack trace available>>
Exception in thread "main"
ヒープ領域値を変更するには、「ヒープ サイズ値の指定」を参照してください。
ヒープ領域の不足を自動的に検出して、サーバの低メモリ状態を解決するよう WebLogic Server をコンフィグレーションするには、「低メモリ状態の自動的なロギング」および「ヒープ サイズ値の指定」を参照してください。
システム メモリの管理に使用するガベージ コレクションは、どの JVM を使用しているかに応じて複数の方式の中から選択できます。たとえば、特定のタイプのアプリケーションには、それに適したガベージ コレクションの方式があります。アプリケーションの負荷や、JVM によって使用されるガベージ コレクション アルゴリズムの違いを理解すると、ガベージ コレクションのコンフィグレーションを最適化できます。
それぞれの JVM のガベージ コレクション オプションの詳細については、以下のリンクを参照してください。
verbose ガベージ コレクション オプション (verbosegc) を使用すると、ガベージ コレクションに費やされる時間とリソースを正確に測定できます。最も効率的なヒープ サイズを判断するには、診断を目的として verbose ガベージ コレクションを有効にし、出力をログ ファイルにリダイレクトします。
-verbosegc オプションを使用して JVM の verbose ガベージ コレクション出力を有効にし、標準エラーおよび標準出力の両方をログ ファイルにリダイレクトします。
リダイレクトすることにより、スレッド ダンプ情報が WebLogic Server の情報メッセージとエラー メッセージに関連してログに記録されるので、診断する際にログ ファイルがさらに役立ちます。
たとえば、Windows および Solaris では次のように入力します。
% java -ms32m -mx200m -verbosegc -classpath $CLASSPATH
-Dweblogic.Name=%SERVER_NAME% -Dbea.home="C:\bea"
-Dweblogic.management.username=%WLS_USER%
-Dweblogic.management.password=%WLS_PW%
-Dweblogic.management.server=%ADMIN_URL%
-Dweblogic.ProductionModeEnabled=%STARTMODE%
-Djava.security.policy="%WL_HOME%\server\lib\weblogic.policy" weblogic.Server
>> logfile.txt 2>&1
logfile.txt 2>&1 コマンドは、標準エラーと標準出力の両方をログ ファイルにリダイレクトします。
HPUX では、次のオプションを使用して stderr stdout を 1 つのファイルにリダイレクトします。
-Xverbosegc:file=/tmp/gc$$.out
$$ は、Java プロセスのプロセス ID (PID) にマップされます。出力にはガベージ コレクションの実行時間を示すタイムスタンプが含まれているので、ガベージ コレクションの実行頻度を推測できます。
ページがディスクに「スワップ」されない範囲で、できるだけ大きいヒープ サイズを設定します。システムの空き RAM の容量は、ハードウェアのコンフィグレーションと、そのマシン上で実行されているプロセスのメモリ要件によって異なります。システムの空き RAM の容量の決定については、システム管理者に問い合わせてください。
通常、使用可能な RAM (オペレーティング システムまたはその他のプロセスによって占有されない RAM) の 80% を JVM に割り当てます。
もう一度確認しますが、ヒープ サイズのチューニングの目標は、WebLogic Server で所定の時間に処理できるクライアントの数を最大限に増やしつつ、JVM によるガベージ コレクションの実行時間を最小限に抑えることです。
| 注意 : | 包括的なガベージ コレクション レポートを出力するその他のオプションについては、JVM ベンダが提供している場合があります。たとえば、JRockit JVM -Xgcreport オプションを使用してプログラムの終了時にガベージ コレクション レポートを出力する方法については、WebLogic JRockit のドキュメントを参照してください。 |
システム パフォーマンスは、JVM で利用可能な Java ヒープのサイズによって大きく影響されます。この節では、ヒープ サイズ値の定義に使用するコマンドライン オプションについて説明します。Java ヒープ サイズ値は、WebLogic Server のインスタンスを起動するたびに指定する必要があります。ヒープ サイズ値は、java コマンドラインから指定するか、WebLogic Server 起動用に WebLogic 配布キットに付属しているサンプル起動スクリプトのデフォルト値を変更して指定します。
以下の節では、VM ヒープ サイズのチューニングに関する一般的なガイドラインを示します。
JRockit では、ヒープ サイズのヒューリスティックな自動調整機能が提供されますが、この機能は、すべてのアプリケーションに最適ではありません。多くの場合、最高のパフォーマンスを引き出すには、各アプリケーションに対して表 5-2 に示すヒープ サイズ オプションを調整し、VM をチューニングします。
たとえば、java コマンドラインから WebLogic Server インスタンスを起動する場合、JRockit VM ヒープ サイズの値は次のように指定できます。
$ java -Xns10m -Xms512m -Xmx512m
これらの値のデフォルト サイズはバイト単位で指定されます。KB (キロバイト) を示すには、値に「k」または「K」を付加します。同様に、MB (メガバイト) を示すには「m」または「M」を、GB (ギガバイト) を示すには「g」または「G」を付加します。上記の例では、保護領域のヒープ サイズに 10MB、JVM で実行している WebLogic Server インスタンスの最小および最大ヒープ サイズに 512MB のメモリを割り当てています。
WebLogic JRockit JVM の適切なヒープ サイズの設定については、『JRockit JVM チューニング ガイド』を参照してください。
Oracle は、JRockit VM のパフォーマンスを向上させるその他のコマンドライン オプションを提供しています。詳細については、『名前別の BEA JRockit JDK コマンドライン オプション』を参照してください。
最高のパフォーマンスは、アプリケーションを個別にチューニングすることで実現されます。ただし、WebLogic Server の起動時に表 5-3 の Java HotSpot VM ヒープ サイズ オプションをコンフィグレーションすると、ほとんどのアプリケーションでパフォーマンスを向上させることができます。
これらのオプションは、使用するアーキテクチャおよびオペレーティング システムによって異なります。プラットフォーム別の JVM チューニング オプションについては、ベンダのマニュアルを参照してください。
たとえば、java コマンドラインから WebLogic Server インスタンスを起動する場合、HotSpot VM ヒープ サイズの値は次のように指定できます。
$ java -XX:NewSize=128m -XX:MaxNewSize=128m -XX:SurvivorRatio=8 -Xms512m -Xmx512m
これらの値のデフォルト サイズはバイト単位で指定されます。KB (キロバイト) を示すには、値に「k」または「K」を付加します。同様に、MB (メガバイト) を示すには「m」または「M」を、GB (ギガバイト) を示すには「g」または「G」を付加します。上記の例では、New 世代および New 世代の最大ヒープ サイズに 128MB、JVM で実行している WebLogic Server インスタンスの最小および最大ヒープ サイズに 512MB を割り当てています。
Sun は、VM のパフォーマンスを向上させるその他の標準および非標準のコマンドライン オプションを提供しています。これらのオプションの使い方は、使用するアプリケーションのコーディングによって異なります。
クライアント JVM とサーバ JVM の両方をテストすると、特定のアプリケーションに対してよりパフォーマンスの優れたオプションを調べることができます。Sun Microsystems の「Java HotSpot VM Options」には、Java HotSpot 仮想マシンのパフォーマンス特性に影響を与えるコマンドライン オプションと環境変数に関する情報が記述されています。
HotSpot VM オプションのその他の例については以下を参照してください。
J2SE 5.0 準拠の Java 仮想マシンのクライアントおよびサーバの実装に関する詳細については、Sun Microsystems の「Java Virtual Machine」ドキュメントを参照してください。
WebLogic Server では、低メモリ状態をサーバで観察して自動的にログに記録できます。WebLogic Server では、ある特定の時間間隔で設定された回数だけ利用可能な空きメモリをサンプリングして低メモリが検出されます。各間隔の最後に、空きメモリの平均が記録され、それが次の間隔で得られた平均と比較されます。サンプル間隔の後に、ユーザがコンフィグレーションした量だけ平均が落ち込んだ場合、サーバは低メモリの警告メッセージをログ ファイルに記録し、サーバの状態を「warning」に設定します。Administration Console オンライン ヘルプの「低メモリ状態のログへの記録」を参照してください。
Administration Console から完全なガベージ コレクションを手動で要求する必要がある場合があります。ガベージ コレクションを実行すると、JVM はヒープ内のすべてのライブ オブジェクトを頻繁に調べるため、コストがかかることに留意してください。Administration Console オンライン ヘルプの「ガベージ コレクションの手動による要求」を参照してください。
アプリケーションのチューニング中にスレッド スタックの表示が必要になる場合があります。Administration Console オンライン ヘルプの「スレッド スタックの表示」を参照してください。
マルチプロセッサ システム上でロックの競合が激しい高負荷のアプリケーションを実行している場合、スピンを使用してパフォーマンスの向上を試みることができます。このオプションを使用すると、スリープ状態に入る前に、短時間ロックをスピンすることができます。
Sun は、Windows IA32 プラットフォーム上の JDK 5.0 において、デフォルトのロック スピン動作を変更しました。JDK 5.0 リリースでは、ロック スピンがデフォルトで無効になっています。このリリースでは、WebLogic Server の起動に使用する環境スクリプト内でスピンを明示的に有効にしています。スピンを有効にするには、以下の VM オプションを使用します。
-XX:+UseSpinning
JRockit VM では、さまざまなロックに対するスピンが自動的に調整されるため、このパラメータを設定する必要はありません。
| 注意 : | JRockit 8.1 SDK リリースでは、スピンは -XXenablefatspin オプションを設定して調整していました。 |
|