Oracle® Fusion Middleware Oracle WebLogic Server パフォーマンス チューニング ガイド 11g リリース 1 (10.3.1) B55570-01 |
|
![]() 戻る |
![]() 次へ |
Java 仮想マシン (JVM) は、マイクロプロセッサ上で Java クラス ファイルのバイト コードを実行する仮想の「実行エンジン」インスタンスです。JVM のチューニングは、WebLogic Server とアプリケーションのパフォーマンスに影響を与えます。
以下の節では、WebLogic Server 用の JVM チューニング オプションについて説明します。
次の表は、WebLogic Server における JVM のチューニングに関する一般的な考慮事項を示しています。
表 5-1 JVM のチューニングの一般的な考慮事項
チューニング事項 | 参照情報 |
---|---|
JVM のベンダおよびバージョン |
WebLogic Server の動作が確認されているプロダクション JVM だけを使用すること。このリリースの WebLogic Server は、J2SE 5.0 準拠の JVM のみサポートする。 サポート対象のコンフィグレーションに関するページ ( |
ヒープ サイズおよびガベージ コレクションのチューニング |
WebLogic Server のヒープ サイズ チューニングの詳細については、「ガベージ コレクション」を参照。 |
ガベージ コレクションの方式の選択 |
システム メモリの管理に使用できるガベージ コレクションの方式は、アプリケーションによって異なる。詳細については、「ガベージ コレクションの方式の選択」を参照。 |
クライアント/サーバ JVM の混在 |
WebLogic Server では、クライアントとサーバ用に異なる JVM バージョンを使用したデプロイメントがサポートされている。サポート対象のコンフィグレーションに関するページ ( |
UNIX スレッディング モデル |
Solaris スレッディング モデルに関する選択は、Solaris 上の JVM のパフォーマンスに大きく影響する。モデル内で複数のスレッディング モデルと異なる同期方式を選択できるが、これは JVM によって異なる。 「Performance Documentation For the Java Hotspot Virtual Machine: Threading」( |
この節では Windows、UNIX、および Linux プラットフォーム用の Sun Microsystems J2SE 5.0 JVM について説明しますが、サーバサイド アプリケーション用に開発され、Intel アーキテクチャ向けに最適化された JRockit JVM を使用すると、Java アプリケーションの信頼性、スケーラビリティ、管理容易性、柔軟性を向上できます。Windows および Linux プラットフォームで JRockit を使用する利点については、『JRockit JDK の紹介』(http://otndnld.oracle.co.jp/document/products/jrockit/webdocs/index.html
) を参照してください。
JVM の一般的な情報については、「Introduction to the JVM specification」(http://java.sun.com/docs/books/vmspec/2nd-edition/html/Introduction.doc.html#3057
) を参照してください。JVM チューニングの関連情報へのリンクについては、「関連情報 : パフォーマンス ツールと情報」を参照してください。
ドメインを作成するときに、そのコンフィグレーションのカスタマイズを選択すると、WebLogic Server がインストールした JDK のリストがコンフィグレーション ウィザードに表示されます。そのリストからドメインを実行する JVM を選択し、ウィザードはその選択に基づいて Oracle 起動スクリプトをコンフィグレーションします。ドメインを作成した後で使用する JVM を変更する場合は、『Oracle Fusion Middleware Oracle WebLogic Server サーバの起動と停止の管理』の「サーバを実行する 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 のガベージ コレクション オプションの詳細については、以下のリンクを参照してください。
Sun の HotSpot VM で使用できるガベージ コレクション方式の概要については、「Tuning Garbage Collection with the 5.0 Java Virtual Machine」(http://java.sun.com/docs/hotspot/gc5.0/gc_tuning_5.html
) を参照。
コレクション方式の利用に関する全般的な説明については、「Improving Java Application Performance and Scalability by Reducing Garbage Collection Times and Sizing Memory Using JDK 1.4.1」(http://wireless.java.sun.com/midp/articles/garbagecolletion2/
) を参照。
JRockit JDK で使用できるガベージ コレクション方式については、「Using the JRockit Memory Management System」(http://otndnld.oracle.co.jp/document/products/jrockit/webdocs/index.html
) を参照。
HP によるガベージ コレクションの解説については、「Performance tuning Java: Tuning steps」(http://h21007.www2.hp.com/dspp/tech/tech_TechDocumentDetailPage_IDX/1,1701,1604,00.html
) を参照。
verbose ガベージ コレクション オプション (verbosegc
) を使用すると、ガベージ コレクションに費やされる時間とリソースを正確に測定できます。最も効率的なヒープ サイズを判断するには、診断を目的として verbose ガベージ コレクションを有効にし、出力をログ ファイルにリダイレクトします。
次に、この手順を簡単に示します。
アプリケーション実行中に、最大の負荷をかけた状態で WebLogic Server のパフォーマンスをモニタします。
-verbosegc
オプションを使用して JVM の verbose ガベージ コレクション出力を有効にし、標準エラーおよび標準出力の両方をログ ファイルにリダイレクトします。
リダイレクトすることにより、スレッド ダンプ情報が WebLogic Server の情報メッセージとエラー メッセージに関連してログに記録されるので、診断する際にログ ファイルがさらに役立ちます。
たとえば、Windows および Solaris では次のように入力します。
% java -ms32m -mx200m -verbosegc -classpath $CLASSPATH -Dweblogic.Name=%SERVER_NAME% -Dbea.home="C:\Oracle\Middleware" -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) にマップされます。出力にはガベージ コレクションの実行時間を示すタイムスタンプが含まれているので、ガベージ コレクションの実行頻度を推測できます。
以下のデータ ポイントを解析します。
ガベージ コレクションの実行頻度。weblogic.log ファイルで、ガベージ コレクション前後のタイム スタンプを比較します。
ガベージ コレクションの実行時間。ガベージ コレクション全体の実行時間は 3 ~ 5 秒を上回ってはいけません。
平均メモリ占有量。つまり、各ガベージ コレクション実行後のヒープの状態です。ヒープの空きが常に 85% になる場合、ヒープ サイズを小さくしてもかまいません。
New 世代のヒープ サイズ (Sun) または保護領域のサイズ (JRockit) を参照してください。
JRockit については、「JRockit JVM ヒープ サイズのオプション」を参照。
Sun については、「Java HotSpot VM ヒープ サイズのオプション」を参照。
ヒープ サイズがシステムの使用可能な空き RAM より大きくならないようにします。
ページがディスクに「スワップ」されない範囲で、できるだけ大きいヒープ サイズを設定します。システムの空き RAM の容量は、ハードウェアのコンフィグレーションと、そのマシン上で実行されているプロセスのメモリ要件によって異なります。システムの空き RAM の容量の決定については、システム管理者に問い合わせてください。
システムがガベージ コレクションに費やす時間が長すぎる場合 (割り当てられた仮想メモリを RAM が処理できない場合)、ヒープ サイズを小さくします。
通常、使用可能な RAM (オペレーティング システムまたはその他のプロセスによって占有されない RAM) の 80% を JVM に割り当てます。
使用可能な空き RAM が大量に残っている場合は、そのマシンでより多くの WebLogic Server インスタンスを実行します。
もう一度確認しますが、ヒープ サイズのチューニングの目標は、WebLogic Server で所定の時間に処理できるクライアントの数を最大限に増やしつつ、JVM によるガベージ コレクションの実行時間を最小限に抑えることです。
包括的なガベージ コレクション レポートを出力するその他のオプションについては、JVM ベンダが提供している場合があります。たとえば、JRockit JVM -Xgcreport
オプションを使用してプログラムの終了時にガベージ コレクション レポートを出力する方法については、「Viewing Garbage Collection Behavior」(http://otndnld.oracle.co.jp/document/products/jrockit/webdocs/index.html
) を参照してください。
システム パフォーマンスは、JVM で利用可能な Java ヒープのサイズによって大きく影響されます。この節では、ヒープ サイズ値の定義に使用するコマンドライン オプションについて説明します。Java ヒープ サイズ値は、WebLogic Server のインスタンスを起動するたびに指定する必要があります。ヒープ サイズ値は、java
コマンドラインから指定するか、WebLogic Server 起動用に WebLogic 配布キットに付属しているサンプル起動スクリプトのデフォルト値を変更して指定します。
以下の節では、VM ヒープ サイズのチューニングに関する一般的なガイドラインを示します。
ヒープ サイズは、VM によって使用される最大メモリ量が、利用可能な物理的な RAM 量を超えないような値に設定する必要があります。この値を超えると、OS がページングを開始するため、パフォーマンスが大幅に低下します。VM では、常にヒープ サイズより多いメモリが消費されます。内部 VM 機能に必要なメモリ、VM の外部のネイティブ ライブラリのメモリ、および永続世代メモリ (Sun VM のみ。クラスおよびメソッドの格納に必要なメモリ) が、ヒープ サイズの設定の他に割り当てられます。
世代別ガベージ コレクション方式を使用する場合、保護領域のサイズは、合計 Java ヒープ サイズの半分を超えないようにする必要があります。一般的には、ヒープ サイズの 25 ~ 40% が適切です。
プロダクション環境では、ヒープを常に拡張したり縮小したりするために使用される VM リソースを浪費しないように、最小ヒープ サイズと最大ヒープ サイズを同じ値に設定します。これは、New 世代のヒープ サイズ (Sun) または保護領域のサイズ (JRockit) にも適用されます。
JRockit では、ヒープ サイズのヒューリスティックな自動調整機能が提供されますが、この機能は、すべてのアプリケーションに最適ではありません。多くの場合、最高のパフォーマンスを引き出すには、各アプリケーションに対して次の表に示すヒープ サイズ オプションを調整し、VM をチューニングします。
表 5-2 JRockit JVM ヒープ サイズのオプション
タスク | オプション | 説明 |
---|---|---|
保護領域を設定する。 |
-Xns |
可能な限り、できるだけ大きな保護領域を確保しつつ、ガベージ コレクションの休止時間を許容できる限り短くするように設定する必要がある。これは、アプリケーションで一時的なオブジェクトを大量に作成している場合に特に重要になる。 保護領域の最大サイズは、最大ヒープ サイズの 95% を超えることはできない。 |
最小ヒープ サイズを設定する。 |
-Xms |
最小ヒープ サイズ ( |
最大ヒープ サイズを設定する。 |
-Xmx |
実データの量と比較して、最大ヒープ値を低めに設定すると、ガベージ コレクションが頻繁に行われ、パフォーマンスが低下する。 |
ガベージ コレクションを設定する。 |
-Xgc: parallel |
|
Java アプリケーションの実行のできるだけ早い段階で、適応性のある最適化を行う。 |
-XXaggressive:memory |
これを実現するために、ボトルネック ディテクタが最初は高い頻度で実行され、その後、実行頻度は徐々に低くなる。また、このオプションを指定すると、JRockit は利用可能なメモリを積極的に使うようになる。 |
たとえば、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 チューニング ガイド』(http://otndnld.oracle.co.jp/document/products/jrockit/webdocs/index.html
) を参照してください。
Oracle は、JRockit VM のパフォーマンスを向上させるその他のコマンドライン オプションを提供しています。詳細については、『名前別の JRockit JDK コマンドライン オプション』(http://e-docs.bea.com/jrockit/docs50/options.html
) を参照してください。
最高のパフォーマンスは、アプリケーションを個別にチューニングすることで実現されます。ただし、WebLogic Server の起動時に、次の表の Java HotSpot VM ヒープ サイズ オプションをコンフィグレーションすると、ほとんどのアプリケーションでパフォーマンスを向上させることができます。
これらのオプションは、使用するアーキテクチャおよびオペレーティング システムによって異なります。プラットフォーム別の JVM チューニング オプションについては、ベンダのマニュアルを参照してください。
表 5-3 Java ヒープ サイズ オプション
タスク | オプション | 説明 |
---|---|---|
New 世代領域のヒープ サイズを設定する。 |
-XX:NewSize |
一般に プロセッサ数が増加するほど、New 世代領域を大きく設定する必要がある。メモリの割り当ては並列処理できるが、ガベージ コレクションは並列処理されない。 |
New 世代領域の最大ヒープ サイズを設定する。 |
-XX:MaxNewSize |
New 世代領域のヒープ サイズの最大サイズを設定する。 |
New 世代領域のヒープ サイズ比率を設定する。 |
-XX:SurvivorRatio |
New 世代領域は、3 つのサブ領域、つまり Eden と、同じサイズの 2 つのサバイバル領域に分割される。 Eden とサバイバル領域の比率をコンフィグレーションする。この値は 8 に設定し、その後、ガベージ コレクションをモニタするようにする。 |
最小ヒープ サイズを設定する。 |
-Xms |
一般に、最小ヒープ サイズ ( |
最大ヒープ サイズを設定する。 |
-Xmx |
ヒープ サイズの最大サイズを設定する。 |
大きなヒープおよび Intimate Shared Memory を設定する。 |
-XX:+UseISM -XX:+AggressiveHeap |
たとえば、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 仮想マシンのパフォーマンス特性に影響を与えるコマンドライン オプションと環境変数に関する情報が記述されています。http://java.sun.com/docs/hotspot/VMOptions.html
を参照してください。
HotSpot VM オプションのその他の例については以下を参照してください。
「Standard Options for Windows (Win32) VMs」(http://java.sun.com/javase/6/docs/tooldocs/windows/java.html
)
「Standard Options for Solaris VMs」(http://java.sun.com/javase/6/docs/tooldocs/solaris/java.html
)
「Standard Options for Linux VMs」(http://java.sun.com/j2se/1.5.0/docs/tooldocs/linux/java.html
)
J2SE 5.0 (http://java.sun.com/j2se/1.5.0/docs/guide/vm/index.html
) 準拠の Java 仮想マシンのクライアントおよびサーバの実装に関する詳細については、Sun Microsystems の「Java Virtual Machine」ドキュメントを参照してください。
WebLogic Server では、低メモリ状態をサーバで観察して自動的にログに記録できます。WebLogic Server では、ある特定の時間間隔で設定された回数だけ利用可能な空きメモリをサンプリングして低メモリが検出されます。各間隔の最後に、空きメモリの平均が記録され、それが次の間隔で得られた平均と比較されます。サンプル間隔の後に、ユーザがコンフィグレーションした量だけ平均が落ち込んだ場合、サーバは低メモリの警告メッセージをログ ファイルに記録し、サーバの状態を「warning」に設定します。Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「低メモリ状態のログへの記録」を参照してください。
Administration Console から完全なガベージ コレクションを手動で要求する必要がある場合があります。ガベージ コレクションを実行すると、JVM はヒープ内のすべてのライブ オブジェクトを頻繁に調べるため、コストがかかることに留意してください。Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「ガベージ コレクションの手動による要求」を参照してください。
アプリケーションのチューニング中にスレッド スタックの表示が必要になる場合があります。Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「スレッド スタックの表示」を参照してください。
マルチプロセッサ システム上でロックの競合が激しい高負荷のアプリケーションを実行している場合、スピンを使用してパフォーマンスの向上を試みることができます。このオプションを使用すると、スリープ状態に入る前に、短時間ロックをスピンすることができます。
Sun は、Windows IA32 プラットフォーム上の JDK 5.0 において、デフォルトのロック スピン動作を変更しました。JDK 5.0 リリースでは、ロック スピンがデフォルトで無効になっています。このリリースでは、WebLogic Server の起動に使用する環境スクリプト内でスピンを明示的に有効にしています。スピンを有効にするには、以下の VM オプションを使用します。
-XX:+UseSpinning