WebLogic Server パフォーマンス チューニング ガイド
|
 |
 |
|
Java 仮想マシン (JVM) は、マイクロプロセッサ上で Java クラス ファイルのバイト コードを実行する仮想の「実行エンジン」インスタンスです。JVM のチューニングは、WebLogic Server とアプリケーションのパフォーマンスに影響を与えます。
以下の節では、WebLogic Server 用の JVM チューニング オプションについて説明します。
表 3-1はWebLogic Server における JVM のチューニングに関する一般的な考慮事項を示しています。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
この節では Windows、UNIX、および Linux プラットフォーム用の Sun Microsystems J2SE 1.4 JVM について説明しますが、サーバサイド アプリケーション用に開発され、Intel アーキテクチャ向けに最適化された BEA WebLogic JRockit JVM を使用すると、Java アプリケーションの信頼性、スケーラビリティ、管理容易性、柔軟性を向上できます。Windows および Linux プラットフォームで JRockit を使用する利点については、WebLogic JRockit のドキュメントを参照してください。
JVM の一般的な情報については、「JVM 仕様の紹介」を参照してください。JVM チューニングの関連情報へのリンクについては、「関連情報 : パフォーマンス ツールと情報」を参照してください。
ドメインを作成するときに、そのコンフィグレーションのカスタマイズを選択すると、WebLogic Server がインストールした SDK のリストがコンフィグレーション ウィザードに表示されます。そのリストからドメインを実行する JVM を選択し、ウィザードはその選択に基づいて BEA 起動スクリプトをコンフィグレーションします。ドメインを作成した後、別の JVM を使用する必要がある場合は、スクリプトを次のように修正できます。詳細については、「サーバを実行する JVM の変更」を参照してください。
ガベージ コレクションは、Java ヒープ内の使用されていない Java オブジェクトを解放する JVM のプロセスです。Java ヒープは Java プログラムのオブジェクトが存在している場所であり、ライブ オブジェクト、デッド オブジェクト、およびフリー メモリのリポジトリです。実行中のプログラムでどのポインタからもアクセスされなくなると、オブジェクトは「ガベージ (廃棄物)」と見なされ、コレクションの対象となります。
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 のガベージ コレクション オプションの詳細については、以下のリンクを参照してください。
http://developers.sun.com/techtopics/mobility/midp/articles/garbagecollection2/index.htmlで、「Improving Java Application Performance and Scalability by Reducing Garbage Collection Times and Sizing Memory Using JDK 1.4.1」を参照してください。HotSpot VM の verbose ガベージ コレクション オプション (verbosegc) を使用すると、ガベージ コレクションに費やされる時間とリソースを正確に測定できます。最も効率的なヒープ サイズを判断するには、診断を目的として 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 コマンドは、標準エラーと標準出力の両方をログ ファイルにリダイレクトします。
$$ は、Java プロセスのプロセス ID (PID) にマップされます。出力にはガベージ コレクションの実行時間を示すタイムスタンプが含まれているので、ガベージ コレクションの実行頻度を推測できます。
「ヒープ サイズ値の指定」および表 3-2 を参照してください。
注意 : BEA WebLogic JRockit JVM の適切なヒープ サイズの設定については、WebLogic JRockit のドキュメントを参照してください。
注意 : BEA WebLogic JRockit JVM -Xgcreport オプションを使用してプログラムの終了時にガベージ コレクション レポートを出力する方法については、WebLogic JRockit のドキュメントを参照してください。
Java ヒープ サイズの値は、WebLogic Server インスタンスを起動するたびに指定する必要があります。ヒープ サイズ値は、java コマンドラインから指定するか、WebLogic Server 起動用に WebLogic 配布キットに付属しているサンプル起動スクリプトのデフォルト値を変更して指定します (「WebLogic 起動スクリプトを使用したヒープ サイズの設定」を参照)。
たとえば、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 を割り当てています。ヒープ サイズ オプションの詳細については、「Java ヒープ サイズのオプション」を参照してください。
WebLogic Server 配布キットには、サーバを起動するサンプル起動スクリプト、およびサーバを構築したり実行したりするための環境を設定するサンプル起動スクリプトが付属しています。
startWLS.cmd および setEnv.cmd (Windows)startWLS.sh および setEnv.sh (UNIX および Windows。Windows では、これらのスクリプトで MKS および Cygnus BASH UNIX シェル エミュレータがサポートされています)。 コンフィグレーション ウィザードを使用してドメインを作成した場合、WebLogic 起動スクリプトはそのドメインを指定した domain-name ディレクトリに格納されます。このディレクトリは、デフォルトでは BEA_HOME\user_projects\domain\domain-name となります。BEA_HOME は製品のインストール ディレクトリ、domain-name は選択したコンフィグレーション テンプレートで定義されているドメイン ディレクトリの名前です。コンフィグレーション ウィザードを使用したドメインの作成については、『コンフィグレーション ウィザードの使い方』を参照してください。
これらの起動スクリプトは、Java に渡されるデフォルト メモリ引数 (つまり、ヒープ サイズ) や JDK の位置などの環境変数を設定し、その後に WebLogic Server の引数を使用して JVM を起動します。WebLogic Server 起動スクリプトでは、デフォルト ヒープ サイズのパラメータが指定されます。したがって、実際の環境やアプリケーションに合わせてそれらのパラメータを変更する必要があります。起動スクリプトを修正して Java ヒープ サイズ オプションを設定する手順については、「WebLogic Server インスタンスの Java オプションの指定」を参照してください。
最高のパフォーマンスは、アプリケーションを個別にチューニングすることで実現されます。 ただし、WebLogic Server の起動時に表 3-2 の Java HotSpot VM ヒープ サイズ オプションをコンフィグレーションすると、ほとんどのアプリケーションでパフォーマンスを向上させることができます。
これらのオプションは、使用するアーキテクチャおよびオペレーティング システムによって異なります。プラットフォーム別の JVM チューニング オプションについては、ベンダのマニュアルを参照してください。
注意 : WebLogic JRockit JVM の適切なヒープ サイズの設定については、WebLogic JRockit のドキュメントを参照してください。
WebLogic Server では、低メモリ状態をサーバで観察して自動的にログに記録できます。WebLogic Server では、ある特定の時間間隔で設定された回数だけ利用可能な空きメモリをサンプリングして低メモリが検出されます。各間隔の最後に、空きメモリの平均が記録され、それが次の間隔で得られた平均と比較されます。 サンプル間隔の後に、ユーザがコンフィグレーションした量だけ平均が落ち込んだ場合、サーバは低メモリの警告メッセージをログ ファイルに記録し、サーバの状態を「warning」に設定します。
平均空きメモリが、サーバの起動直後に記録された初期空きメモリの 5% を下回ると、WebLogic Server はメッセージをログ ファイルに記録します。
低メモリ検出プロセスの各側面は、次のように Administration Console を使用してコンフィグレーションします。
サーバでガベージ コレクションを手動で選択するには、完全なガベージ コレクションが必要です。ガベージ コレクションを実行すると、JVM ではヒープ内のすべてのライブ オブジェクトが頻繁に調べられます。
Administration Console を使用して、指定したサーバ インスタンスでガベージ コレクションを要求するには、次の手順に従います。
標準の java コマンドライン オプションを使用すると、JVM のパフォーマンスを向上させることができます。これらのオプションの使い方は、使用するアプリケーションのコーディングによって異なります。コマンドライン オプションはプラットフォーム間で一貫性がありますが、プラットフォームによってはデフォルトが異なる場合もあります。
クライアント JVM とサーバ JVM の両方をテストすると、特定のアプリケーションに対してよりパフォーマンスの優れたオプションを調べることができます。Sun Microsystems の「Java HotSpot VM Options」には、Java HotSpot 仮想マシンのパフォーマンス特性に影響を与えるコマンドライン オプションと環境変数に関する情報が記述されています。
パフォーマンスに影響する可能性のあるその他の「非標準」VM オプションの概要については、「Windows、Solaris、および Linux の非標準の HotSpot VM オプション」を参照してください。
注意 : WebLogic JRockit JVM コマンドライン オプションを使用してパフォーマンスを向上させる場合は、WebLogic JRockit のドキュメントを参照してください。
標準の java オプションを使用して、Windows、Solaris、および Linux プラットフォームでのパフォーマンスを向上できます。これらのオプションは、現在の Java 実行時環境でサポートされており、HotSpot の将来のリリースでもサポートされる予定です。表 3-3 に示す標準オプションを java コマンドを使用して指定すると、WebLogic Server によって特定のバージョンの JVM が呼び出されます。
標準の HotSpot VM オプションのその他の例については以下を参照してください。
J2SE 1.4 準拠の Java 仮想マシンのクライアントおよびサーバの実装に関する詳細については、Sun Microsystems の「Java Virtual Machine」を参照してください。
非標準の Java オプションを使用しても、パフォーマンスを向上させることができます。これらのオプションの使い方は、使用するアプリケーションのコーディングによって異なります。コマンドライン オプションはプラットフォーム間で一貫性がありますが、プラットフォームによってはデフォルトが異なる場合もあります。非標準のコマンドライン オプションは、将来のリリースにおいて変更される可能性があります。
Windows、Solaris、および Linux 上の HotSpot VM でパフォーマンスを向上させる非標準オプションの例については以下を参照してください。
|
|
|