WebSphere Application Server for z/OS, Version 6.1   
             オペレーティング・システム: z/OS

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

Java 仮想マシン設定

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

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

z/OS プラットフォームの場合
アプリケーション・サーバー サーバー」>「アプリケーション・サーバー」>「server1」とクリックします。 次に、「サーバー・インフラストラクチャー」の下で、「プロセス定義」をクリックし、 「コントロール」または「サーバント」を選択してから、 「Java 仮想マシン」をクリックします。
デプロイメント・マネージャー システム管理」>「デプロイメント・マネージャー」とクリックします。 次に「サーバー・インフラストラクチャー」の下で、 「プロセス定義」>「コントロール」>「Java 仮想マシン」とクリックします
ノード・エージェント システム管理」>「ノード・エージェント」>「nodeagent 」とクリックします。 次に「サーバー・インフラストラクチャー」の下で、 「プロセス定義」>「コントロール」>「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 に 割り振られたヒープが徐々に増加しており、ご使用のアプリケーションにメモリー・リークがあることを示している可能性があります。

また、MVS コンソール・コマンドの変更コマンドで display, jvmheap を指定し 、JVM ヒープ情報を表示することができます。 詳しくは、『変更コマンド』を参照してください。 さらに、サーバー・アクティビティーおよびインターバル SMF レコードを確認することができます。 また、JVM ヒープ・サイズは PMI に使用可能で、Tivoli Performance Viewer を使用してモニターすることができます。

冗長 JNI

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

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

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

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

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

データ型 整数
デフォルト

z/OS の場合、コントローラーのデフォルトは 48、サーバントのデフォルトは 128 です。 これらのデフォルト値は、31 ビットと 64 ビットの両方の構成に適用されます。

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

最大ヒープ・サイズ

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

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

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

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

データ型 整数
デフォルト

z/OS プラットフォームの場合、 31 ビットと 64 ビットの構成のデフォルトはともに 256 です。 ページングやメモリーからディスクへのスワップアウトを避けるために、値は小さくしておいてください。

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

デバッグ・モード

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

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

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

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

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

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

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

以下は、汎用 JVM 引数フィールドに入力できる、オプションのコマンド行引数です。 複数の引数を入力する場合は、各引数の間にスペースを入力します。
重要: 引数が IBM Developer Kit のみを指定している場合には、この引数を Sun JDK または HP JDK などの他の JVM と共に使用することはできません。
  • hotRestartSync: hotRestartSync を使用して、 同期サービスのホット・リスタート同期機能を使用可能にできます。 この機能は、デプロイメント・マネージャーがアクティブでないときは構成更新が行われない環境で、 インストールが実行されている同期サービスを示しています。 したがって、サービスは、デプロイメント・マネージャーまたはノード・エージェントの再始動時に、 完全なリポジトリーの比較を行う必要はありません。 このフィーチャーを使用可能にすると、デプロイメント・マネージャーまたはノード・エージェントの再始動後の、 最初の同期操作の効率が良くなります。 これは、特に、混合リリース・セル、多数のノード、および多数のアプリケーションの実行を含むインストールの場合です。
  • -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 2 Standard Edition (J2SE) 5 には、 世代ガーベッジ・コレクションがあります。これによって、存続期間が異なるオブジェクトを、それぞれ個別のメモリー・プールに入れることができます。ガーベッジ・コレクション・サイクルでは、存続期間に応じて、相互に独立してオブジェクトを収集します。 追加パラメーターを使用することで、メモリー・プールのサイズを個々に設定できます。 より良いパフォーマンスを得るには、存続期間の短いオブジェクトを含むプールを設定してください。 これによって、プール内のオブジェクトが、複数のガーベッジ・コレクション・サイクルに渡って存続することがなくなります。 新しい世代プールのサイズは、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 2 Standard Edition (J2SE) 5 の Java HotSpot Technology には、 バイト・コードの実行を長期にわたり最適化するアルゴリズムを含む最適な JVM が使用されています。JVM は、-server および -client の 2 つのモードで実行します。 デフォルトの -client モードを使用する場合には、起動時間が短縮され、 メモリーのフットプリントが減少します。ただし、拡張パフォーマンスは低下します。 HotSpot JVM の立ち上げに十分な時間がかけられる場合には、-server モードを使用して、 バイト・コードを連続して実行することによって、パフォーマンスを向上させることができます。 ほとんどの場合、-server モードを使用します。これにより、長期間にわたるランタイム実行の効率をあげることができます。 プロセス・サイズとサーバー起動時間をモニターすることで、-client-server の違いを確認できます。

  • -Dcom.ibm.ws.buffermgmt.impl.WsByteBufferPoolManagerImpl=

    -Dcom.ibm.ws.buffermgmt.impl.WsByteBufferPoolManagerImpl= 引数を使用して、 バッファーが不要になった直後に、個々の直接バイト・バッファーのストレージを解放することを示すことができます。 この引数のサポートされる唯一の値は、com.ibm.ws.buffermgmt.impl.ZOSWsByteBufferPoolManagerImpl です。

    要求データを処理するために JVM が作成する直接バイト・バッファーは、 JVM ヒープではなく、LE ヒープ内に割り振られます。 通常は、直接バイト・バッファーが不要になっても、JVM は、次のガーベッジ・コレクションが行われるまで、 ネイティブ LE ストレージを解放しません。 サーバーが大量の要求を処理している場合は、 JVM がガーベッジ・コレクション・サイクルを実行する前に LE ストレージが使い尽くされ、 サーバーは異常終了 (アベンド) することがあります。 以下の引数を使用して JVM を構成すると、このような異常終了は発生しなくなります。
    -Dcom.ibm.ws.buffermgmt.impl.WsByteBufferPoolManagerImpl=com.ibm.ws.buffermgmt.impl.ZOSWsByteBufferPoolManagerImpl

    z/OS プラットフォームでは、これらのバッファーが接続に不要になった直後、 チャネルが新規接続で使用される初期読み取りバッファーを解放する必要があることを示すために、TCP チャネルの zaioFreeInitialBuffers カスタム・プロパティー を使用する場合にも、この引数を指定する必要があります。

  • -Xshareclasses:none

    -Xshareclasses:none 引数を使用して、プロセスの共有クラス・オプションを使用不可にできます。 Java 2 Standard Edition (J2SE) 5 で使用可能な共有クラス・オプションにより、キャッシュでクラスを共有できます。キャッシュでクラスを共有すると、起動時間が短縮され、メモリー占有スペースを縮小できます。 アプリケーション・サーバー、ノード・エージェントおよびデプロイメント・マネージャーなどのプロセスは、この共有クラス・オプションを使用できます。

    このオプションを使用すると、プロセスを使用していない場合にキャッシュをクリアする必要があります。 キャッシュをクリアするには、app_server_root/bin/clearClassCache.bat/sh ユーティリティーを呼び出すか、プロセスを停止してからそのプロセスを再始動します。

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

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

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

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

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

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

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

Network Deployment 製品では、プロセスの開始時に、プロセスがノードの 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 に 割り振られたヒープが徐々に増加しており、ご使用のアプリケーションにメモリー・リークがあることを示している可能性があります。

また、MVS コンソール・コマンドの変更コマンドで display, jvmheap を指定し 、JVM ヒープ情報を表示することができます。 詳しくは、『変更コマンド』を参照してください。 さらに、サーバー・アクティビティーおよびインターバル SMF レコードを確認することができます。 また、JVM ヒープ・サイズは PMI に使用可能で、Tivoli Performance Viewer を使用してモニターすることができます。




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

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

最終更新: Jan 21, 2008 9:12:22 PM EST
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.zseries.doc/info/zseries/ae/urun_rconfproc_jvm.html