| ドキュメントのダウンロード | サイト マップ | Glossary | |
|
|||
| BEA ホーム | 製品 | dev2dev | support | askBEA |
|
|
|
|||||||
 |
| e-docs > WebLogic Server > WebLogic Server パフォーマンス チューニング ガイド > Java 仮想マシン (JVM) のチューニング |
|
WebLogic Server パフォーマンス チューニング ガイド
|
Java 仮想マシン (JVM) は、マイクロプロセッサ上で Java クラス ファイルのバイト コードを実行する仮想の「実行エンジン」インスタンスです。JVM のチューニングは、WebLogic Server とアプリケーションのパフォーマンスに影響を与えます。
以下の節では、WebLogic Server 用の JVM チューニング オプションについて説明します。
JVM チューニングの関連情報へのリンクについては、関連情報: パフォーマンス ツールと情報.を参照してください。
表 2-1 は、JVM のチューニングに関する一般的な考慮事項を示しています。
|
WebLogic Server の動作が保証されているプロダクション JVM だけを使用すること。WebLogic Server 7.0 は、Java 1.3 準拠の JVM のみサポートする。 「動作確認状況」ページは頻繁に更新されて、さまざまなプラットフォームの最新の動作確認情報が示される。 |
|
|
WebLogic Server のヒープ サイズ チューニングの詳細については、JVM のヒープ サイズとガベージ コレクションを参照。 java.sun.com でのガベージ コレクションの概要については、「Tuning Garbage Collection with the 1.3.1 Java Virtual Machine」(を参照。 |
|
|
世代別ガベージ コレクションを参照。 |
|
|
WebLogic Server では、クライアントとサーバ用に異なる JVM バージョンを使用したデプロイメントがサポートされている。詳細については、クライアント/サーバ JVM の混在のサポート ページを参照。 |
|
|
UNIX には、グリーン スレッドとネイティブ スレッドという 2 つのスレッディング モデルがある。WebLogic Server で最高のパフォーマンスとスケーラビリティを得るには、ネイティブ スレッドを使用する JVM を選択する。 Solaris を使用する場合は、Sun Microsystems の Web サイトにある「Threading Models and Solaris Versions Supported」(を参照。 |
|
|
WebLogic Server を実行するときは、JIT コンパイラを使用する。Sun Microsystems や Symantec などから提供されるほとんどの JVM では、JIT コンパイラが使用される。 注意: Sun Microsystems の JVM 1.3.x、JIT オプションは有効ではなくなった。Java 仮想マシン (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 をコンフィグレーションするには、自動的な低メモリ状態のロギングを参照してください。
Java HotSpot JVM 1.3 では、割り当て速度と全体的なガベージ コレクションの効率を大幅に向上させる世代別コレクタが使用されます。ネイティブ ガベージ コレクションではヒープ内のすべてのアクセス可能オブジェクトが調べられますが、世代別ガベージ コレクションでは余分な作業を省くため、オブジェクトの有効期間が考慮されます。Hotspot JVM は、ほとんどのオブジェクトは有効期間が短く、コレクションを考慮する必要がないという、効率的なガベージ コレクションが行われる状態を前提として動作します。
世代別ガベージ コレクションを使用した場合、Java ヒープは Young、Old という 2 つの世代領域に分割されます。Young 世代領域は、さらに Eden と 2 つのサバイバル領域に細分化されます。Eden は、新しいオブジェクトが割り当てられる領域です。ガベージ コレクションが実行されると、Eden 内のライブ オブジェクトは隣のサバイバル領域にコピーされます。オブジェクトはヒープ サイズの最大しきい値を超過するまで、このようにサバイバル領域間でコピーされ、その後、Young 領域から Old 領域に移動されます。Young 世代領域および Old 世代領域のサイズと比率の指定については、ヒープ サイズ値の指定を参照してください。
多くのオブジェクトは、割り当てられた直後にガベージになります。このようなオブジェクトは、「初期廃棄」オブジェクトと呼ばれます。オブジェクトの有効期間が長くなるほど、ガベージ コレクションの実行回数が増え、ガベージ コレクションは低速化します。アプリケーションがオブジェクトを作成および解放する頻度によって、ヒープ サイズが影響を受け、それによってガベージ コレクションの実行頻度が決まります。したがって、可能であれば、新しいオブジェクトを作成するよりも、オブジェクトをキャッシュして再利用するようにしてください。
オブジェクトの大半の有効期間が短いことを理解すれば、ガベージ コレクションを効率化できるようチューニングできます。世代単位でメモリ管理を行う場合、複数のメモリ プールを作成して世代の異なるオブジェクトを保持します。ガベージ コレクションは世代ごとにプールがいっぱいになると実行されます。オブジェクトの大半の有効期間を 1 回のコレクションより短くすると、ガベージ コレクションを効率化できます。世代のサイズが小さいと、ガベージ コレクションの実行頻度が増加し、それによってパフォーマンスが低下します。
世代別ガベージ コレクションのチューニングの概要については、「Tuning Garbage Collection with the 1.3.1 Java Virtual Machine」(を参照してください。
verbose ガベージ コレクションを使用したヒープ サイズの決定
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) にマップされます。出力にはガベージ コレクションの実行時間を示すタイムスタンプが含まれているので、ガベージ コレクションの実行頻度を推測できます。
ヒープ サイズ値の指定および表2-2を参照してください。
Java ヒープ サイズの値は、WebLogic Server を起動するたびに指定する必要があります。ヒープ サイズ値は、Java コマンドラインから指定するか、WebLogic Server 起動用に WebLogic 配布キットに付属しているサンプル起動スクリプトのデフォルト値を変更して指定します。
たとえば、Java コマンドラインから WebLogic Server を起動する場合、ヒープ サイズ値は次のように指定できます。
$ java -XX:NewSize=128m -XX:MaxNewSize=128m -XX:SurvivorRatio=8 -Xms512m -Xmx512m
-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
これらの値のデフォルト サイズはバイト単位で指定されます。KB (キロバイト) を示すには、値に「k」または「K」を付加します。同様に、MB (メガバイト) を示すには「m」または「M」を、GB (ギガバイト) を示すには「g」または「G」を付加します。ヒープ サイズ オプションの詳細については、Java ヒープ サイズのオプションを参照してください。
WebLogic 起動スクリプトを使用したヒープ サイズの設定
WebLogic Server 配布キットには、サーバを起動するサンプル起動スクリプト、およびサーバを構築したり実行したりするための環境を設定するサンプル起動スクリプトが付属しています。
これらのスクリプトは、WL_HOME¥server¥bin にあります (WL_HOME は WebLogic Server のインストール位置)。これらの起動スクリプトは、Java に渡されるデフォルト メモリ引数 (つまり、ヒープ サイズ) や JDK の位置などの環境変数を設定し、その後に WebLogic Server の引数を使用して JVM を起動します。
WebLogic Server 起動スクリプトでは、デフォルト ヒープ サイズのパラメータが指定されます。したがって、実際の環境やアプリケーションに合わせてそれらのパラメータを変更する必要があります。「スクリプトを使用した管理サーバの起動」(を参照してください。
最高のパフォーマンスは、各アプリケーションを個別にチューニングすることで実現されます。ただし、WebLogic Server の起動時に表 2-2 の JVM ヒープ サイズ オプションをコンフィグレーションすると、ほとんどのアプリケーションでパフォーマンスを向上させることができます。
これらのオプションは、使用するアーキテクチャおよびオペレーティング システムによって異なります。プラットフォーム別の JVM チューニング オプションについては、ベンダのマニュアルを参照してください。
WebLogic Server では、サーバが観測した低メモリ状態を自動的にロギングできます。WebLogic Server では、ある特定の時間間隔で設定された回数だけ利用可能な空きメモリをサンプリングして低メモリが検出されます。各間隔の最後に、空きメモリの平均が記録され、それが次の間隔で得られた平均と比較されます。サンプル間隔の後に、ユーザがコンフィグレーションした量だけ平均が落ち込んだ場合、サーバは低メモリの警告メッセージをログ ファイルに記録し、サーバの状態を「警告」に設定します。
平均空きメモリが、サーバの起動直後に記録された初期空きメモリの 5% を下回ると、WebLogic Server はメッセージをログ ファイルに記録します。
低メモリ検出プロセスの各側面は、次のように Administration Console を使用してコンフィグレーションします。
サーバでガベージ コレクションを強制する前に、完全なガベージ コレクションが必要であることを確認してください。ガベージ コレクションを実行すると、JVM ではヒープ内のすべてのライブ オブジェクトを頻繁に調べます。
Administration Console を使用して、指定したサーバ インスタンスでガベージ コレクションを要求するには、次の手順に従います。
標準の java コマンドライン オプションを使用すると、JVM のパフォーマンスを向上させることができます。これらのオプションの使い方は、使用するアプリケーションのコーディングによって異なります。コマンドライン オプションはプラットフォーム間で一貫性がありますが、プラットフォームによってはデフォルトが異なる場合もあります。
クライアント JVM とサーバ JVM の両方をテストすると、特定のアプリケーションに対してよりパフォーマンスの優れたオプションを調べることができます。Sun Microsystems の「Java HotSpot VM Options」には、Java HotSpot 仮想マシンのパフォーマンス特性に影響を与えるコマンドライン オプションと環境変数に関する情報が記述されています。
パフォーマンスを向上させる、これ以外の VM オプションについては、非標準の Java オプション (Windows および UNIX 用)を参照してください。
標準の Java オプション (Windows および UNIX 用)
Windows では、WebLogic Server は java コマンドを通じ、表 2-3 のオプションのいずれかを指定して特定バージョンの JVM を起動します。
UNIX では、WebLogic Server は java コマンドを通じ、表 2-4 のオプションのいずれかを指定して特定バージョンの JVM を起動します。
Sun Microsystems の「The Java HotSpot Client and Server Virtual Machines」では、J2SE 1.3 で利用可能な Java 仮想マシンの 2 つの実装が説明されています。
非標準の Java オプション (Windows および UNIX 用)
非標準の Java オプションを使用しても、パフォーマンスを向上させることができます。これらのオプションの使い方は、使用するアプリケーションのコーディングによって異なります。コマンドライン オプションはプラットフォーム間で一貫性がありますが、プラットフォームによってはデフォルトが異なる場合もあります。非標準のコマンドライン オプションは、将来のリリースにおいて変更される可能性があります。
表 2-5 に、Windows 上の HotSpot VM でパフォーマンスを向上させる非標準オプションの例を 2 つ示します。
|
このオプションは、指定されたクラスのガベージ コレクションを無効にして、そのクラスへのすべての参照が失われた後にそのクラスが参照されたときに、そのクラスの再ロードを防ぐ。このオプションでは、ヒープ サイズを大きくする必要がある。 |
|
非標準 Windows オプションの他の例については、「Non-Standard Options (Windows VM 用)」(を参照してください。
表 2-6 に、UNIX Solaris 上の HotSpot VM でパフォーマンスを向上させる非標準オプションの例を 2 つ示します。
Solaris 用の非標準オプションの他の例については、「Non-Standard Options (Solaris VM 用)」(を参照してください。
|
|
|
|
||
 |
|
|
 |
 |
 |
|
||
