Java 仮想マシン設定

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

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

[AIX Solaris HP-UX Linux Windows] [iSeries] i5/OS および分散プラットフォームの場合、「サーバー」 > 「サーバー・タイプ」 > 「Websphere アプリケーション・サーバー (WebSphere application servers)」>「server_name」とクリックします。次に「サーバー・インフラストラクチャー」セクションで、 「Java およびプロセス管理」 > 「プロセス定義」 > 「Java 仮想マシン」 とクリックします。

[z/OS] z/OS プラットフォームの場合、以下のパスの 1 つに従います。
アプリケーション・サーバー 「サーバー」 > 「サーバー・タイプ」 > 「Websphere アプリケーション・サーバー (WebSphere application servers)」>「server_name」をクリックします。次に「サーバー・インフラストラクチャー」セクションで、 「Java およびプロセス管理 」>「プロセス定義 」>「制御 」>「Java 仮想マシン 」とクリックします。
デプロイメント・マネージャー システム管理」>「デプロイメント・マネージャー」とクリックします。次に「サーバー・インフラストラクチャー」セクションで、 「Java およびプロセス管理 」>「プロセス定義 」>「制御 」>「Java 仮想マシン 」とクリックします。
ノード・エージェント システム管理」>「ノード・エージェント」>「node_agent」とクリックします。 次に「サーバー・インフラストラクチャー」セクションで、 「Java およびプロセス管理」 > 「プロセス定義」 > 「Java 仮想マシン」 とクリックします。
[AIX Solaris HP-UX Linux Windows] [iSeries] i5/OS および分散プラットフォームの場合、以下のパスの 1 つに従います。
アプリケーション・サーバー 「サーバー」 > 「サーバー・タイプ」 > 「Websphere アプリケーション・サーバー (WebSphere application servers)」>「server_name」をクリックします。次に「サーバー・インフラストラクチャー」セクションで、 「Java およびプロセス管理」 > 「プロセス定義」 > 「Java 仮想マシン」 とクリックします。
デプロイメント・マネージャー システム管理」>「デプロイメント・マネージャー」とクリックします。次に「サーバー・インフラストラクチャー」セクションで、 「Java およびプロセス管理」 > 「プロセス定義」 > 「Java 仮想マシン」 とクリックします。
ノード・エージェント システム管理」>「ノード・エージェント」>「node_agent」とクリックします。 次に「サーバー・インフラストラクチャー」セクションで、 「Java およびプロセス管理」 > 「プロセス定義」 > 「Java 仮想マシン」 とクリックします。

「構成」タブ

クラスパス

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

このフィールドにクラスパスを追加する必要がある場合は、各クラスパス・エントリーを別々のテーブル行に入力します。 各エントリーの最後にコロンまたはセミコロンを付け加える必要はありません。

このフィールドに追加する必要のあるクラスパスは、以下の項目のロケーションを指定するクラスパスのみです。
  • システムに対する検査ツールまたはモニター・ツール。
  • この製品上で実行される製品の JAR ファイル。
  • JVM の診断パッチまたはフィックス。
以下の項目のロケーションを指定するこのフィールドにクラスパスを追加すると、処理エラーが発生する場合があります。
  • DB2 などのリソース・プロバイダーの JAR ファイル。 これらの JAR ファイルのパスは、関連するプロバイダーのクラスパスに追加する必要があります。
  • 本製品で実行する 1 つ以上のアプリケーションで使用するユーザー JAR ファイル。 このタイプの JAR ファイルのパスは、その JAR ファイルを必要とする各アプリケーション内で指定するか、サーバーに関連付けられている共用ライブラリーで指定する必要があります。
  • 拡張 JAR ファイル。 システムに拡張 JAR ファイルを追加する必要がある場合は、ws.ext.dirs という JVM カスタム・プロパティーを使用して、この JAR ファイルの絶対パスを指定する必要があります。 この JAR ファイルは WAS_HOME/lib/ext/ ディレクトリーに置くこともできますが、拡張 JAR ファイルのパスの指定には、ws.ext.dirs という JVM カスタム・プロパティーを使用する方法をお勧めします。
データ型 ストリング
ブート・クラスパス

JVM コードのブートストラップ・クラスおよびリソースを指定します。 このオプションは、 ブートストラップ・クラスおよびリソースをサポートする JVM 命令でのみ使用可能です。

このフィールドにクラスパスを追加する必要がある場合は、各クラスパス・エントリーを 1 つのテーブル行に入力します。 各エントリーの最後にコロンまたはセミコロンを付け加える必要はありません。

このフィールドに複数のクラスパスを追加する必要がある場合は、コロン (:) またはセミコロン (;) (JVM がどのオペレーティング・システム上にあるかによって異なります) を使用して、それらのクラスパスを分離できます。

このフィールドに複数のクラスパスを追加する必要がある場合は、コロン (:) またはセミコロン (;) (ノードがどのオペレーティング・システム上にあるかによって異なります) を使用して、それらのクラスパスを分離できます。

このフィールドに追加する必要のあるクラスパスは、以下の項目のロケーションを指定するクラスパスのみです。
  • システムに対する検査ツールまたはモニター・ツール。
  • この製品上で実行される製品の JAR ファイル。
  • JVM の診断パッチまたはフィックス。
以下の項目のロケーションを指定するこのフィールドにクラスパスを追加すると、処理エラーが発生する場合があります。
  • DB2 などのリソース・プロバイダーの JAR ファイル。 これらの JAR ファイルのパスは、関連するプロバイダーのクラスパスに追加する必要があります。
  • 本製品で実行する 1 つ以上のアプリケーションで使用するユーザー JAR ファイル。 このタイプの JAR ファイルのパスは、その JAR ファイルを必要とする各アプリケーション内で指定するか、サーバーに関連付けられている共用ライブラリーで指定する必要があります。
  • 拡張 JAR ファイル。 システムに拡張 JAR ファイルを追加する必要がある場合は、ws.ext.dirs という JVM カスタム・プロパティーを使用して、この JAR ファイルの絶対パスを指定する必要があります。 この JAR ファイルは WAS_HOME/lib/ext/ ディレクトリーに置くこともできますが、拡張 JAR ファイルのパスの指定には、ws.ext.dirs という JVM カスタム・プロパティーを使用する方法をお勧めします。
冗長クラス・ロード

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

[AIX Solaris HP-UX Linux Windows] 冗長クラス・ロードが使用可能である場合、デバッグ出力はネイティブ・プロセス・ログのいずれかに送信されます。

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

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

[AIX Solaris HP-UX Linux Windows] 冗長ガーベッジ・コレクションが使用可能である場合、デバッグ出力はネイティブ・プロセス・ログのいずれかに送信されます。

,

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

このフィールドが使用可能な場合、ガーベッジ・コレクターが稼働するたびに、出力ストリームにレポートが書き込まれます。 このレポートは、Java ガーベッジ・コレクション・プロセスがどのように機能しているかを示しています。

verboseGC レポートを確認して以下を明らかにすることができます。
  • ガーベッジ・コレクションを実行するのに JVM が費やす時間。
    JVM が費やす時間は、ガーベッジ・コレクションを実行するそのプロセス時間の 5 パーセント未満であることが理想的です。 JVM がガーベッジ・コレクションに費やしている時間のパーセンテージを明らかにするには、コレクションを完了するまでにかかった時間を 最後の AF 以降の時間で割り、その結果に 100 を掛けます。以下に例を示します。
    83.29/3724.32 * 100 = 2.236 パーセント
    
    

    ガーベッジ・コレクションに 5 パーセントを超える時間を費やし、ガーベッジ・コレクションが頻繁に発生している場合、 ご使用の Java ヒープ・サイズを増やす必要がある場合があります。

  • 割り当てられたヒープが、ガーベッジ・コレクションの実行により増大している場合。

    割り当てられたヒープが増大しているかどうかを明らかにするには、各ガーベッジ・コレクション・サイクル後に割り当てられていないヒープのパーセンテージを調べて、そのパーセンテージが減少し続けていないことを確認します。 空きスペースのパーセンテージが減少し続ける場合、ヒープ・サイズが、ガーベッジ・コレクションの実行ごとに、だんだんと増大していることになります。 このシチュエーションは、ご使用のアプリケーションにメモリー・リークが生じていることを示しています。

[z/OS] z/OS プラットフォームで、MVS コンソール・コマンドの modify display, jvmheap を実行して、JVM ヒープ情報を表示することもできます。 さらに、サーバー・アクティビティーおよびインターバル SMF レコードを確認することができます。 また、JVM ヒープ・サイズは PMI に使用可能で、Tivoli Performance Viewer を使用してモニターすることができます。

冗長 JNI

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

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

JVM コードで使用可能な初期ヒープ・サイズをメガバイト単位で指定します。 このフィールドがブランクのままである場合は、デフォルト値が使用されます。

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

[AIX Solaris HP-UX Linux Windows] [iSeries] i5/OS および分散プラットフォームの場合、デフォルトの初期ヒープ・サイズは 50 MB です。

ベスト・プラクティス: ほとんどのアプリケーションでは、これらのデフォルト値で十分対応することができます。bprac
[iSeries] トラブルの回避: i5/OS の場合、初期ヒープ・サイズは常に最大ヒープ・サイズよりも小さくなければなりません。 初期ヒープ・サイズ・プロパティーと最大ヒープ・サイズ・プロパティーに同じ値を設定しないようにしてください。 gotcha

この設定値を大きくすると、始動時間を短縮できます。 ガーベッジ・コレクションの実行回数が減少するため、パフォーマンスが 10 パーセント向上します。

Java ヒープ・サイズを増やすと、ヒープが物理メモリーの容量を超えるまでは、スループットが向上し続けます。 ヒープ・サイズが使用可能な物理メモリー容量を超えると、ページングが発生するため、パフォーマンスが大幅に低下します。

最大ヒープ・サイズ

JVM コードで使用可能な最大ヒープ・サイズをメガバイト単位で指定します。 このフィールドがブランクのままである場合は、デフォルト値が使用されます。

[z/OS] z/OS の場合、デフォルトの最大ヒープ・サイズは 256 MB です。このデフォルト値は、31 ビットおよび 64 ビットの構成の両方に適用されます。

最大ヒープ・サイズの設定値を大きくすると、始動時間を短縮できます。 最大ヒープ・サイズを増やすと、ガーベッジ・コレクションの実行回数が減少し、パフォーマンスが 10 パーセント向上します。

この設定値を増やすと、通常は、ヒープが物理メモリーの容量を超えるまでは、スループットが向上します。 ヒープ・サイズが使用可能な物理メモリー容量を超えると、ページングが発生するため、パフォーマンスが大幅に低下します。 そのため、このプロパティーには、ヒープが物理メモリー内に収まる範囲の値を指定することが重要です。

[z/OS] ページングを防止するには、各プロセッサーごとに少なくとも 256 MB の物理メモリー、 各アプリケーション・サーバーごとに 512 MB の物理メモリーを確保する値をこのプロパティーに指定してください。 ページングのためにプロセッサー使用率が低い場合は、 可能であれば、最大ヒープ・サイズではなく、使用可能メモリーを増やします。 最大ヒープ・サイズを増やすと、パフォーマンスは向上せず、むしろ低下することがあります。

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

ベスト・プラクティス: ほとんどのアプリケーションでは、これらのデフォルト値が適切な値です。ガーベッジ・コレクションが頻繁に発生しすぎていると思われる場合は、「冗長ガーベッジ・コレクション」プロパティーを使用可能にしてください。 ガーベッジ・コレクションが頻繁に発生しすぎる場合は、JVM ヒープの最大サイズを増やしてください。 bprac
HProf の実行 [AIX Solaris HP-UX Linux Windows] [iSeries]

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

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

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

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

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

デバッグ・モード

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

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

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

アプリケーション・サーバー・プロセスを開始する JVM コードに渡すコマンド行デバッグ引数を指定します。 「デバッグ・モード」プロパティーが true に設定されている場合には、 引数を指定できます。

同じノードの複数のアプリケーション・サーバーでデバッグを使用可能にする場合は、同じ値が address 引数に対して指定されていないことを確認してください。address 引数は、デバッグに使用するポートを定義します。 デバッグが使用可能な 2 つのサーバーを、同じデバッグ・ポートを使用するために構成する場合、サーバーが正常に開始しないことがあります。 例えば、両方のサーバーが、デバッグ引数 address=7777 で構成されている場合などです。この引数は デバッグ address 引数のデフォルト値です。

複数のアプリケーション・サーバーでデバッグを使用可能にする場合は、同じ値が address 引数に対して指定されていないことを確認してください。address 引数は、デバッグに使用するポートを定義します。 デバッグが使用可能な 2 つのサーバーを、同じデバッグ・ポートを使用するために構成する場合、サーバーが正常に開始しないことがあります。 例えば、両方のサーバーが、デバッグ引数 address=7777 で構成されている場合などです。この引数は デバッグ address 引数のデフォルト値です。

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

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

汎用 JVM 引数」フィールドで、以下のコマンド行引数 (オプション) を入力することができます。 複数の引数を入力する場合は、各引数の間にスペースを入力します。
トラブルの回避: 引数が IBM Developer Kit のみを指定している場合には、この引数を Microsoft または Hewlett-Packard などの別のプロバイダーからの JVM と共に使用することはできません。gotcha
  • [z/OS] [AIX Solaris HP-UX Linux Windows] hotRestartSync:

    同期サービスのホット・リスタート同期機能を使用可能にするには、hotRestartSync を指定します。この機能は、デプロイメント・マネージャーがアクティブでないときは構成更新が行われない環境で、 インストールが実行されている同期サービスを示しています。 したがって、サービスは、デプロイメント・マネージャーまたはノード・エージェントの再始動時に、 完全なリポジトリーの比較を行う必要はありません。 このフィーチャーを使用可能にすると、デプロイメント・マネージャーまたはノード・エージェントの再始動後に行う、最初の同期操作の効率が良くなります。特に、混合リリース・セルを含み、複数のノードを使用し、複数のアプリケーションを実行するインストールの場合には効果的です。

  • [AIX Solaris HP-UX Linux Windows] [z/OS] -Xquickstart
    デフォルト・モードの場合よりも低い最適化レベルで初期コンパイルを実行するには、-Xquickstart を指定します。後で抽出結果に応じて、 デフォルト・モードでの初期コンパイル・レベルに再コンパイルすることができます。
    ベスト・プラクティス: -Xquickstart は、 長時間に渡るスループットよりも、初期段階での適度な速度が重要とされるアプリケーションに使用します。 一部のデバッグ・シナリオ、一連のテスト、および実行時間の短いツールなどでは、起動時間を 15 - 20 パーセント程度改善させることが可能です。 bprac
    [iSeries] トラブルの回避: i5/OS はこの引数をサポートしていません。gotcha
  • [AIX Solaris HP-UX Linux Windows] [z/OS] -Xverify:none

    クラス・ロード中にクラス検証の段階をスキップするには、-Xverify:none を指定します。 -Xverify:none を使用すると Java クラス検証 を使用不可にすることができ、起動時間が 10 パーセントから 15 パーセント改善されます。ただし、この引数を指定すると、破損したクラス・データや無効なクラス・データは検出されません。破損したクラス・データがロードされると、JVM が予期しない動作をして JVM に障害が起きる可能性があります。

    トラブルの回避:
    • 計測エラーが発生すると JVM で障害が起きる可能性があるため、バイトコード変更の実行中はこの引数を使用しないでください。
    • この引数の使用中に JVM 障害が発生するか、 または JVM が予期しない動作をする場合は、JVM の問題をデバッグする第一段階としてこの引数を除去します。
    • [iSeries] i5/OS はこの引数をサポートしていません。
    gotcha
  • [AIX Solaris HP-UX Linux Windows] [z/OS] -Xnoclassgc

    クラス・ガーベッジ・コレクションを使用不可にするには、-Xnoclassgc を指定します。この引数により、クラスの再利用率が上がり、パフォーマンスが若干向上します。ただし、これらのクラスのリソースは、そのクラスが呼び出されていないときでも、使用中のままです。 ガーベッジ・コレクションをモニターする場合は、verbose:gc 構成設定を使用することができます。 これらのリソースの再利用によりパフォーマンスに与える影響を判別するには、結果出力を使用することができます。 同一のクラスのセットのガーベッジ・コレクションが繰り返し行われる場合には、クラス・ガーベッジ・コレクションを使用不可にしてください。 デフォルトで、このクラス・ガーベッジ・コレクションは使用可能になっています。

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

    複数のガーベッジ・コレクション・スレッドを同時に使用するには、-Xgcthreads を指定します。このガーベッジ・コレクション技術は、パラレル・ガーベッジ・コレクション として知られています。この引数は、IBM Developer Kit にのみ有効です。

    この値を「汎用 JVM 引数」フィールドに入力する場合は、使用マシンで稼働中のプロセッサー数も入力してください。例えば、ご使用のマシンで 3 個のプロセッサーが稼働している場合、-Xgcthreads 3 と入力します。n 個のプロセッサーを使用するノードでは、デフォルトのスレッド数は n です。

    ベスト・プラクティス: 使用マシンに複数のプロセッサーが搭載されている場合は、 並列ガーベッジ・コレクションを使用する必要があります。 bprac
    [iSeries] トラブルの回避: i5/OS はこの引数をサポートしていません。gotcha
  • [AIX Solaris HP-UX Linux Windows] [z/OS] -Xnocompactgc

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

    [iSeries] トラブルの回避: i5/OS はこの引数をサポートしていません。gotcha
  • [AIX Solaris HP-UX Linux Windows] [z/OS] -Xgpolicy

    ガーベッジ・コレクション・ポリシーを設定するには、-Xgpolicy を指定します。 この引数は、IBM Developer Kit にのみ有効です。

    並行マーキングを使用して、ヒープがフルになる前に、 スタックから開始されるアプリケーション・スレッドのトラッキングを行うには、この引数を optavgpause に設定します。 このパラメーターを指定すると、ガーベッジ・コレクターの休止が定期的になり、長期間休止することはなくなります。 ただし、このポリシーを使用すると、スレッドが余分な処理を行わねばならないことによるスループットの低下が発生します。

    スループットを最適化する場合には、この引数を optthruput に設定します。この設定を行うと、長期間にわたるガーベッジ・コレクションの休止が発生しても、問題は生じません。 これは、デフォルトのパラメーターで、推奨設定です。

    [iSeries] トラブルの回避: i5/OS はこの引数をサポートしていません。gotcha
  • [AIX Solaris HP-UX Linux Windows] [z/OS] -XX

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

    最初のガーベッジ・コレクション・サイクルを存続したオブジェクトは、他のプールに転送されます。 SurvivorRatio パラメーターを使用して、存続プール SurvivorRatio のサイズを指定します。Tivoli Performance Viewer が収集するオブジェクト統計を使用することができます。また、構成設定内に verbose:gc 引数を組み込んで、ガーベッジ・コレクション統計をモニターすることができます。 ガーベッジ・コレクションがボトルネックになった場合には、以下の引数を指定して、世代プールの設定値を使用環境により適合するようにカスタマイズしてください。
    -XX:NewSize=lower_bound
    -XX:MaxNewSize=upper_bound
     -XX:SurvivorRatio=new_ratio_size 
    ベスト・プラクティス: これらの引数のデフォルト値は NewSize=2m MaxNewSize=32m SurvivorRatio=2 です。ただし、JVM が、1 GB を超えるヒープ・サイズで構成されている場合には、次の値 -XX:newSize=640m -XX:MaxNewSize=640m -XX:SurvivorRatio=16 を使用するか、新規世代プールに対してトータル・ヒープ・サイズを 50 パーセントから 60 パーセントに設定します。 bprac
    [iSeries] トラブルの回避: i5/OS はこの引数をサポートしていません。gotcha
  • [AIX Solaris HP-UX Linux Windows] [z/OS] -Xminf

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

    [iSeries] トラブルの回避: i5/OS はこの引数をサポートしていません。gotcha
  • [AIX Solaris HP-UX Linux Windows] [z/OS] -server | -client

    Java SE 6 の Java HotSpot Technology には、 バイト・コードの実行の方法を長期にわたり最適化するアルゴリズムを含む最適な JVM が使用されています。 JVM は、-server および -client の 2 つのモードで実行します。 ほとんどの場合、-server モードを使用します。これにより、長期間にわたるランタイム・パフォーマンスの効率をあげることができます。

    デフォルトの -client モードを使用すると、サーバーの起動時間が短縮され、メモリー使用量が減少します。 ただし、このモードでは拡張パフォーマンスが低下します。サーバーの起動時間がパフォーマンスよりも重要でない限り、パフォーマンスを向上する -server モードを使用してください。 プロセス・サイズとサーバー起動時間をモニターすることで、-client-server モードを使用する場合のパフォーマンスの違いを確認できます。

    [iSeries] トラブルの回避: i5/OS はこの引数をサポートしていません。gotcha
  • -Dcom.ibm.CORBA.RequestTimeout=timeout_interval

    この引数は z/OS にのみ適用します。 クライアントから送信された要求に応答する場合のタイムアウト期間を設定するには、-Dcom.ibm.CORBA.RequestTimeout= timeout_interval 引数を指定します。 この引数は、-D オプションを使用します。timeout_interval は秒単位のタイムアウト期間です。 ネットワークで極端な待ち時間が発生している場合は、タイムアウトを防ぐために大きい値を指定します。 指定した値が小さ過ぎると、 ワークロード管理に関与するアプリケーション・サーバーが応答を受け取る前にタイムアウトになる可能性があります。

    この引数を指定するのは、ユーザーのアプリケーションでタイムアウトの問題が発生しているときのみにしてください。 この引数に推奨値はありません。

  • -Dcom.ibm.websphere.wlm.unusable.interval=interval

    この引数は z/OS にのみ適用します。 クライアントのワークロード管理状態のリフレッシュが早過ぎたり遅過ぎたりするときに com.ibm.websphere.wlm.unusable.interval プロパティーの値を変更するには、-Dcom.ibm.websphere.wlm.unusable.interval= timeout_interval 引数を指定します。 このプロパティーは、ワークロード管理クライアント・ランタイムが、サーバーを使用不可とマークしてから、 再びそのサーバーに連絡しようとするまで待機する時間 (秒) を指定します。この引数は、-D オプションを使用します。. デフォルト値は、300 秒です。このプロパティーが大きい値に設定されると、 サーバーは長時間使用不可であるとマークされます。 これで、ワークロード管理リフレッシュ・プロトコルが、 この時間枠が終了するまではクライアントのワークロード管理状態をリフレッシュ しないようになります。

  • [z/OS] -Dcom.ibm.ws.buffermgmt.impl.WsByteBufferPoolManagerImpl=

    この引数は z/OS にのみ適用します。 バッファーが不要になった直後に、個々の直接バイト・バッファーのストレージを解放することを示すには、-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 Solaris HP-UX Linux Windows] [z/OS] -Xshareclasses:none

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

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

    トラブルの回避:
    • [Solaris] [iSeries] [HP-UX] IBM JVM for J2SE 5 は、Solaris、HP、および i5/OS ではサポートされていません。
    • アプリケーション・サーバーのプロセスで稼働中の J2EE アプリケーション・クラスは、共有クラス・キャッシュには追加されません。
    gotcha
データ型 ストリング
単位 Java コマンド行の引数
実行可能 JAR ファイル名

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

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

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

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

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

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

プロセスの開始時に、プロセスはサーバーに指定されている JVM 設定をオペレーティング・システムの JVM 設定として使用します。

プロセスの開始時に、プロセスはノードに指定されている JVM 設定をオペレーティング・システムの JVM 設定として使用します。

「ランタイム」タブ

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

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

[AIX Solaris HP-UX Linux Windows] 冗長ガーベッジ・コレクションが使用可能である場合、デバッグ出力はネイティブ・プロセス・ログのいずれかに送信されます。

,

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

このフィールドが使用可能な場合、ガーベッジ・コレクターが稼働するたびに、出力ストリームにレポートが書き込まれます。 このレポートは、Java ガーベッジ・コレクション・プロセスがどのように機能しているかを示しています。

verboseGC レポートを確認して以下を明らかにすることができます。
  • ガーベッジ・コレクションを実行するのに JVM が費やす時間。
    JVM が費やす時間は、ガーベッジ・コレクションを実行するそのプロセス時間の 5 パーセント未満であることが理想的です。 JVM がガーベッジ・コレクションに費やしている時間のパーセンテージを明らかにするには、コレクションを完了するまでにかかった時間を 最後の AF 以降の時間で割り、その結果に 100 を掛けます。以下に例を示します。
    83.29/3724.32 * 100 = 2.236 パーセント
    
    

    ガーベッジ・コレクションに 5 パーセントを超える時間を費やし、ガーベッジ・コレクションが頻繁に発生している場合、 ご使用の Java ヒープ・サイズを増やす必要がある場合があります。

  • 割り当てられたヒープが、ガーベッジ・コレクションの実行により増大している場合。

    割り当てられたヒープが増大しているかどうかを明らかにするには、各ガーベッジ・コレクション・サイクル後に割り当てられていないヒープのパーセンテージを調べて、そのパーセンテージが減少し続けていないことを確認します。 空きスペースのパーセンテージが減少し続ける場合、ヒープ・サイズが、ガーベッジ・コレクションの実行ごとに、だんだんと増大していることになります。 このシチュエーションは、ご使用のアプリケーションにメモリー・リークが生じていることを示しています。

[z/OS] z/OS プラットフォームで、MVS コンソール・コマンドの modify display, jvmheap を実行して、JVM ヒープ情報を表示することもできます。 さらに、サーバー・アクティビティーおよびインターバル SMF レコードを確認することができます。 また、JVM ヒープ・サイズは PMI に使用可能で、Tivoli Performance Viewer を使用してモニターすることができます。




マーク付きのリンク (オンライン) では、インターネットにアクセスする必要があります。

関連タスク
関連資料
カスタム・プロパティー・コレクション
[AIX Solaris HP-UX Linux Windows]


ファイル名: urun_rconfproc_jvm.html