WebSphere Application Server Version 6.1 Feature Pack for Web Services   
             オペレーティング・システム: AIX , HP-UX, i5/OS, Linux, Solaris, Windows, Windows Vista, z/OS

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

Java 仮想マシン設定

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

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

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

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

冗長 JNI

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

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

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

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

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

[i5/OS] 重要: i5/OS では、最小ヒープ・サイズは常に最大ヒープ・サイズよりも小さくなければなりません。最小ヒープ・サイズ・プロパティーと最大ヒープ・サイズ・プロパティーに決して同じ値をセットしないでください。
データ型 整数
デフォルト

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

[AIX HP-UX Linux Solaris Windows] 分散プラットフォームの場合、デフォルトは 50 です。

[i5/OS] i5/OS の場合、デフォルトは 96 です

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

最大ヒープ・サイズ

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

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

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

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

[i5/OS] i5/OS では、このプロパティーを 0 (ゼロ) に設定すると、ガーベッジ・コレクターのしきい値に達したときのみガーベッジ・コレクターが実行されます。0 以外の値を指定した場合は、ヒープ・サイズが指定された最大サイズに達すると必ずガーベッジ・コレクターが実行されます。 しかし、通常のガーベッジ・コレクターと異なり、最大サイズに達した場合には、 すべてのアプリケーション・スレッドは、実行を継続する前に、 ガーベッジ・コレクションのプロセスが終了するまで待機する必要があります。 これにより、望ましくない休止時間が生じることがあります。したがって、 最大ヒープ・サイズは、予期しないヒープの増大を処理し、ヒープが使用可能メモリーよりも大きくならないことを確認するための安全策として使用する必要があります。通常の環境では、指定した最大ヒープ・サイズに達することがあってはなりません。

データ型 整数
デフォルト

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

[AIX HP-UX Linux Solaris Windows] 分散プラットフォームの場合、デフォルトは 256 です。 ページングやメモリーからディスクへのスワップアウトを避けるために、値は小さくしておいてください。

[i5/OS] i5/OS の場合のデフォルトは 0 で、これは最大ヒープ・サイズが設定されていないことを示しています。

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

HProf の実行 [AIX HP-UX Linux Solaris Windows] [i5/OS]

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

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

データ型 ブール
デフォルト false
HProf 引数 [AIX HP-UX Linux Solaris Windows] [i5/OS]

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

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

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

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 と共に使用することはできません。
  • [AIX HP-UX Linux Solaris Windows] [z/OS] -Xquickstart

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

    [i5/OS] 重要: i5/OS はこのオプションをサポートしていません。
  • [AIX HP-UX Linux Solaris Windows] [z/OS] -Xverify:none

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

    [i5/OS] 重要: i5/OS はこのオプションをサポートしていません。
  • [AIX HP-UX Linux Solaris Windows] [z/OS] -Xnoclassgc

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

    [i5/OS] 重要: i5/OS はこのオプションをサポートしていません。 このプラットフォームでガーベッジ・コレクションを使用不可にするには、-noclassgc を使用する必要があります。
  • [AIX HP-UX Linux Solaris Windows] [z/OS] -Xgcthreads

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

    [i5/OS] 重要: i5/OS はこのオプションをサポートしていません。
  • [AIX HP-UX Linux Solaris Windows] [z/OS] -Xnocompactgc

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

    [i5/OS] 重要: i5/OS はこのオプションをサポートしていません。
  • [AIX HP-UX Linux Solaris Windows] [z/OS] -Xinitsh

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

    [i5/OS] 重要: i5/OS はこのオプションをサポートしていません。
  • [AIX HP-UX Linux Solaris Windows] [z/OS] -Xgpolicy

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

    [i5/OS] 重要: i5/OS はこのオプションをサポートしていません。
  • [AIX HP-UX Linux Solaris Windows] [z/OS] -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% に設定します。

    [i5/OS] 重要: i5/OS はこのオプションをサポートしていません。
  • [AIX HP-UX Linux Solaris Windows] [z/OS] -Xminf

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

    [i5/OS] 重要: i5/OS はこのオプションをサポートしていません。
  • [AIX HP-UX Linux Solaris Windows] [z/OS] -server | -client

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

    [i5/OS] 重要: i5/OS はこのオプションをサポートしていません。
  • [z/OS] -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] z/OS プラットフォームでは、これらのバッファーが接続に不要になった直後、 チャネルが新規接続で使用される初期読み取りバッファーを解放する必要があることを示すために、TCP チャネルの zaioFreeInitialBuffers カスタム・プロパティー を使用する場合にも、この引数を指定する必要があります。

  • [AIX HP-UX Linux Solaris Windows] [z/OS] -Xshareclasses:none

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

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

    [Solaris] [i5/OS] [HP-UX] 重要: IBM J2SE 5 は、現在 Solaris、HP、および i5/OS では使用されていません。
データ型 ストリング
単位 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 に 割り振られたヒープが徐々に増加しており、ご使用のアプリケーションにメモリー・リークがあることを示している可能性があります。

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




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

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

最終更新: Jan 21, 2008 4:10:06 PM EST
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.wsfep.multiplatform.doc/info/ae/ae/urun_rconfproc_jvm.html