Oracle® Fusion Middleware Oracle WebLogic Serverパフォーマンスおよびチューニング 12c リリース1 (12.1.1) B65905-02 |
|
前 |
次 |
この章では、WebLogic Server用にJVMチューニング・オプションを構成する方法について説明します。Java仮想マシン(JVM)は、マイクロプロセッサ上でJavaクラス・ファイルのバイト・コードを実行する仮想の「実行エンジン」インスタンスです。JVMのチューニングは、WebLogic Serverとアプリケーションのパフォーマンスに影響を与えます。
次の表は、WebLogic ServerにおけるJVMのチューニングに関する一般的な考慮事項を示しています。
表5-1 JVMのチューニングの一般的な考慮事項
チューニング事項 | 参照情報 |
---|---|
JVMのベンダーおよびバージョン |
WebLogic Serverの動作が確認されている製品JVMだけを使用します。このリリースのWebLogic Serverは、Java SE 5.0準拠のJVMのみサポートします。 様々なプラットフォームの最新の動作確認情報へのリンクは、『Oracle WebLogic Serverの新機能』のサポートされる構成に関する項を参照してください。 |
ヒープ・サイズおよびガベージ・コレクションのチューニング |
WebLogic Serverのヒープ・サイズ・チューニングの詳細は、「ガベージ・コレクション」を参照してください。 |
ガベージ・コレクションの方式の選択 |
システム・メモリーの管理に使用できるガベージ・コレクションの方式は、アプリケーションによって異なります。詳細は、「ガベージ・コレクションの方式の選択」を参照してください。 |
クライアント/サーバーJVMの混在 |
WebLogic Serverでは、クライアントとサーバー用に異なるJVMバージョンを使用したデプロイメントがサポートされています。サポートされている最新の混合クライアント/サーバーJVMへのリンクは、『Oracle WebLogic Serverの新機能』のサポートされる構成に関する項を参照してください。 |
UNIXスレッディング・モデル |
Solarisスレッディング・モデルに関する選択は、Solaris上のJVMのパフォーマンスに大きく影響します。モデル内で複数のスレッディング・モデルと異なる同期方式を選択できますが、これはJVMによって異なります。 「Performance Documentation For the Java Hotspot Virtual Machine: Threading」( |
この項では、Windows、UNIX、およびLinuxプラットフォーム用のJava SE 5.0 JVMについて説明しますが、サーバー側アプリケーション用に開発され、Intelアーキテクチャ向けに最適化されたJRockit JVMを使用すると、Javaアプリケーションの信頼性、スケーラビリティ、管理容易性、柔軟性を向上できます。WindowsおよびLinuxプラットフォームでJRockitを使用する利点については、http://download.oracle.com/docs/cd/E13150_01/jrockit_jvm/jrockit/webdocs/index.html
にあるJRockit JDKの紹介を参照してください。
JVMの一般情報については、「http://java.sun.com/docs/books/vmspec/2nd-edition/html/Introduction.doc.html#3057」
でIntroduction to the JVM specificationに関する項を参照してください。
ガベージ・コレクションは、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://www.oracle.com/technetwork/java/gc-tuning-5-138395.html
)を参照してください。
コレクション方式の利用に関する全般的な説明については、「Improving Java Application Performance and Scalability by Reducing Garbage Collection Times and Sizing Memory Using JDK 1.4.1」(http://www.oracle.com/technetwork/java/index-jsp-138820.html
)を参照してください。
JRockit JDKで使用できるガベージ・コレクション方式については、「Using the JRockit Memory Management System」(http://download.oracle.com/docs/cd/E13150_01/jrockit_jvm/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://download.oracle.com/docs/cd/E13150_01/jrockit_jvm/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://download.oracle.com/docs/cd/E13150_01/jrockit_jvm/jrockit/webdocs/index.html
)を参照してください。
Oracleでは、JRockit VMのパフォーマンスを向上するその他のコマンド・ライン・オプションが用意されています。詳細情報については、「http://download.oracle.com/docs/cd/E13150_01/jrockit_jvm/jrockit/jrdocs/refman/index.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を割り当てています。
VMのパフォーマンスを向上させるその他の標準および非標準のコマンド・ライン・オプションが用意されています。これらのオプションの使い方は、使用するアプリケーションのコーディングによって異なります。
クライアントJVMとサーバーJVMの両方をテストすると、特定のアプリケーションに対してよりパフォーマンスの優れたオプションを調べることができます。Java HotSpot仮想マシンのパフォーマンス特性に影響を及ぼすコマンドライン・オプションと環境変数の詳細は、http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html
を参照してください。
HotSpot VMオプションのその他の例については次を参照してください。
「Standard Options for Windows (Win32) VMs」(http://download.oracle.com/javase/6/docs/technotes/tools/windows/java.html
)。
「Standard Options for Solaris VMs and Linux VMs」(http://download.oracle.com/javase/6/docs/technotes/tools/solaris/java.html
)。
Java SE 5.0のJava仮想マシンのクライアントおよびサーバーの実装に関する詳細は、「Java Virtual Machine」ドキュメント(http://download.oracle.com/javase/1.5.0/docs/guide/vm/index.html
)を参照してください。
WebLogic Serverでは、サーバーによって監視した低メモリー状態を自動的にログに記録できます。WebLogic Serverは、使用可能な空きメモリーをある時間間隔内に一定回数サンプリングし、低メモリーを検出します。各間隔の経過時に空きメモリーの平均がログに記録され、次の間隔で取得した平均と比較されます。サンプルの間隔の経過時の平均がユーザーが構成した値より低い場合、サーバーは低メモリー警告をログ・ファイルに記録し、サーバーのヘルス状態を「警告」に設定します。Oracle WebLogic Server管理コンソール・ヘルプの低メモリー状態のロギングに関する項を参照してください。
管理コンソールから完全なガベージ・コレクションを手動でリクエストする必要がある場合があります。その場合、JVMがヒープ内のすべての有効なオブジェクトを調べることが多くあるため、ガベージ・コレクションに対してコストがかかることに注意してください。Oracle WebLogic Server管理コンソール・ヘルプのガベージ・コレクションの手動によるリクエストに関する項を参照してください。
アプリケーションをチューニングするときに、スレッド・スタックを表示する必要がある場合があります。Oracle WebLogic Server管理コンソール・ヘルプのスレッド・スタックの表示に関する項を参照してください。
マルチプロセッサ・システム上でロックの競合が激しい高負荷のアプリケーションを実行している場合、スピンを使用してパフォーマンスの向上を試みることができます。このオプションを使用すると、スリープ状態に入る前に、短時間ロックをスピンすることができます。
Sunは、Windows IA32プラットフォーム上のJDK 5.0において、デフォルトのロック・スピン動作を変更しました。JDK 5.0リリースでは、ロック・スピンがデフォルトで無効になっています。このリリースでは、WebLogic Serverの起動に使用する環境スクリプト内でスピンを明示的に有効にしています。スピンを有効にするには、次のVMオプションを使用します。
-XX:+UseSpinning