このページを使用して、アプリケーション・サーバーのプロセスの Java™ 仮想マシン (JVM) 構成の設定の表示および変更を行います。
この管理コンソール・ページを表示するには、管理コンソールに接続し、「Java 仮想マシン」パネルにナビゲートします。
IBM® i および分散プラットフォームの場合、「サーバー」>「サーバー・タイプ」>「Websphere アプリケーション・サーバー (WebSphere application servers)」>「server_name」とクリックします。次に「サーバー・インフラストラクチャー」セクションで、「Java およびプロセス管理」>「プロセス定義」>「Java 仮想マシン」とクリックします。
アプリケーション・サーバー | 「サーバー」>「サーバー・タイプ」>「Websphere アプリケーション・サーバー (WebSphere application servers)」>「server_name」をクリックします。次に「サーバー・インフラストラクチャー」セクションで、「Java およびプロセス管理」>「プロセス定義」>「制御」>「Java 仮想マシン」とクリックします。 |
デプロイメント・マネージャー | 「システム管理」>「デプロイメント・マネージャー」とクリックします。次に「サーバー・インフラストラクチャー」セクションで、「Java およびプロセス管理」>「プロセス定義」>「制御」>「Java 仮想マシン」とクリックします。 |
ノード・エージェント | 「システム管理」>「ノード・エージェント」>「node_agent」とクリックします。 次に「サーバー・インフラストラクチャー」セクションで、「Java およびプロセス管理」>「プロセス定義」>「Java 仮想マシン」とクリックします。 |
アプリケーション・サーバー | 「サーバー」>「サーバー・タイプ」>「Websphere アプリケーション・サーバー (WebSphere application servers)」>「server_name」。次に「サーバー・インフラストラクチャー」セクションで、「Java およびプロセス管理」>「プロセス定義」>「Java 仮想マシン」とクリックします。 |
デプロイメント・マネージャー | 「システム管理」>「デプロイメント・マネージャー」とクリックします。次に「サーバー・インフラストラクチャー」セクションで、「Java およびプロセス管理」>「プロセス定義」>「Java 仮想マシン」とクリックします。 |
ノード・エージェント | 「システム管理」>「ノード・エージェント」>「node_agent」とクリックします。 次に「サーバー・インフラストラクチャー」セクションで、「Java およびプロセス管理」>「プロセス定義」>「Java 仮想マシン」とクリックします。 |
Java 仮想マシン・コードがクラスを検索する標準クラスパスを指定します。
このフィールドにクラスパスを追加する必要がある場合は、各クラスパス・エントリーを別々のテーブル行に入力します。 各エントリーの最後にコロンまたはセミコロンを付け加える必要はありません。
データ型 | ストリング |
JVM コードのブートストラップ・クラスおよびリソースを指定します。 このオプションは、 ブートストラップ・クラスおよびリソースをサポートする JVM 命令でのみ使用可能です。
このフィールドにクラスパスを追加する必要がある場合は、各クラスパス・エントリーを 1 つのテーブル行に入力します。 各エントリーの最後にコロンまたはセミコロンを付け加える必要はありません。
このフィールドに複数のクラスパスを追加する必要がある場合は、コロン (:) またはセミコロン (;) (JVM がどのオペレーティング・システム上にあるかによって異なります) を使用して、それらのクラスパスを分離できます。
このフィールドに複数のクラスパスを追加する必要がある場合は、コロン (:) またはセミコロン (;) (ノードがどのオペレーティング・システム上にあるかによって異なります) を使用して、それらのクラスパスを分離できます。
クラス・ロードのために冗長デバッグ出力を使用するかどうかを指定します。 デフォルトでは、冗長クラス・ロードは使用可能ではありません。
冗長クラス・ロードが使用可能である場合、デバッグ出力はネイティブ・プロセス・ログのいずれかに送信されます。
データ型 | ブール値 |
デフォルト | false |
ガーベッジ・コレクションの冗長デバッグ出力を使用するかどうかを指定します。 デフォルトでは、冗長ガーベッジ・コレクションは使用可能ではありません。
冗長ガーベッジ・コレクションが使用可能である場合、デバッグ出力はネイティブ・プロセス・ログのいずれかに送信されます。
データ型 | ブール値 |
デフォルト | false |
このフィールドが使用可能な場合、ガーベッジ・コレクターが稼働するたびに、出力ストリームにレポートが書き込まれます。 このレポートは、Java ガーベッジ・コレクション・プロセスがどのように機能しているかを示しています。
83.29/3724.32 * 100 = 2.236 パーセント
ガーベッジ・コレクションに 5 パーセントを超える時間を費やし、ガーベッジ・コレクションが頻繁に発生している場合、ご使用の Java ヒープ・サイズを増やす必要がある場合があります。
割り当てられたヒープが増大しているかどうかを明らかにするには、各ガーベッジ・コレクション・サイクル後に割り当てられていないヒープのパーセンテージを調べて、そのパーセンテージが減少し続けていないことを確認します。 空きスペースのパーセンテージが減少し続ける場合、ヒープ・サイズが、ガーベッジ・コレクションの実行ごとに、だんだんと増大していることになります。 このシチュエーションは、ご使用のアプリケーションにメモリー・リークが生じていることを示しています。
z/OS プラットフォームで、MVS™ コンソール・コマンドの modify display, jvmheap を実行して、JVM ヒープ情報を表示することもできます。さらに、サーバー・アクティビティーおよびインターバル SMF レコードを確認することができます。
また、JVM ヒープ・サイズは PMI に使用可能で、Tivoli® Performance Viewer を使用してモニターすることができます。
ネイティブ・メソッドの起動のために冗長デバッグ出力を使用するかどうかを指定します。 デフォルトでは、冗長 Java ネイティブ・インターフェース (JNI) アクティビティー は使用可能に設定されていません。
データ型 | ブール値 |
デフォルト | false |
JVM コードで使用可能な初期ヒープ・サイズをメガバイト単位で指定します。このフィールドがブランクのままである場合は、デフォルト値が使用されます。
z/OS の場合、コントローラーのデフォルトの初期ヒープ・サイズは 48 MB、サーバントのデフォルトの初期ヒープ・サイズは 128 MB です。これらのデフォルト値は、31 ビットと 64 ビットの両方の構成に適用されます。
IBM i および分散プラットフォームの場合、デフォルトの初期ヒープ・サイズは 50 MB です。
この設定値を大きくすると、始動時間を短縮できます。 ガーベッジ・コレクションの実行回数が減少するため、パフォーマンスが 10 パーセント向上します。
Java ヒープ・サイズを増やすと、ヒープが物理メモリーの容量を超えるまでは、スループットが向上し続けます。ヒープ・サイズが使用可能な物理メモリー容量を超えると、ページングが発生するため、パフォーマンスが大幅に低下します。
JVM コードで使用可能な最大ヒープ・サイズをメガバイト単位で指定します。 このフィールドがブランクのままである場合は、デフォルト値が使用されます。
デフォルトの最大ヒープ・サイズは 256 MB です。 このデフォルト値は、31 ビットおよび 64 ビットの構成の両方に適用されます。
最大ヒープ・サイズの設定値を大きくすると、始動時間を短縮できます。 最大ヒープ・サイズを増やすと、ガーベッジ・コレクションの実行回数が減少し、パフォーマンスが 10 パーセント向上します。
この設定値を増やすと、通常は、ヒープが物理メモリーの容量を超えるまでは、スループットが向上します。 ヒープ・サイズが使用可能な物理メモリー容量を超えると、ページングが発生するため、パフォーマンスが大幅に低下します。 そのため、このプロパティーには、ヒープが物理メモリー内に収まる範囲の値を指定することが重要です。
ページングを防止するには、各プロセッサーごとに少なくとも 256 MB の物理メモリー、
各アプリケーション・サーバーごとに 512 MB の物理メモリーを確保する値をこのプロパティーに指定してください。
ページングのためにプロセッサー使用率が低い場合は、
可能であれば、最大ヒープ・サイズではなく、使用可能メモリーを増やします。
最大ヒープ・サイズを増やすと、パフォーマンスは向上せず、むしろ低下することがあります。
IBM i では、このプロパティーを 0 に設定すると、ガーベッジ・コレクターのしきい値に達したときのみガーベッジ・コレクターが実行されます。0
以外の値を指定した場合は、ヒープ・サイズが指定された最大サイズに達すると必ずガーベッジ・コレクターが実行されます。ただし、通常のガーベッジ・コレクターと異なり、最大サイズに達した場合には、
すべてのアプリケーション・スレッドは、実行を継続する前に、
ガーベッジ・コレクションのプロセスが終了するまで待機する必要があります。
このシチュエーションにより、望ましくない休止時間が生じることがあります。したがって、
最大ヒープ・サイズは、予期しないヒープの増大の発生を処理し、ヒープが使用可能メモリーよりも大きくならないことを確認するための安全策として使用してください。通常の環境では、指定した最大ヒープ・サイズに達することはありません。
HProf プロファイラー・サポートを使用するかどうかを指定します。別のプロファイラーを使用するには、「HProf 引数」の設定を使用してカスタム・プロファイラーの設定を指定します。 デフォルトでは、HProf プロファイラー・サポートは使用可能ではありません。
「HProf の実行」プロパティーを true に設定する場合は、「HProf 引数」プロパティーの値としてコマンド行プロファイラー引数を指定する必要があります。
データ型 | ブール値 |
デフォルト | false |
アプリケーション・サーバー・プロセスを開始する 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 コマンド行の引数 |
アプリケーション・サーバー・プロセスを始動する Java 仮想マシン・コードに渡すコマンド行引数を指定します。
同期サービスのホット・リスタート同期機能を使用可能にするには、hotRestartSync を指定します。この機能は、デプロイメント・マネージャーがアクティブでないときは構成更新が行われない環境で、 インストールが実行されている同期サービスを示しています。 したがって、サービスは、デプロイメント・マネージャーまたはノード・エージェントの再始動時に、 完全なリポジトリーの比較を行う必要はありません。 このフィーチャーを使用可能にすると、デプロイメント・マネージャーまたはノード・エージェントの再始動後に行う、最初の同期操作の効率が良くなります。特に、混合リリース・セルを含み、複数のノードを使用し、複数のアプリケーションを実行するインストールの場合には効果的です。
この引数は z/OS にのみ適用されます。 クライアントから送信された要求に応答する場合のタイムアウト期間を設定するには、-Dcom.ibm.CORBA.RequestTimeout= timeout_interval 引数を指定します。 この引数は、-D オプションを使用します。timeout_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= 引数を指定します。 この引数のサポートされる唯一の値は、com.ibm.ws.buffermgmt.impl.ZOSWsByteBufferPoolManagerImpl です。
-Dcom.ibm.ws.buffermgmt.impl.WsByteBufferPoolManagerImpl=com.ibm.ws.buffermgmt.impl.ZOSWsByteBufferPoolManagerImpl
z/OS プラットフォームでは、これらのバッファーが接続に不要になった直後、チャネルに新規接続で使用される初期読み取りバッファーを解放させるために、TCP チャネルの zaioFreeInitialBuffers カスタム・プロパティーを指定する場合にも、この引数を指定する必要があります。
SIP 準拠検査が SIP プロキシー・サーバーで有効になっているかどうかを指定します。 SIP 準拠検査により、SIP メッセージが Session Initiation Protocol 標準に準拠するようにします。 このプロパティーが true に設定されると、SIP 準拠検査が使用可能になります。
Java SE 6 の Java HotSpot Technology には、バイト・コードの実行の方法を長期にわたり最適化するアルゴリズムを含む最適な JVM が使用されています。JVM は、-server および -client の 2 つのモードで実行します。 ほとんどの場合、-server モードを使用します。これにより、長期間にわたるランタイム・パフォーマンスの効率をあげることができます。
デフォルトの -client モードを使用すると、サーバーの起動時間が短縮され、メモリー使用量が減少します。 ただし、このモードでは拡張パフォーマンスが低下します。サーバーの起動時間がパフォーマンスよりも重要でない限り、パフォーマンスを向上する -server モードを使用してください。 プロセス・サイズとサーバー起動時間をモニターすることで、-client と -server モードを使用する場合のパフォーマンスの違いを確認できます。
クラス・ロード中にクラス検証の段階をスキップするには、-Xverify:none を指定します。 -Xverify:none を使用すると Java クラス検証を使用不可にすることができ、起動時間が 10 パーセントから 15 パーセント改善されます。ただし、この引数を指定すると、破損したクラス・データや無効なクラス・データは検出されません。破損したクラス・データがロードされると、JVM が予期しない動作をして JVM に障害が起きる可能性があります。
クラス・ガーベッジ・コレクションを使用不可にするには、-Xnoclassgc を指定します。この引数により、クラスの再利用率が上がり、パフォーマンスが若干向上します。ただし、これらのクラスのリソースは、そのクラスが呼び出されていないときでも、使用中のままです。
ガーベッジ・コレクションをモニターする場合は、verbose:gc 構成設定を使用することができます。 これらのリソースの再利用によりパフォーマンスに与える影響を判別するには、結果出力を使用することができます。
-Xnoclassgc 引数を指定した場合は、アプリケーションを再デプロイするたびに、常にアプリケーション・サーバーを再始動して、前のバージョンのアプリケーションで使用したクラス・データおよび静的データを消去する必要があります。
複数のガーベッジ・コレクション・スレッドを同時に使用するには、-Xgcthreads を指定します。このガーベッジ・コレクション技術は、パラレル・ガーベッジ・コレクション として知られています。この引数は、IBM Developer Kit にのみ有効です。
この値を「汎用 JVM 引数」フィールドに入力する場合は、使用マシンで稼働中のプロセッサー数も入力してください。例えば、ご使用のマシンで 3 個のプロセッサーが稼働している場合、-Xgcthreads 3 と入力します。n 個のプロセッサーを使用するノードでは、デフォルトのスレッド数は n です。
ヒープ圧縮を使用不可にするには、-Xnocompactgc を指定します。 ヒープ圧縮は、最もコストの高いガーベッジ・コレクション操作です。 IBM Developer Kit を使用している場合は、ヒープ圧縮を使用しないでください。ヒープ圧縮を使用不可にすると、それに付随するすべてのオーバーヘッドがなくなります。
ガーベッジ・コレクション・ポリシーを設定するには、-Xgcpolicy を指定します。この引数は、IBM Developer Kit にのみ有効です。
スループットを最適化する場合には、この引数を optthruput に設定します。この設定を行うと、長期間にわたるガーベッジ・コレクションの休止が発生しても、問題は生じません。 これは、デフォルトのパラメーターで、推奨設定です。
世代的ガーベッジ・コレクターを使用する場合、この引数に gencon を設定します。 この世代的な方式では、ガーベッジ・コレクションの収集休止時間を短縮するとともに、高スループットを実現します。この目的を達成するために、ヒープは新旧のセグメントに分割されます。 存続時間が長いオブジェクトは古いスペースにプロモートされますが、存続時間が短いオブジェクトは新規スペースに格納されて短時間にガーベッジ・コレクションが実行されます。 gencon ポリシーは多くのアプリケーションに多くの利点をもたらします。ただし、すべてのアプリケーションに適するわけではなく、 一般的に、調整が難しくなります。
並行マーキングを使用して、ヒープがフルになる前に、 スタックから開始されるアプリケーション・スレッドのトラッキングを行うには、この引数を optavgpause に設定します。 このパラメーターを指定すると、ガーベッジ・コレクターの休止が定期的になり、長期間休止することはなくなります。 ただし、このポリシーを使用すると、スレッドが余分な処理を行わねばならないことによるスループットの低下が発生します。
一般に使用プロセッサー数が 8 つを超えるマルチプロセッサー・システムでパフォーマンスを向上させる場合、 この引数に subpool を設定します。 このポリシーを使用できるのは、IBM System i、System p、および System z プロセッサーのみです。subpool ポリシーは optthruput ポリシーと似ていますが、ヒープがサブプールに分割されて、オブジェクト割り振りのスケーラビリティーが改善される点が異なります。
Java Platform, Standard Edition 6 (Java SE 6) には、世代ガーベッジ・コレクションがあります。これによって、存続期間が異なるオブジェクトを、それぞれ個別のメモリー・プールに入れることができます。ガーベッジ・コレクション・サイクルでは、存続期間に応じて、相互に独立してオブジェクトを収集します。 追加パラメーターを使用することで、メモリー・プールのサイズを個々に設定できます。 より良いパフォーマンスを得るには、ライフサイクルの短いオブジェクトを含むプールのサイズを設定してください。これによって、プール内のオブジェクトが、複数のガーベッジ・コレクション・サイクルに渡って保持されることがなくなります。 NewSize および MaxNewSize パラメーターを使用して、新規世代プールのサイズを指定します。
-XX:NewSize=lower_bound -XX:MaxNewSize=upper_bound -XX:SurvivorRatio=new_ratio_size
または、総ヒープ・サイズの 50% から 60% を新世代プールに設定する必要があります。
最小フリー・ヒープ・サイズのパーセンテージを変更するには、-Xminf を指定します。 フリー・スペースが指定量よりも少ない場合、 ヒープは大きくなります。リセット可能モードで、 この引数は、ミドルウェアおよび一過性ヒープのフリー・スペースの最小割合を指定します。 この引数に指定された値は、浮動小数点数 0 から 1 です。デフォルトは .3 (30 パーセント) です。
プロセスの共有クラス・オプションを使用不可にするには、-Xshareclasses:none 引数を指定します。 Java SE 6 で使用可能な共有クラス・オプションにより、キャッシュでクラスを共有できます。キャッシュでクラスを共有すると、起動時間が短縮され、メモリー占有スペースを縮小できます。 アプリケーション・サーバー、ノード・エージェントおよびデプロイメント・マネージャーなどのプロセスは、この共有クラス・オプションを使用できます。
このオプションを使用すると、プロセスを使用していない場合にキャッシュをクリアする必要があります。 キャッシュをクリアするには、app_server_root/bin/clearClassCache.bat/sh ユーティリティーを呼び出すか、プロセスを停止してからそのプロセスを再始動します。
データ型 | ストリング |
単位 | Java コマンド行の引数 |
JVM コードで使用する実行可能な JAR ファイルの絶対パス名を指定します。
データ型 | ストリング |
単位 | パス名 |
JVM コードのジャストインタイム (JIT)・コンパイラー・オプションを使用不可にするかどうかを指定します。
JIT コンパイラーを使用不可にしている場合は、スループットが著しく減少します。したがって、 パフォーマンス上の理由から、JIT は使用可能のままにしてください。
データ型 | ブール値 |
デフォルト | false (JIT は使用可能) |
推奨 | JIT は使用可能 |
所定のオペレーティング・システムの JVM 設定を指定します。
プロセスの開始時に、プロセスはサーバーに指定されている JVM 設定をオペレーティング・システムの JVM 設定として使用します。
プロセスの開始時に、プロセスはノードに指定されている JVM 設定をオペレーティング・システムの JVM 設定として使用します。