Java 仮想マシンの設定
このページを使用して、アプリケーション・サーバーのプロセスの Java™ 仮想マシン (JVM) 構成設定の表示および変更を行います。
この管理コンソール・ページを表示するには、管理コンソールに接続して「Java 仮想マシン」パネルにナビゲートします。
![[z/OS]](../images/ngzos.gif)
通知 | 値 |
---|---|
アプリケーション・サーバー | をクリックします。次に「サーバー・インフラストラクチャー」セクションで、 をクリックします。 |
デプロイメント・マネージャー | をクリックします。次に「サーバー・インフラストラクチャー」セクションで、 をクリックします。 |
ノード・エージェント | とクリックします。次に「サーバー・インフラストラクチャー」セクションで、 をクリックします。 |
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
![[IBM i]](../images/iseries.gif)
通知 | 値 |
---|---|
アプリケーション・サーバー | 。次に「サーバー・インフラストラクチャー」セクションで、 をクリックします。 |
デプロイメント・マネージャー | 。次に「サーバー・インフラストラクチャー」セクションで、 をクリックします。 |
ノード・エージェント | 。 次に「サーバー・インフラストラクチャー」セクションで、 をクリックします。 |
クラスパス
Java 仮想マシン・コードがクラスを検索する標準クラスパスを指定します。
このフィールドにクラスパスを追加する必要がある場合は、各クラスパス・エントリーを別々のテーブル行に入力します。各エントリーの最後にコロンまたはセミコロンを付け加える必要はありません。
- システムに対する検査ツールまたはモニター・ツール。
- この製品上で実行される製品の JAR ファイル。
- JVM の診断パッチまたはフィックス。
- DB2® などのリソース・プロバイダーの JAR ファイル。 これらの JAR ファイルのパスは、関連するプロバイダーのクラスパスに追加する必要があります。
- 本製品で実行する 1 つ以上のアプリケーションに使用されるユーザー JAR ファイル。このタイプの JAR ファイルのパスは、その JAR ファイルを必要とする各アプリケーション内で指定するか、サーバーに関連付けられている共有ライブラリーで指定する必要があります。
- 拡張 JAR ファイル。システムに拡張 JAR ファイルを追加する必要がある場合は、ws.ext.dirs という JVM カスタム・プロパティーを使用して、この JAR ファイルの絶対パスを指定する必要があります。この JAR ファイルは WAS_HOME/lib/ext/ ディレクトリーに置くこともできますが、拡張 JAR ファイルのパスの指定には、JVM カスタム・プロパティー ws.ext.dirs を使用する方法をお勧めします。
通知 | 値 |
---|---|
データ型 | ストリング |
ブート・クラスパス
JVM コードのブートストラップ・クラスおよびリソースを指定します。 このオプションは、 ブートストラップ・クラスおよびリソースをサポートする JVM 命令でのみ使用可能です。
このフィールドにクラスパスを追加する必要がある場合は、各クラスパス・エントリーを 1 つのテーブル行に入力します。各エントリーの最後にコロンまたはセミコロンを付け加える必要はありません。
このフィールドに複数のクラスパスを追加する必要がある場合は、コロン (:) またはセミコロン (;) (ノードがどのオペレーティング・システム上にあるかによって異なります) を使用して、それらのクラスパスを分離できます。
- システムに対する検査ツールまたはモニター・ツール。
- この製品上で実行される製品の JAR ファイル。
- JVM の診断パッチまたはフィックス。
- DB2 などのリソース・プロバイダーの JAR ファイル。 これらの JAR ファイルのパスは、関連するプロバイダーのクラスパスに追加する必要があります。
- 本製品で実行する 1 つ以上のアプリケーションに使用されるユーザー JAR ファイル。このタイプの JAR ファイルのパスは、その JAR ファイルを必要とする各アプリケーション内で指定するか、サーバーに関連付けられている共有ライブラリーで指定する必要があります。
- 拡張 JAR ファイル。システムに拡張 JAR ファイルを追加する必要がある場合は、ws.ext.dirs という JVM カスタム・プロパティーを使用して、この JAR ファイルの絶対パスを指定する必要があります。この JAR ファイルは WAS_HOME/lib/ext/ ディレクトリーに置くこともできますが、拡張 JAR ファイルのパスの指定には、JVM カスタム・プロパティー ws.ext.dirs を使用する方法をお勧めします。
冗長クラス・ロード
クラス・ロードのために冗長デバッグ出力を使用するかどうかを指定します。 デフォルトでは、冗長クラス・ロードは使用不可です。
冗長クラス・ロードが使用可能な場合、デバッグ出力はネイティブ・プロセス・ログのいずれかに送信されます。
通知 | 値 |
---|---|
データ型 | ブール |
デフォルト | false |
冗長ガーベッジ・コレクション
ガーベッジ・コレクションの冗長デバッグ出力を使用するかどうかを指定します。 デフォルトでは、冗長ガーベッジ・コレクションは使用可能ではありません。
冗長ガーベッジ・コレクションが使用可能な場合、デバッグ出力はネイティブ・プロセス・ログのいずれかに送信されます。
通知 | 値 |
---|---|
データ型 | ブール |
デフォルト | false |
このフィールドが使用可能な場合、ガーベッジ・コレクターが稼働するたびに、出力ストリームにレポートが書き込まれます。 このレポートでは、Java ガーベッジ・コレクション・プロセスが機能する様子が示されます。
- JVM がガーベッジ・コレクションを実行するのにかかる時間。JVM が費やす時間は、ガーベッジ・コレクションを実行するそのプロセス時間の 5 パーセント未満であることが理想的です。 JVM がガーベッジ・コレクションに費やしている時間のパーセンテージを判別するには、コレクションを完了するのに要した時間を最後の AF 以降の時間で割り、その結果に 100 を掛けます。 以下に例を示します。
83.29/3724.32 * 100 = 2.236%
ガーベッジ・コレクションに 5% を超える時間を費やし、ガーベッジ・コレクションが頻繁に発生している場合は、 Java ヒープ・サイズを増やす必要があります。
- 割り振られたヒープが、各ガーベッジ・コレクションの発生とともに増大しているかどうか。
割り当てられたヒープが増大しているかどうかを判別するには、各ガーベッジ・コレクション・サイクルの後に未割り当て状態のまま残っているヒープのパーセンテージを調べて、そのパーセンテージが減少し続けていないことを確認します。 フリー・スペースの パーセンテージが減少し続けている場合は、ガーベッジ・コレクション間のヒープ・サイズが徐々に増大しています。この状態は、アプリケーションにメモリー・リークが発生していることを示している可能性があります。
z/OS® プラットフォーム上では、MVS™ コンソール・コマンド modify display, jvmheap を発行して、JVM ヒープ情報を表示することもできます。
さらに、サーバー・アクティビティーおよびインターバル SMF レコードを確認することができます。
また、JVM ヒープ・サイズは PMI に使用可能で、Tivoli® Performance Viewer を使用してモニターすることができます。
冗長 JNI
ネイティブ・メソッドの起動のために冗長デバッグ出力を使用するかどうかを指定します。 デフォルトでは、冗長 Java ネイティブ・インターフェース (JNI) アクティビティー は使用可能に設定されていません。
通知 | 値 |
---|---|
データ型 | ブール |
デフォルト | false |
初期ヒープ・サイズ
JVM コードで使用可能な初期ヒープ・サイズ (メガバイト単位) を指定します。 このフィールドがブランクのままである場合は、デフォルト値が使用されます。
z/OS の場合、コントローラーのデフォルトの初期ヒープ・サイズは 256 MB で、サーバントのデフォルトの初期ヒープ・サイズは 512 MB です。
IBM® i および分散プラットフォームの場合、デフォルトの初期ヒープ・サイズは 50 MB です。


この設定を増やすと、始動時間が短縮されます。ガーベッジ・コレクションの実行回数が減少するため、パフォーマンスが 10 パーセント向上します。
Java ヒープ・サイズを増やすと、ヒープが物理メモリーの容量を超えるまでは、スループットが向上します。 ヒープ・サイズが使用可能な物理メモリー量を超えて、ページングが発生すると、パフォーマンスが著しく低下します。
最大ヒープ・サイズ
JVM コードで使用可能な最大ヒープ・サイズ (メガバイト単位) を指定します。 このフィールドがブランクのままである場合は、デフォルト値が使用されます。
デフォルトの最大ヒープ・サイズはシステム・メモリー合計量の 25% (最大 4 GB) です。メモリー・サイズにアクセスできない場合は JVM のデフォルトが使用されます。
最大ヒープ・サイズの設定を増やすと、始動時間が短縮されます。最大ヒープ・サイズを増やすと、ガーベッジ・コレクションの実行回数が減少し、パフォーマンスが 10 パーセント向上します。
この設定値を増やすと、通常は、ヒープが物理メモリーの容量を超えるまでは、スループットが向上します。ヒープ・サイズが使用可能な物理メモリー量を超えて、ページングが発生すると、パフォーマンスが著しく低下します。そのため、このプロパティーには、ヒープが物理メモリー内に収まる範囲の値を指定することが重要です。
z/OS の場合、コントローラーのデフォルトの最大ヒープ・サイズは 512 MB で、サーバントのデフォルトの初期ヒープ・サイズは 1024 MB です。
ページングを防止するには、このプロパティーに対してプロセッサーごとに最低 256 MB の物理メモリー、および
アプリケーション・サーバーごとに 512 MB の物理メモリーを確保する値を指定します。
ページングのためにプロセッサー使用率が低い場合は、
可能であれば、最大ヒープ・サイズではなく、使用可能メモリーを増やします。
最大ヒープ・サイズが増えると、パフォーマンスは向上せずに低下する可能性があります。

![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
![[IBM i]](../images/iseries.gif)
HProf の実行
HProf プロファイラー・サポートを使用するかどうかを指定します。別のプロファイラーを使用するには、 「HProf 引数」設定を使用してカスタム・プロファイラーの設定を指定します。 デフォルトでは、HProf プロファイラー・サポートは使用可能ではありません。
「HProf の実行」プロパティーを true に設定する場合は、「HProf 引数」プロパティーの値としてコマンド行プロファイラー引数を指定する必要があります。
通知 | 値 |
---|---|
データ型 | ブール |
デフォルト | false |
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
![[IBM i]](../images/iseries.gif)
HProf 引数
アプリケーション・サーバー・プロセスを開始する JVM コードに渡すコマンド行プロファイラー引数を指定します。 HProf プロファイラー・サポートが使用可能であるときは、引数を指定できます。
HProf 引数は、「HProf の実行」プロパティーが true に設定されている場合にのみ必要になります。
デバッグ・モード
JVM をデバッグ・モードで実行するかどうかを指定します。 デフォルトでは、デバッグ・モード・サポートは使用不可です。
「デバッグ・モード」プロパティーを true に設定する場合は、「デバッグ 引数」プロパティーの値としてコマンド行デバッグ引数を指定する必要があります。
通知 | 値 |
---|---|
データ型 | ブール |
デフォルト | false |
デバッグ引数
アプリケーション・サーバー・プロセスを開始する JVM コードに渡すコマンド行デバッグ引数を指定します。 「デバッグ・モード」プロパティーが true に設定されている場合は、引数を指定することができます。
同じノード上で複数のアプリケーション・サーバーのデバッグを使用可能にする場合は、アドレス引数に同じ値が指定されていないことを確認してください。アドレス引数により、デバッグに使用されるポートが定義されます。デバッグが使用可能な 2 つのサーバーが同じデバッグ・ポートを使用するように構成されている場合は、サーバーが適切に開始できない可能性があります。例えば、 両方のサーバーが、デバッグ・アドレス引数のデフォルト値であるデバッグ引数 address=7777 を使用して構成されている場合などです。
通知 | 値 |
---|---|
データ型 | ストリング |
単位 | Java コマンド行の引数 |
汎用 JVM 引数
アプリケーション・サーバー・プロセスを開始する Java 仮想マシン・コードに渡す、コマンド行引数を指定します。

-DhotRestartSync:
同期サービスのホット・リスタート同期機能を使用可能にする場合は、-DhotRestartSync を指定します。この機能は、デプロイメント・マネージャーがアクティブでない場合には 構成更新が行われない環境でインストールが実行されていることを、同期サービスに示します。 したがって、そのサービスは、デプロイメント・マネージャーまたはノード・エージェント・サーバーの再始動時に、 完全なリポジトリーの比較を行う必要はありません。 この機能を使用可能にすると、デプロイメント・マネージャーまたはノード・エージェントの再始動後の、 最初の同期操作の効率が向上します。 これは、特に混合リリース・セルを含み、複数のノードを使用して、複数のアプリケーションを実行するインストールの場合に当てはまります。
- -Dcom.ibm.crypto.provider.doAESInHardware:
IBM SDK and Runtime Environment for AIX®, Java Technology Edition バージョン 7 で提供されている Advanced Encryption Standard (AES) 機能を使用可能にする場合は、このオプションを true に設定します。AES は、複数のラウンドによりデータの暗号化および暗号化解除を行う対称ブロック暗号です。この機能を有効にすることで、WebSphere® Application Server SSL 処理のパフォーマンスが向上しました。
-Xquickstart
デフォルト・モードよりも低い最適化レベルでの初期コンパイルが必要な場合は、-Xquickstart を指定します。後で抽出結果に応じて、 デフォルト・モードでの初期コンパイル・レベルに再コンパイルすることができます。ベスト・プラクティス: -Xquickstart は、 長時間に渡るスループットよりも、初期段階での適度な速度が重要とされるアプリケーションに使用します。 一部のデバッグ・シナリオ、テスト・ハーネス、および実行時間の短いツールの場合は、起動時間を 15% から 20% 改善することができます。bprac
トラブルの回避 (Avoid trouble): IBM i では、この引数はサポートされません。gotcha
-Xverify:none
クラス・ロード中にクラス検証ステージをスキップする場合は、-Xverify:none を指定します。-Xverify:none を使用すると Java クラス検証を使用不可にすることができ、 起動時間が 10 パーセントから 15 パーセント改善されます。ただし、この引数を指定すると、 破損したクラス・データや無効なクラス・データは検出されません。破損したクラス・データがロードされると、JVM が予期しない動作をしたり、JVM に障害が起きたりする可能性があります。
トラブルの回避 (Avoid trouble):
- 計測エラーが発生すると JVM で障害が起きる可能性があるため、バイトコードを変更する場合はこの引数を使用しないでください。
- この引数の使用中に JVM 障害が発生するか、JVM が予期しない動作をする場合は、JVM の問題をデバッグする第一段階としてこの引数を除去します。
IBM i では、この引数はサポートされません。
-Xnoclassgc
クラス・ガーベッジ・コレクションを使用不可にする場合は、-Xnoclassgc を指定します。 この引数によりクラスの再使用率が増加し、パフォーマンスが若干向上します。ただし、これらのクラスが所有するリソースは、クラスが呼び出されていない場合でも使用中の状態となります。
トラブルの回避 (Avoid trouble): ガーベッジ・コレクションのパフォーマンスへの影響は通常ごくわずかです。Java Platform, Enterprise Edition (Java EE) ベースのシステムでクラス・ガーベッジ・コレクションをオフにすると、アプリケーションのクラス・ローダーが頻繁に使用されるため、事実上クラス・データのメモリー・リークが発生し、JVM でメモリー不足による例外がスローされます。gotcha
ガーベッジ・コレクションをモニターする場合は、verbose:gc 構成設定を使用することができます。作成された出力を使用して、これらのリソースの再利用によりパフォーマンスに与える影響を判別することができます。
-Xnoclassgc 引数を指定する場合、アプリケーションを再デプロイするときには常に、必ずアプリケーション・サーバーを再始動して、アプリケーションの前のバージョンからのクラスと静的データをクリアする必要があります。
トラブルの回避 (Avoid trouble): IBM i では、この引数はサポートされません。 このプラットフォームでクラス・ガーベッジ・コレクションを使用不可にするには、-noclassgc 引数を使用する必要があります。gotcha
-Xgcthreads
一度に複数のガーベッジ・コレクション・スレッドを使用する場合は、-Xgcthreads を指定します。このガーベッジ・コレクション技法は、パラレル・ガーベッジ・コレクション と呼ばれます。この引数は、IBM Developer Kit にのみ有効です。
この値を「汎用 JVM 引数」フィールドに入力する場合は、ご使用のマシンで実行中のプロセッサーの数も入力してください。
以下のように -Xgcthreads を指定します。-Xgcthreads<number of processors>
トラブルの回避 (Avoid trouble): -Xgcthreads とプロセッサー数の値 n の間にスペースを入れないでください。
例えば、5 台のプロセッサーで -Xgcthreads を指定する場合は、-Xgcthreads5 となります。
gotchaベスト・プラクティス: ご使用のマシンに複数のプロセッサーが搭載されている場合は、パラレル・ガーベッジ・コレクションを使用する必要があります。bprac
トラブルの回避 (Avoid trouble): IBM i では、この引数はサポートされません。gotcha
-Xnocompactgc
ヒープ圧縮を使用不可にする場合は、-Xnocompactgc を指定します。ヒープ圧縮は、最もコストを必要とする ガーベッジ・コレクション操作です。IBM Developer Kit を使用する場合は、 ヒープ圧縮は避ける必要があります。ヒープ圧縮を使用不可にすると、それに付随するすべてのオーバーヘッドがなくなります。
トラブルの回避 (Avoid trouble): IBM i では、この引数はサポートされません。gotcha
-Xgcpolicy
-Xgcpolicy を指定して、 ガーベッジ・コレクション・ポリシーを設定します。この引数は、IBM Developer Kit にのみ有効です。
スループットを最適化したい場合で、 長時間のガーベッジ・コレクションの一時停止が発生しても問題ないのであれば、 この引数を optthruput に設定します。
世代的ガーベッジ・コレクターを使用する場合、この引数に gencon を設定します。この世代的な方式では、ガーベッジ・コレクションの収集休止時間を短縮するとともに、高スループットを実現します。 この目的を達成するために、ヒープは新旧のセグメントに分割されます。 存続時間が長いオブジェクトは古いスペースにプロモートされますが、存続時間が短いオブジェクトは新規スペースに格納されて短時間にガーベッジ・コレクションが実行されます。 gencon ポリシーは、多くのアプリケーションに大きなメリットをもたらします。 ただし、すべてのアプリケーションにとって適切なわけではなく、一般に調整が難しくなります。
ヒープがいっぱいになる前に、スタックから開始されるアプリケーション・スレッドを追跡するのに並行マーキングを使用する場合は、この引数に optavgpause を指定します。このパラメーターが指定されると、 ガーベッジ・コレクターの一時停止は均一になり、長時間の一時停止は発生しなくなります。 ただし、このポリシーを使用するとスレッドが追加の作業を実行する必要がある場合があるため、スループットは低下します。
マーク、スイープ、圧縮、および世代の各スタイルのガーベッジ・コレクションを使用する場合は、この引数を balanced に設定します。 並行マーク・フェーズは使用できません。並行ガーベッジ・コレクション・テクノロジーは使用されますが、他のポリシーに実装されている並行マークと同じ方法では使用されません。 balanced ポリシーは、Java™ ヒープに領域ベースのレイアウトを使用します。 これらの領域は、ラージ・ヒープでの最大休止時間を削減し、ガーベッジ・コレクションの効率を高めるために個々に管理されます。 このポリシーは、オブジェクト割り振り率と残存率を釣り合わせることによって、グローバル・コレクションを回避しようとします。 グローバル・ガーベッジ・コレクションの特に圧縮に起因するアプリケーション休止時間の問題がある場合は、このポリシーによってアプリケーションのパフォーマンスが改善される可能性があります。 Non-Uniform Memory Architecture (NUMA) 特性を持つ大規模システムを使用している場合 (x86 および POWER® プラットフォームのみ)、balanced ポリシーによってアプリケーションのスループットがさらに改善される可能性があります。
トラブルの回避 (Avoid trouble): IBM i では、この引数はサポートされません。gotcha
-XX
ガーベッジ・コレクション・サイクルでは、存続期間に応じて、相互に独立してオブジェクトを収集します。 追加パラメーターを使用することで、メモリー・プールのサイズを個々に設定できます。 より良好なパフォーマンスを達成するには、ライフサイクルの短いオブジェクトを含むプールのサイズ設定を、プール内のオブジェクトが複数のガーベッジ・コレクション・サイクルにわたって存続することがないような設定にします。 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=32
ベスト・プラクティス: ただし、JVM のヒープ・サイズが 1 GB を超える場合は、以下の値を使用する必要があります。
- -XX:NewSize=640m
- -XX:MaxNewSize=640m
- -XX:SurvivorRatio=16
あるいは、総ヒープ・サイズの 50% から 60% を新世代プールに設定することが可能です。
トラブルの回避 (Avoid trouble): IBM i では、この引数はサポートされません。gotcha
-Xminf
最低フリー・ヒープ・サイズのパーセンテージを変更する場合は、-Xminf を指定します。フリー・スペースが指定量よりも少ない場合、 ヒープは大きくなります。リセット使用可能モードでは、 この引数によりミドルウェアおよび一時的ヒープのフリー・スペースの最小パーセンテージが指定されます。 この引数に指定される値は浮動小数点数で、0 から 1 の間の値です。 デフォルトは .3 (30%) です。
トラブルの回避 (Avoid trouble): IBM i では、この引数はサポートされません。gotcha
-server | -client
Java SE 6 の Java HotSpot Technology では、時間と共にバイトコードの実行方法を最適化するアルゴリズムを含む最適な JVM を使用します。 JVM は、-server および -client の 2 つのモードで実行します。 ほとんどの場合、-server モードを使用します。これにより、長期間にわたるランタイム実行の効率を向上させることができます。
デフォルトの -client モードを使用する場合は、 サーバー起動時間が短縮され、作成されるメモリーのフットプリントが減少します。 ただし、このモードでは拡張パフォーマンスは低下します。サーバーの起動時間よりパフォーマンスが優先される場合は、-server モードを使用するとパフォーマンスが向上します。プロセス・サイズおよびサーバー起動時間をモニターして、-client モードと -server モードを使用した際のパフォーマンスの違いを確認することができます。
トラブルの回避 (Avoid trouble): IBM i では、この引数はサポートされません。gotcha
- -Dcom.ibm.CORBA.RequestTimeout=timeout_interval
-Dcom.ibm.CORBA.RequestTimeout= timeout_interval 引数を指定して、 クライアントから送信された要求に応答するタイムアウト期間を設定します。 この引数は、-D オプションを使用します。timeout_interval は秒単位のタイムアウト期間です。 ネットワークで極端な待ち時間が発生している場合は、タイムアウトを防ぐために大きい値を指定します。 指定した値が小さ過ぎると、 ワークロード管理に関与するアプリケーション・サーバーが応答を受け取る前にタイムアウトになる可能性があります。
アプリケーションでタイムアウトの問題が発生した場合にのみ、この引数を指定してください。この引数に推奨値はありません。
- -Dcom.ibm.server.allow.sigkill=true
-Dcom.ibm.server.allow.sigkill=true 引数により、ノード・エージェント・プロセスは、Ping 間隔に指定された時間内に stop メソッドが完了しない場合に、プロセスの terminate メソッドを使用することができます。 この設定は、ノード・エージェントがアプリケーション・サーバーをモニター中に、そのアプリケーション・サーバーとの接続が失われた場合に便利です。
アプリケーション・サーバーに自動再始動が有効に設定されているため、アプリケーション・サーバーのモニター・ポリシーにより、ノード・エージェントがアプリケーション・サーバーの再始動を許可されると、ノード・エージェントはアプリケーション・サーバー・プロセスに対して stop メソッドを実行します。 停止処理中は、ノード・エージェントがアプリケーション・サーバーをモニターします。そのため、Ping 間隔に指定された時間間隔内にアプリケーション・サーバーが停止せず、この引数がデフォルト値の true に設定されている場合は、ノード・エージェントがアプリケーション・サーバー・プロセスで terminate メソッドを実行して、アプリケーション・サーバー・プロセスを停止します。
この引数を false に設定している場合、ノード・エージェントは stop プロセスのモニターを継続しますが、アプリケーション・サーバーの再始動は試みません。
管理コンソールを使用してこの引数を使用不可に設定するには、 「システム管理」>「ノード・エージェント」>「nodeagent_name」>「Java およびプロセス管理」>「プロセス定義」>「Java 仮想マシン」>「汎用 JVM 引数」をクリックします。
- -Dcom.ibm.websphere.alarmthreadmonitor.hung_alarm_mute=
この引数は、アラームがシステム・ログのハング・スレッド・メッセージ内の完全なスタック・トレースを報告する最大回数を指定します。
システムのアラーム・スレッドがアクティブである時間が、アラーム・スレッド・モニターのしきい値より長い場合、アプリケーション・サーバーは、アラーム・スレッドの名前、アラーム・スレッドがアクティブになっている時間の長さ、および完全な例外スタック・トレースと共にハング・スレッド・メッセージをログに記録します。完全なスタック・トレースは、遅延の原因をデバッグするには役立ちますが、ハング・スレッド・メッセージが頻繁にトリガーされる場合は、長メッセージが繰り返されることで、システム・ログ内の他の情報を見つけにくくなる可能性があります。この引数を 0 より大きい整数に設定して、1 つのアラームがその完全なスタック・トレースを報告する最大回数を指定してください。回数がこのしきい値に達すると、それ以降の各ハング・スレッド・メッセージには、ハング・アラーム・ハンドラーのエントリーのみが含まれます。
デフォルト値の 0 は、アラームのすべてのハング・スレッド・メッセージに完全なスタック・トレースが含まれることを示します。
注: このプロパティーが指定するのは、各アラーム・ハンドラー・クラスのしきい値であり、メッセージ総数や各アラーム・ハンドラー・インスタンスのしきい値ではありません。 - -Dcom.ibm.websphere.native.logging.timestamp=true
native_stdout および native_stderr ログ・ファイルに出力されるすべてのサーバー・デバッグ・メッセージの前にタイム・スタンプとスレッド ID を追加するには、この引数を指定します。そのタイム・スタンプとスレッド ID を使用して、アプリケーション・サーバー・ブートストラップ・コンポーネントの動作を他のサーバー・メカニズムの動作と相互に関連付けることができます。この相関は、SystemOut および SystemErr ログ・ファイル内に示されます。デフォルトでは、この動作は使用不可となっています。
JVM 汎用引数 -Dws.ext.debug=true を指定してサーバーが構成されている場合、ブートストラッピング・シーケンス中にデバッグ・メッセージが native_stdout.log および native_stderr.log に出力されます。 また、-Dcom.ibm.websphere.native.logging.timestamp も true に設定されている場合、以下の例に示すように、サーバーはデバッグ・メッセージをタイム・スタンプとスレッド ID と共に出力します。
[6/18/12 16:24:31:453 CDT] 00000000 ws.ext.mains.args[0]=-nosplash [6/18/12 16:24:31:453 CDT] 00000000 ws.ext.mains.args[1]=-application [6/18/12 16:24:31:453 CDT] 00000000 ws.ext.mains.args[2]=com.ibm.ws.bootstrap.WSLauncher [6/18/12 16:24:31:453 CDT] 00000000 ws.ext.mains.args[3]=com.ibm.ws.runtime.WsServer
注: -Dws.ext.debug=true は、IBM サポート 担当員による指示がある場合のみ指定してください。 - -Dcom.ibm.ws.wim.registry.DbSharedAcrossMultipleServers=true
複数の異なるインストール済み環境で仮想メンバー・マネージャー (VMM) DB/LA リポジトリーが共有される場合、-Dcom.ibm.ws.wim.registry.DbSharedAcrossMultipleServers=true と指定します。このプロパティーは、クラスター環境で使用するためのものではありません。このプロパティーを設定すると、リポジトリーを共有する WebSphere Application Server インストール済み環境からの呼び出しを VMM が同期化できるようになります。
-Dcom.ibm.websphere.wlm.unusable.interval=interval
この引数は z/OS の場合にのみ適用されます。クライアントのワークロード管理状態のリフレッシュが早過ぎるかまたは遅過ぎる場合は、-Dcom.ibm.websphere.wlm.unusable.interval= timeout_interval 引数を指定して、com.ibm.websphere.wlm.unusable.interval プロパティーの値を変更します。 このプロパティーでは、ワークロード管理クライアント・ランタイムが、サーバーを使用不可とマークした後、 再度そのサーバーへの接続を試みるまでの間の待機時間を秒単位で指定します。この引数は、-D オプションを使用します。デフォルト値は 300 秒です。このプロパティーが大きい値に設定されると、 サーバーは長時間使用不可であるとマークされます。 これで、ワークロード管理リフレッシュ・プロトコルが、 この時間枠が終了するまではクライアントのワークロード管理状態をリフレッシュ しないようになります。
-Dcom.ibm.ws.buffermgmt.impl.WsByteBufferPoolManagerImpl=
この引数は z/OS の場合にのみ適用されます。-Dcom.ibm.ws.buffermgmt.impl.WsByteBufferPoolManagerImpl= 引数を指定して、 バッファーが不要になった直後に、個別に直接バイト・バッファーのストレージを解放する必要があることを示します。 この引数でサポートされる値は、com.ibm.ws.buffermgmt.impl.ZOSWsByteBufferPoolManagerImpl のみです。
JVM が要求データを処理するために作成する直接バイト・バッファーは、JVM ヒープ内ではなく、Language Environment® (LE) ヒープ内で割り振られます。通常は、直接バイト・バッファーが 必要ではなくなった場合でも、次のガーベッジ・コレクションが発生するまで、JVM は このネイティブ LE ストレージをリリースしません。サーバーが大量の要求を処理している場合は、 JVM がガーベッジ・コレクション・サイクルを実行する前に LE ストレージが使い尽くされ、 サーバーは異常終了 (アベンド) することがあります。 以下の引数を使用して JVM を構成すると、これらの異常終了は発生しません。-Dcom.ibm.ws.buffermgmt.impl.WsByteBufferPoolManagerImpl=com.ibm.ws.buffermgmt.impl.ZOSWsByteBufferPoolManagerImpl
z/OS プラットフォームでは、TCP チャネルの zaioFreeInitialBuffers カスタム・プロパティーを指定して、新規の接続に使用される初期読み取りバッファーが、その接続に必要でなくなった時点で直ちにチャネルによりリリースされるようにする場合にも、この引数を指定する必要があります。
-DisSipComplianceEnabled=true|false
SIP 準拠検査が SIP プロキシー・サーバーで有効になっているかどうかを指定します。SIP 準拠検査により、SIP メッセージが Session Initiation Protocol 標準に準拠するようにします。このプロパティーが true に設定されると、SIP 準拠検査が使用可能になります。
トラブルの回避 (Avoid trouble): z/OS WebSphere Application Server Network Deployment 環境でプロキシー・サーバーを実行していて、プロキシー・サーバーがクラスターの一部でない場合、isSipComplianceEnabled SIP プロキシー・サーバー・カスタム・プロパティーを使用して、その SIP プロキシー・サーバーに対して SIP 準拠検査を使用可能または使用不可にします。ただし、スタンドアロン・アプリケーション・サーバーを実行しているか、プロキシー・サーバーがクラスターの一部である場合、 この汎用 JVM 引数を使用して、SIP 準拠検査を使用可能または使用不可にする必要があります。gotcha
-Xshareclasses:none
-Xshareclasses:none 引数を指定して、プロセスの共有クラス・オプションを使用不可にします。 キャッシュでクラスを共有すると、起動時間が短縮され、メモリー占有スペースを縮小できます。 アプリケーション・サーバー、ノード・エージェントおよびデプロイメント・マネージャーなどのプロセスは、この共有クラス・オプションを使用できます。
このオプションを使用すると、プロセスを使用していない場合にキャッシュをクリアする必要があります。 キャッシュをクリアするには、<app_server_root>/bin/clearClassCache.bat ユーティリティーを呼び出すか、プロセスを停止してからそのプロセスを再始動します。
注: clearClassCache を使用している場合、キャッシュ全体をクリアするには、接続されているすべての JVM を停止する必要があります。トラブルの回避 (Avoid trouble):
- アプリケーション・サーバー・プロセスで稼働中の Java EE アプリケーション・クラスは、共有クラス・キャッシュには追加されません。
- -XXallowvmshutdown:false
-XXallowvmshutdown:false 引数を使用すると、JVM の前の動作 (正しくない動作) に戻ります。以前の動作に依存するアプリケーションがある場合は、この引数を汎用 JVM 引数セクションに追加することで前の動作に戻ることができます。
通知 | 値 |
---|---|
データ型 | ストリング |
単位 | Java コマンド行の引数 |
実行可能 JAR ファイル名
JVM コードで使用する実行可能な JAR ファイルの絶対パス名を指定します。
通知 | 値 |
---|---|
データ型 | ストリング |
単位 | パス名 |
JIT を使用不可にする
JVM コードのジャストインタイム (JIT) コンパイラー・オプションを使用不可にするかどうかを指定します。
JIT コンパイラーを使用不可にしている場合は、スループットが著しく減少します。したがって、 パフォーマンス上の理由から、JIT は使用可能のままにしてください。
通知 | 値 |
---|---|
データ型 | ブール |
デフォルト | false (JIT は使用可能) |
推奨 | JIT は使用可能 |
オペレーティング・システム名
所定のオペレーティング・システムの JVM 設定を指定します。
プロセスの開始時に、 そのプロセスがノードに対して指定された JVM 設定をオペレーティング・システムの JVM 設定として使用します。