WebSphere Application Server, Version 6.0.x   
             オペレーティング・システム: AIX , HP-UX, Linux, Solaris, Windows

             目次と検索結果のパーソナライズ化

Java 仮想マシン設定

このページを使用して、アプリケーション・サーバーのプロセスの Java 仮想マシン (JVM) 構成の表示および変更を行います。

この管理コンソール・ページを表示するには、管理コンソールに接続し、「Java 仮想マシン」パネルにナビゲートします。

i5/OS および分散プラットフォーム・ベースの WebSphere Application Server および WebSphere Application Server - Express の場合、 「サーバー」>「アプリケーション・サーバー」>「server1」とクリックします。 次に「サーバー・インフラストラクチャー」の下で、 「Java およびプロセス管理」>「プロセス定義」>「Java 仮想マシン」とクリックします。

「構成」タブ

クラスパス

Java 仮想マシン・コードがクラスを検索する標準クラスパスを指定します。

各クラスパス・エントリーを表の行に入力してください。 各エントリーの最後にコロンまたはセミコロンを付け加える必要はありません。

データ型 ストリング
単位 クラスパス
ブート・クラスパス

JVM コードのブートストラップ・クラスおよびリソースを指定します。 このオプションは、 ブートストラップ・クラスおよびリソースをサポートする JVM 命令でのみ使用可能です。 コロン (:) またはセミコロン (;) (ノードのオペレーティング・システムによって決まる) で複数のパスを分離できます。

データ型 ストリング
冗長クラス・ロード

クラス・ロードのために冗長デバッグ出力を使用するかどうかを指定します。 デフォルトでは、冗長クラス・ロードは使用可能ではありません。

データ型 ブール
デフォルト false
冗長ガーベッジ・コレクション

ガーベッジ・コレクションの冗長デバッグ出力を使用するかどうかを指定します。 デフォルトでは、冗長ガーベッジ・コレクションは使用可能ではありません。

データ型 ブール
デフォルト false

このフィールドが使用可能な場合、ガーベッジ・コレクターが稼働するたびに、出力ストリームにレポートが書き込まれます。 このレポートは、Java ガーベッジ・コレクションで何が起こっているかを伝えます。

verboseGC レポートで探す重要なことは以下のとおりです。
  • ガーベッジ・コレクションに費やす時間。
    理想的には、GC に費やす時間は 5% 以下です。 GC に費やしている時間のパーセンテージを明らかにするには、コレクションを完了するまでにかかった時間を 最後の AF 以降の時間で割り、その結果に 100 を掛けます。以下に例を示します。
    83.29/3724.32 * 100 = 2.236%
    
    

    GC に 5% を超える時間を費やし、GC が頻繁に発生している場合、 ご使用の Java ヒープ・サイズを増やす必要があります。

  • 割り振られたヒープの増加。

    これを明らかにするには、%free を見ます。 数が減少し続けていないか確認します。%free が減少し続けている場合、GC から GC に 割り振られたヒープが徐々に増加しており、ご使用のアプリケーションにメモリー・リークがあることを示している可能性があります。

冗長 JNI

ネイティブ・メソッドの起動のために冗長デバッグ出力を使用するかどうかを指定します。 デフォルトでは、 冗長 Java ネイティブ・インターフェース (JNI) アクティビティーは使用可能ではありません。

データ型 ブール
デフォルト false
初期ヒープ・サイズ

JVM コードで使用可能な初期ヒープ・サイズ (メガバイト単位) を指定します。

最小ヒープ・サイズを増やすと、始動時間が短縮されます。ガーベッジ・コレクションの実行回数が減少するため、 パフォーマンスが 10% 向上します。

一般に、Java ヒープ・サイズを増やすと、物理メモリー中にヒープが存在しなくなるまでは、 スループットが向上します。 ディスクへのヒープのスワッピングが開始されると、Java パフォーマンスが 大幅に低下します。

データ型 整数
デフォルト

分散プラットフォームの場合、デフォルトは 50 です。

ほとんどのアプリケーションでは、これらのデフォルトの設定で問題ありません。

最大ヒープ・サイズ

JVM コードで使用可能な最大ヒープ・サイズ (メガバイト単位) を指定します。

ヒープ・サイズを増やすと、始動時間が短縮されます。ヒープ・サイズを増やすことによって、 ガーベッジ・コレクションの実行回数が減少するので、パフォーマンスを 10% 向上させることができます。

一般に、Java ヒープ・サイズを増やすと、物理メモリー中にヒープが存在しなくなるまでは、スループットが向上します。 ヒープ・サイズが物理メモリーを超えると、ヒープがディスクへスワッピングし始めるため、Java のパフォーマンスが大幅に低下します。 そのため、最大ヒープ・サイズは、ヒープが物理メモリー内に収まることができるような値に設定することが重要になります。

ページングを防止するには、各プロセッサーごとに少なくとも 256 MB の物理メモリー、 各アプリケーション・サーバーごとに 512 MB の物理メモリーを確保する値をこのプロパティーに指定する必要があります。 ページングのためにプロセッサー使用率が低い場合は、 可能であれば、最大ヒープ・サイズではなく、使用可能メモリーを増やします。 ヒープ・サイズを増やすと、パフォーマンスが良くなるどころか、さらに悪くなる可能性があります。

データ型 整数
デフォルト 256. ページングやメモリーからディスクへのスワップアウトを避けるために、値は小さくしておいてください。

ほとんどのアプリケーションでは、これらのデフォルトの設定で問題ありません。 冗長ガーベッジ・コレクション・フィールドを使用可能にすることにより、 ガーベッジ・コレクションの頻度をモニターすることができます。 ガーベッジ・コレクションが頻繁に発生しすぎる場合は、JVM ヒープの最大サイズを増やしてください。

HProf の実行

HProf プロファイラー・サポートを使用するかどうかを指定します。別のプロファイラーを使用するには、「HProf 引数」の設定を使用してカスタム・プロファイラーの設定を指定します。 デフォルトでは、HProf プロファイラー・サポートは使用可能ではありません。

この設定は、 基本 WebSphere Application Server および WebSphere Application Server - Express 製品にのみ適用されます。

「HProf の実行」プロパティーを true に設定する場合は、「HProf 引数」プロパティーの値としてコマンド行プロファイラー引数を指定する必要があります。

データ型 ブール
デフォルト false
HProf 引数

アプリケーション・サーバー・プロセスを開始する JVM コードに渡すコマンド行プロファイラー引数を指定します。 HProf プロファイラー・サポートが使用可能であるときは、引数を指定できます。

この設定は、 基本 WebSphere Application Server および WebSphere Application Server - Express 製品にのみ適用されます。

HProf 引数が必要になるのは、「HProf の実行」プロパティーが true に設定されている場合のみです。

データ型 ストリング
デバッグ・モード

JVM をデバッグ・モードで実行するかどうかを指定します。 デフォルトでは、デバッグ・モード・サポートは使用可能ではありません。

「デバッグ・モード」プロパティーを true に設定する場合は、 「デバッグ引数」プロパティーの値としてコマンド行デバッグ引数を指定する必要があります。

データ型 ブール
デフォルト false
デバッグ引数

アプリケーション・サーバー・プロセスを開始する JVM コードに渡すコマンド行デバッグ引数を指定します。 「デバッグ・モード」が使用可能である場合に、引数を指定できます。

基本 WebSphere Application Server および WebSphere Application Server - Express の構成では、デバッグ引数が必要になるのは、「デバッグ・モード」プロパティーが true に設定されている場合のみです。 複数のアプリケーション・サーバーでデバッグを使用可能にする場合は、各サーバーで、異なる address 引数 (この引数によって、デバッグ用のポートが定義される) を使用していることを確認してください。例えば、2 つのサーバーでデバッグを使用可能にし、 それぞれのサーバーのデフォルトのデバッグ・ポートを address=7777 のままにしておくと、 サーバーは正常に始動できない場合があります。

データ型 ストリング
単位 Java コマンド行の引数
汎用 JVM 引数

アプリケーション・サーバー・プロセスを始動する Java 仮想マシン・コードに渡すコマンド行引数を指定します。

以下は、汎用 JVM 引数フィールドに入力できる、オプションのコマンド行引数です。 複数の引数を入力する場合は、各引数の間にスペースを入力します。
重要: 引数が IBM Developer Kit のみを指定している場合には、この引数を Sun JDK または HP JDK などの他の JVM と共に使用することはできません。
  • -Xquickstart

    -Xquickstart は、デフォルト・モードの場合よりも低い最適化レベルでの初期コンパイルに使用できます。後で抽出結果に応じて、 デフォルト・モードでの初期コンパイル・レベルに再コンパイルすることができます。-Xquickstart は、 長時間に渡るスループットよりも、初期段階での適度な速度が重要とされるアプリケーションに使用します。 一部のデバッグ・シナリオ、一連のテスト、および実行時間の短いツールなどでは、起動時間を 15 - 20% 程度改善させることが可能です。

  • -Xverify:none

    クラス・ロード中にクラス検証の段階をスキップしたい場合は、-Xverify:none を使用することができます。ジャストインタイム (JIT) コンパイラーを使用可能にして -Xverify:none を使用することにより、起動時間は 10 から 15% 改善されます。

  • -Xnoclassgc

    -Xnoclassgc を使用すると、クラス・ガーベッジ・コレクションを使用不可にすることができます。 このアクションにより、クラスの再利用率が上がり、パフォーマンスが若干向上します。代わりに、これらのクラスが所有するリソースを収集できません。 verbose:gc 構成設定を使用すると、ガーベッジ・コレクションをモニターできます。 この設定で、クラス・ガーベッジ・コレクションの統計が出力されます。 これら統計を検査することによって、リソースの再利用と、リソースの再利用で必要なガーベッジ・コレクションの量との間のトレードオフについて理解できます。 ただし、同一のクラスのセットがワークロードで繰り返し収集される場合には、ガーベッジ・コレクションを使用不可にしてください。 デフォルトで、このクラス・ガーベッジ・コレクションは使用可能になっています。

  • -Xgcthreads

    ガーベッジ・コレクションのスレッドは、一度に複数使用することができます。 これは並列ガーベッジ・コレクション としても知られています。 この値を汎用 JVM 引数フィールドに入力する場合は、使用マシンに搭載されているプロセッサーの数も入力してください。例えば、-Xgcthreadsn とします。ここで、n はプロセッサー数です。n 個のプロセッサーを使用するノードでは、デフォルトのスレッド数は n です。 使用マシンに複数のプロセッサーが搭載されている場合は、 並列ガーベッジ・コレクションを使用する必要があります。 この引数は、IBM Developer Kit にのみ有効です。

  • -Xnocompactgc

    コストが最も高いガーベッジ・コレクション操作であるヒープ圧縮を使用不可にする場合には、-Xnocompactgc を使用することができます。IBM Developer Kit では圧縮を行わないでください。ヒープ圧縮を使用不可にすると、それに付随するすべてのオーバーヘッドがなくなります。

  • -Xinitsh

    -Xinitsh を使用すると、クラス・オブジェクトが格納される初期ヒープ・サイズを設定できます。 クラス・オブジェクトだけではなく、メソッド定義および静的フィールドも格納されます。 システムのヒープ・サイズに上限はありませんが、初期サイズを設定し、 システムのヒープ・サイズの拡張 (これには、オペレーティング・システムのメモリー・マネージャーの呼び出しが伴います) によるコストが発生しないようにしてください。WebSphere Application Server 製品にロードされるクラスの数 (約 8,000 クラス) およびその平均サイズを知ることにより、適切な初期システム・ヒープ・サイズを算出できます。 アプリケーションに関する知識がある場合は、それらを計算に含めることができます。 この引数は、IBM Developer Kit でのみ使用できます。

  • -Xgpolicy

    -Xgpolicy を使用すると、ガーベッジ・コレクション・ポリシーを設定できます。ガーベッジ・コレクション・ポリシー (gcpolicy) が、optavgpause に設定されている場合には、 並行マーキングを使用して、ヒープがフルになる前に、 スタックから開始されるアプリケーション・スレッドのトラッキングを行います。 このように設定すると、ガーベッジ・コレクターの休止が定期的になり、長期間休止することはなくなります。 このトレードオフとして、 スレッドが余分な処理を行わねばならないことによるスループットの低下が発生する場合があります。デフォルトで、推奨されている値は optthruput です。 値を -Xgcpolicy:[optthruput|optavgpause] として入力します。  この引数は、IBM Developer Kit でのみ使用できます。

  • -XX

    Sun ベースの Java Development Kit (JDK) バージョン 1.4.2 には、世代ガーベッジ・コレクションがあります。 これによって、存続期間が異なるオブジェクトを、それぞれ個別のメモリー・プールに入れることができます。ガーベッジ・コレクション・サイクルでは、存続期間に応じて、相互に独立してオブジェクトを収集します。 追加パラメーターを使用することで、メモリー・プールのサイズを個々に設定できます。 より良いパフォーマンスを得るには、存続期間の短いオブジェクトを含むプールを設定してください。 これによって、プール内のオブジェクトが、複数のガーベッジ・コレクション・サイクルに渡って存続することがなくなります。 新しい世代プールのサイズは、NewSize および MaxNewSize パラメーターによって決まります。

    最初のガーベッジ・コレクション・サイクルを存続したオブジェクトは、他のプールに転送されます。 この存続プールのサイズは、SurvivorRatio パラメーターによって決まります。 ガーベッジ・コレクションがボトルネックになった場合には、世代プールの設定値をカスタマイズしてみてください。 ガーベッジ・コレクション統計をモニターするには、Tivoli Performance Viewer のオブジェクト統計または verbose:gc 構成設定を使用します。 以下の値を入力します。
    -XX:NewSize (下限)
    -XX:MaxNewSize (上限)
     -XX:SurvivorRatio=NewRatioSize 

    デフォルト値は、NewSize=2m MaxNewSize=32m SurvivorRatio=2 です。 ただし、JVM のヒープ・サイズが 1 GB より大きい場合には、次の値 -XX:newSize=640m -XX:MaxNewSize=640m -XX:SurvivorRatio=16 を使用するか、新規世代プールに対してトータル・ヒープ・サイズを 50% から 60% に設定します。

  • -Xminf

    -Xminf を使用すると、最小フリー・ヒープ・サイズの割合を指定できます。フリー・スペースが指定量よりも少ない場合、 ヒープは大きくなります。リセット可能モードで、 このオプションは、ミドルウェアおよび一過性ヒープのフリー・スペースの最小割合を指定します。 これは、浮動小数点数 0 から 1 です。デフォルトは .3 (30%) です。

  • -server | -client

    Sun ベースの Java Development Kit (JDK) バージョン 1.4.2 の Java HotSpot Technology には、バイト・コードの実行を長期にわたり最適化するアルゴリズムを含む最適な JVM が導入されています。JVM は、-server および -client の 2 つのモードで実行します。 デフォルトの -client モードを使用する場合には、起動時間が短縮され、 メモリーのフットプリントが減少します。ただし、拡張パフォーマンスは低下します。 HotSpot JVM の立ち上げに十分な時間がかけられる場合には、-server モードを使用して、 バイト・コードを連続して実行することによって、パフォーマンスを向上させることができます。 ほとんどの場合、-server モードを使用します。これにより、長期間にわたるランタイム実行の効率をあげることができます。 プロセス・サイズとサーバー起動時間をモニターすることで、-client-server の違いを確認できます。

データ型 ストリング
単位 Java コマンド行引数
実行可能 JAR ファイル名

JVM コードで使用する実行可能な JAR ファイルの絶対パス名を指定します。

データ型 ストリング
単位 パス名
JIT を使用不可にする

JVM コードのジャストインタイム (JIT) コンパイラー・オプションを使用不可にするかどうかを指定します。

JIT コンパイラーを使用不可にしている場合は、スループットが著しく減少します。したがって、 パフォーマンス上の理由から、JIT は使用可能のままにしてください。

データ型 ブール
デフォルト false (JIT は使用可能)
推奨 JIT は使用可能
オペレーティング・システム名

所定のオペレーティング・システムの JVM 設定を指定します。

基本 WebSphere Application Server および WebSphere Application Server - Express 製品では、プロセスは、開始時に、サーバーに関して指定された JVM 設定をオペレーティング・システムの JVM 設定として使用します。

データ型 ストリング

「ランタイム」タブ

冗長ガーベッジ・コレクション

ガーベッジ・コレクションの冗長デバッグ出力を使用するかどうかを指定します。 デフォルトでは、冗長ガーベッジ・コレクションは使用可能ではありません。

データ型 ブール
デフォルト false

このフィールドが使用可能な場合、ガーベッジ・コレクターが稼働するたびに、出力ストリームにレポートが書き込まれます。 このレポートは、Java ガーベッジ・コレクションで何が起こっているかを伝えます。

verboseGC レポートで探す重要なことは以下のとおりです。
  • ガーベッジ・コレクションに費やす時間。
    理想的には、GC に費やす時間は 5% 以下です。 GC に費やしている時間のパーセンテージを明らかにするには、コレクションを完了するまでにかかった時間を 最後の AF 以降の時間で割り、その結果に 100 を掛けます。以下に例を示します。
    83.29/3724.32 * 100 = 2.236%
    
    

    GC に 5% を超える時間を費やし、GC が頻繁に発生している場合、 ご使用の Java ヒープ・サイズを増やす必要があります。

  • 割り振られたヒープの増加。

    これを明らかにするには、%free を見ます。 数が減少し続けていないか確認します。%free が減少し続けている場合、GC から GC に 割り振られたヒープが徐々に増加しており、ご使用のアプリケーションにメモリー・リークがあることを示している可能性があります。




関連タスク
JVM の構成
アプリケーション・サービス提供環境のチューニング
関連資料
カスタム・プロパティー・コレクション
参照トピック    

ご利用条件 | フィードバック

最終更新: Jan 22, 2008 12:07:38 AM EST
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp?topic=/com.ibm.websphere.base.doc/info/aes/ae/urun_rconfproc_jvm.html