5 Java仮想マシン(JVM)のチューニング

この章では、WebLogic Server用にJVMチューニング・オプションを構成する方法について説明します。Java仮想マシン(JVM)は、マイクロプロセッサ上でJavaクラス・ファイルのバイト・コードを実行する仮想の「実行エンジン」インスタンスです。JVMのチューニングは、WebLogic Serverとアプリケーションのパフォーマンスに影響を与えます。

• JVMのチューニングの考慮事項

• 使用しているシステムに適したJVM

• ガベージ・コレクション

• IA32プラットフォームでのスピンの有効化

JVMのチューニングの考慮事項

次の表は、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」(http://java.sun.com/docs/hotspot/threads/threads.html)を参照してください。

使用しているシステムに適したJVM

この項では、Windows、UNIX、およびLinuxプラットフォーム用のJava SE 5.0 JVMについて説明しますが、サーバー側アプリケーション用に開発され、Intelアーキテクチャ向けに最適化されたJRockit JVMを使用すると、Javaアプリケーションの信頼性、スケーラビリティ、管理容易性、柔軟性を向上できます。WindowsおよびLinuxプラットフォームでJRockitを使用する利点については、http://docs.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にあるJVM仕様の概要を参照してください。

他のJVMへの変更

ドメインを作成するときに、その構成のカスタマイズを選択すると、WebLogic ServerがインストールしたJDKのリストが構成ウィザードに表示されます。そのリストからドメインを実行するJVMを選択すると、ウィザードはその選択に基づいてOracle起動スクリプトを構成します。ドメインの作成後、別のJVMを使用する場合、『Oracle WebLogic Serverサーバーの起動と停止の管理』のサーバーを実行するJVMの変更に関する項を参照してください。

ガベージ・コレクション

ガベージ・コレクションは、Javaヒープ内の使用されていないJavaオブジェクトを解放するVMのプロセスです。次の項では、VMのガベージ・コレクションのチューニングに関する情報を示します。

• VMのヒープ・サイズとガベージ・コレクション

• ガベージ・コレクションの方式の選択

• verboseガベージ・コレクションを使用したヒープ・サイズの決定

• ヒープ・サイズ値の指定

• 低メモリー状態の自動的なロギング

• ガベージ・コレクションの手動によるリクエスト

• スレッド・スタックのリクエスト

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で利用可能なガベージ・コレクション・スキームの詳細は、「JRocktメモリー管理システムの使用」(http://www.oracle.com/technetwork/middleware/jrockit/overview/index.html)を参照してください。

• HPによるガベージ・コレクションの解説については、「Performance tuning Java: Tuning steps」(http://h21007.www2.hp.com/dspp/tech/tech_TechDocumentDetailPage_IDX/1,1701,1604,00.html)を参照してください。

verboseガベージ・コレクションを使用したヒープ・サイズの決定

verboseガベージ・コレクション・オプション(verbosegc)を使用すると、ガベージ・コレクションに費やされる時間とリソースを正確に測定できます。最も効率的なヒープ・サイズを判断するには、診断を目的としてverboseガベージ・コレクションを有効にし、出力をログ・ファイルにリダイレクトします。

次に、この手順を簡単に示します。

1. アプリケーション実行中に、最大の負荷をかけた状態でWebLogic Serverのパフォーマンスをモニターします。

2. -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)にマップされます。出力にはガベージ・コレクションの実行時間を示すタイムスタンプが含まれているので、ガベージ・コレクションの実行頻度を推測できます。

3. 次のデータ・ポイントを解析します。

   1. ガベージ・コレクションの実行頻度。weblogic.logファイルで、ガベージ・コレクション前後のタイム・スタンプを比較します。

   2. ガベージ・コレクションの実行時間。完全ガベージ・コレクションの実行時間は3 - 5秒を上回ってはいけません。

   3. 平均メモリー占有量。つまり、各完全ガベージ・コレクション後にヒープがどのような状態になるかです。ヒープの空きが常に85%になる場合、ヒープ・サイズを小さくしてもかまいません。

4. New世代のヒープ・サイズ(Sun)または保護領域のサイズ(JRockit)を参照してください。

   • JRockitについては、「JRockit JVMヒープ・サイズのオプション」を参照してください。

   • Sunについては、「Java HotSpot VMヒープ・サイズのオプション」を参照してください。

5. ヒープ・サイズがシステムの使用可能な空きRAMより大きくならないようにします。

   ページがディスクに「スワップ」されない範囲で、できるだけ大きいヒープ・サイズを設定します。システムの空きRAMの容量は、ハードウェアの構成と、そのマシン上で実行されているプロセスのメモリー要件によって異なります。システムの空きRAMの容量の決定については、システム管理者に問い合わせてください。

6. システムがガベージ・コレクションに費やす時間が長すぎる場合(割り当てられた仮想メモリーをRAMが処理できない場合)、ヒープ・サイズを小さくします。

   通常、使用可能なRAM (オペレーティング・システムまたはその他のプロセスによって占有されないRAM)の80%をJVMに割り当てます。

7. 使用可能な空きRAMが大量に残っている場合は、そのマシンでより多くのWebLogic Serverインスタンスを実行します。

   もう一度確認しますが、ヒープ・サイズのチューニングの目標は、WebLogic Serverで所定の時間に処理できるクライアントの数を最大限に増やしつつ、JVMによるガベージ・コレクションの実行時間を最小限に抑えることです。

   包括的なガベージ・コレクション・レポートを出力するその他のオプションについては、JVMベンダーが提供している場合があります。たとえば、JRockit JVMの-Xgcreportオプションを使用してプログラムの終了時に包括的なガベージ・コレクション・レポートを出力できます。http://docs.oracle.com/docs/cd/E13150_01/jrockit_jvm/jrockit/webdocs/index.htmlで、ガベージ・コレクション動作の表示に関する説明を参照してください。

ヒープ・サイズ値の指定

システム・パフォーマンスは、JVMで利用可能なJavaヒープのサイズによって大きく影響されます。この節では、ヒープ・サイズ値の定義に使用するコマンド・ライン・オプションについて説明します。Javaヒープ・サイズ値は、WebLogic Serverのインスタンスを起動するたびに指定する必要があります。ヒープ・サイズ値は、javaコマンド・ラインから指定するか、WebLogic Server起動用にWebLogic配布キットに付属しているサンプル起動スクリプトのデフォルト値を変更して指定します。

• ヒープ・サイズのチューニングのヒント

• JRockit JVMヒープ・サイズのオプション

• Java HotSpot VMヒープ・サイズのオプション

ヒープ・サイズのチューニングのヒント

次の項では、VMヒープ・サイズのチューニングに関する一般的なガイドラインを示します。

• ヒープ・サイズは、VMによって使用される最大メモリー量が、利用可能な物理的なRAM量を超えないような値に設定する必要があります。この値を超えると、OSがページングを開始するため、パフォーマンスが大幅に低下します。VMでは、常にヒープ・サイズより多いメモリーが消費されます。内部VM機能に必要なメモリー、VMの外部のネイティブ・ライブラリのメモリー、および永続世代メモリー(Sun VMのみ。クラスおよびメソッドの格納に必要なメモリー)が、ヒープ・サイズの設定の他に割り当てられます。

• 世代別ガベージ・コレクション方式を使用する場合、保護領域のサイズは、合計Javaヒープ・サイズの半分を超えないようにする必要があります。一般的には、ヒープ・サイズの25 - 40%が適切です。

• 本番環境では、ヒープを常に拡張したり縮小したりするために使用されるVMリソースを浪費しないように、最小ヒープ・サイズと最大ヒープ・サイズを同じ値に設定します。これは、New世代のヒープ・サイズ(Sun)または保護領域のサイズ(JRockit)にも適用されます。

JRockit JVMヒープ・サイズのオプション

JRockitでは、ヒープ・サイズのヒューリスティックな自動調整機能が提供されますが、この機能は、すべてのアプリケーションに最適ではありません。多くの場合、最高のパフォーマンスを引き出すには、各アプリケーションに対して次の表に示すヒープ・サイズ・オプションを調整し、VMをチューニングします。

表5-2 JRockit JVMヒープ・サイズのオプション

タスク	オプション	説明
保護領域を設定する	-Xns	可能な限り、できるだけ大きな保護領域を確保しつつ、ガベージ・コレクションの休止時間を許容できる限り短くするように設定する必要があります。これは、アプリケーションで一時的なオブジェクトを大量に作成している場合に特に重要になります。 保護領域の最大サイズは、最大ヒープ・サイズの95%を超えることはできません。
ヒープ・サイズの初期値と最小値を設定する	-Xms	最小ヒープ・サイズ(-Xms)は最大ヒープ・サイズ(-Xmx)と同じ大きさに設定して、ガベージ・コレクションを最小限に抑えることが推奨されます。
最大ヒープ・サイズを設定する	-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の適切なヒープ・サイズの設定の詳細は、http://docs.oracle.com/docs/cd/E13150_01/jrockit_jvm/jrockit/webdocs/index.htmlで、JRockit JVMのチューニングに関する説明を参照してください。

JRockit VMのその他のオプション

Oracleでは、JRockit VMのパフォーマンスを向上するその他のコマンド・ライン・オプションが用意されています。詳細情報については、http://docs.oracle.com/docs/cd/E13150_01/jrockit_jvm/jrockit/jrdocs/refman/index.htmlで、コマンド・ライン・リファレンスを参照してください。

Java HotSpot VMヒープ・サイズのオプション

最高のパフォーマンスは、アプリケーションを個別にチューニングすることで実現されます。ただし、WebLogic Serverの起動時に、次の表のJava HotSpot VMヒープ・サイズ・オプションを構成すると、ほとんどのアプリケーションでパフォーマンスを向上させることができます。

これらのオプションは、使用するアーキテクチャおよびオペレーティング・システムによって異なります。プラットフォーム別のJVMチューニング・オプションについては、ベンダーのドキュメントを参照してください。

表5-3 Javaヒープ・サイズ・オプション

タスク	オプション	説明
New世代領域のヒープ・サイズを設定する	-XX:NewSize	一般に-XX:NewSizeは、ヒープ・サイズの4分の1のサイズになるように設定します。有効期間の短いオブジェクトが多い場合ほど、このオプションの値を大きくします。 プロセッサ数が増加するほど、New世代領域を大きく設定する必要があります。メモリーの割当ては並列処理できますが、ガベージ・コレクションは並列処理されません。
New世代領域の最大ヒープ・サイズを設定する	-XX:MaxNewSize	New世代領域のヒープ・サイズの最大サイズを設定します。
New世代領域のヒープ・サイズ比率を設定する	-XX:SurvivorRatio	New世代領域は、3つのサブ領域、つまりEdenと、同じサイズの2つのサバイバル領域に分割されます。 Edenとサバイバル領域の比率を構成します。この値は8に設定し、その後、ガベージ・コレクションをモニターするようにします。
ヒープ・サイズの初期値を設定する	-Xms	一般的なルールとしては、ガベージ・コレクションを最小限にするために、ヒープ・サイズの初期値(-Xms)をヒープ・サイズの最大値(-Xmx)と等しく設定します。
最大ヒープ・サイズを設定する	-Xmx	ヒープ・サイズの最大サイズを設定します。
大きなヒープおよびIntimate Shared Memoryを設定する	-XX:+UseISM -XX:+AggressiveHeap	http://java.sun.com/docs/hotspot/ism.htmlを参照してください。

たとえば、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 HotSpot VMのその他のオプション

VMのパフォーマンスを向上させるその他の標準および非標準のコマンド・ライン・オプションが用意されています。これらのオプションの使い方は、使用するアプリケーションのコーディングによって異なります。

クライアントJVMとサーバーJVMの両方をテストすると、特定のアプリケーションに対してよりパフォーマンスの優れたオプションを調べることができます。Java HotSpot仮想マシンのパフォーマンス特性に影響を及ぼすコマンドライン・オプションと環境変数の詳細は、http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.htmlを参照してください。

HotSpot VMオプションのその他の例については次を参照してください:

• Windows (Win32) VM用標準オプション(http://docs.oracle.com/javase/6/docs/technotes/tools/windows/java.html)。

• Solaris VMおよびLinux VM用標準オプション(http://docs.oracle.com/javase/6/docs/technotes/tools/solaris/java.html)。

Java SE 5.0のJava仮想マシンのクライアントおよびサーバーの実装に関する詳細は、Java Virtual Machineのドキュメント(http://docs.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管理コンソール・ヘルプのスレッド・スタックの表示に関する項を参照してください。

IA32プラットフォームでのスピンの有効化

マルチプロセッサ・システム上でロックの競合が激しい高負荷のアプリケーションを実行している場合、スピンを使用してパフォーマンスの向上を試みることができます。このオプションを使用すると、スリープ状態に入る前に、短時間ロックをスピンすることができます。

Sun JDK

Sunは、Windows IA32プラットフォーム上のJDK 5.0において、デフォルトのロック・スピン動作を変更しました。JDK 5.0リリースでは、ロック・スピンがデフォルトで無効になっています。このリリースでは、WebLogic Serverの起動に使用する環境スクリプト内でスピンを明示的に有効にしています。スピンを有効にするには、次のVMオプションを使用します。

-XX:+UseSpinning

JRockit

JRockit VMでは、様々なロックに対するスピンが自動的に調整されるため、このパラメータを設定する必要はありません。