Java 仮想マシン設定

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

9.0.5.24 では、管理された Liberty サーバーに対して Classpath フィールドが削除されました。

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

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

9.0.5.24 で、 Boot classpath フィールドが管理された Liberty サーバーから削除されました。

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

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

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

冗長クラス・ロードが使用可能な場合、デバッグ出力はネイティブ・プロセス・ログのいずれかに送信されます。

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

冗長ガベージコレクションが有効な場合、デバッグ出力はJESジョブログに送られる。 冗長なガベージコレクションのパフォーマンス・オーバーヘッドはごくわずかである。

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

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

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

冗長なガベージコレクションが有効になっている場合、デバッグ出力は10個の回転する verbosegc ログファイルに送られ、このログファイルには約7000ガベージコレクションサイクルを含めることができ、おおよそのサイズは10Mである。 冗長なガベージコレクションのパフォーマンス・オーバーヘッドはごくわずかである。

注意冗長ガベージ・コレクションのロギング動作を 9.0.0.3 より前のリリースまたはフィックス・パックの動作に戻すには、冗長ガベージ・コレクションを無効にし、汎用JVM引数フィールドに標準JVMオプション -verbose:gc を入力し、フィールドにガベージ・コレクション診断を制御する追加のJVMオプションが含まれていないことを確認します。 これにより、JVM はデバッグ出力をネイティブ・プロセス・ログに送信するように指示されます。

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

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

9.0.5.24 で、 Verbose JNI フィールドは、管理された Liberty サーバーのために削除された。

JVM コードで使用可能な初期ヒープ・サイズ (メガバイト単位) を指定します。 このフィールドがブランクの場合は、デフォルト値が使用されます。 ほとんどのアプリケーションでは、デフォルト値で十分です。

分散プラットフォームの場合、デフォルトの初期ヒープ・サイズは 50 MB です。

IBM i の場合、デフォルトの初期ヒープ・サイズは50MBである。 初期ヒープ・サイズは常に最大ヒープ・サイズよりも小さくなければなりません。 初期ヒープ・サイズ・プロパティーと最大ヒープ・サイズ・プロパティーに同じ値を設定しないようにしてください。

z/OS の場合、コントローラのデフォルトの初期ヒープサイズは256MBで、サーバントのデフォルトの初期ヒープサイズは512MBである。

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

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

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

デフォルトの最大ヒープ・サイズはシステム・メモリー合計量の 25% (最大 4 GB) です。メモリー・サイズにアクセスできない場合は JVM のデフォルトが使用されます。 デフォルトの最大ヒープ・サイズの計算の上限は、分散環境の場合は 4 GB です。 この場合に、計算が実行されるのは、サーバー構成に最大ヒープ・サイズの値が設定されていない場合のみです。 値が設定されている場合、最大ヒープ・サイズのハード最大値は 4 GB ではありません。

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

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

z/OS の場合、コントローラのデフォルトの最大ヒープサイズは512 MBで、サーバントのデフォルトの最大ヒープサイズは1024 MBです。 ページングを防止するには、このプロパティーに対してプロセッサーごとに最低 256 MB の物理メモリー、および アプリケーション・サーバーごとに 512 MB の物理メモリーを確保する値を指定します。 ページングが原因でプロセッサー使用率が低い場合は、可能であれば、最大ヒープ・サイズではなく、使用可能メモリーを増やします。 最大ヒープ・サイズが増えると、パフォーマンスは向上せずに低下する可能性があります。

ほとんどのアプリケーションでは、デフォルト値が適しています。 ガーベッジ・コレクションがあまりにも頻繁に発生している可能性がある場合は、「冗長ガーベッジ・コレクション」プロパティーを使用可能にします。 ガーベッジ・コレクションがあまりにも頻繁に発生する場合は、JVM ヒープの最大サイズを増やします。

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

9.0.5.24 で、 HProfの実行フィールドは、管理された Liberty サーバーのために削除されました。

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

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

9.0.5.24 で、 HProf Arguments フィールドが管理された Liberty サーバーから削除されました。

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

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

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

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

debug引数 address の値は、デバッグに使用するIPアドレスとポートを定義する。 管理された Liberty サーバーでは、デフォルトでは、IPアドレスが指定されていない場合、ローカルデバッグのみが有効になります。 リモートデバッグ用に特定のIPアドレスとポートを指定するには、debug引数アドレスの値を <IP-address>:<port> に設定する。

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

アプリケーション・サーバー・プロセスを開始する 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 処理のパフォーマンスが向上します。

-Xクイックスタート

デフォルト・モードよりも低い最適化レベルでの初期コンパイルが必要な場合は、-Xquickstart を指定します。 後で抽出結果に応じて、 デフォルト・モードでの初期コンパイル・レベルに再コンパイルすることができます。

-Xquickstart は、 長時間に渡るスループットよりも、初期段階での適度な速度が重要とされるアプリケーションに使用します。 一部のデバッグ・シナリオ、テスト・ハーネス、および実行時間の短いツールでは、起動時間を 15 パーセントから 20 パーセント改善できます。

-Xverify:なし

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

計測エラーが発生すると JVM で障害が起きる可能性があるため、バイトコードを変更する場合はこの引数を使用しないでください。 この引数の使用中に JVM 障害が発生するか、JVM が予期しない動作をする場合は、JVM の問題をデバッグする第一段階としてこの引数を除去します。

-Xnoclassgc

クラス・ガーベッジ・コレクションを使用不可にする場合は、-Xnoclassgc を指定します。 この引数によりクラスの再使用率が増加し、パフォーマンスが若干向上します。 ただし、これらのクラスが所有するリソースは、クラスが呼び出されていない場合でも使用中の状態となります。

通常、クラス・ガーベッジ・コレクションのパフォーマンスへの影響は最小限に抑えられます。 Java Platform, Enterprise Edition (Java EE) ベースのシステムでクラス・ガーベッジ・コレクションをオフにすると、アプリケーション・クラス・ローダーを頻繁に使用することにより、クラス・データのメモリー・リークが効果的に作成され、JVM がメモリー不足例外をスローする可能性があります。

ガーベッジ・コレクションをモニターする場合は、verbose:gc 構成設定を使用することができます。 作成された出力を使用して、これらのリソースの再利用によりパフォーマンスに与える影響を判別することができます。

-Xnoclassgc 引数を指定する場合、アプリケーションを再デプロイするときには常に、必ずアプリケーション・サーバーを再始動して、アプリケーションの前のバージョンからのクラスと静的データをクリアする必要があります。

トラブルを避ける： このプラットフォームでクラス・ガベージ・コレクションを無効にするには、 -noclassgc 引数を使わなければならない。

-Xgcthreads

一度に複数のガーベッジ・コレクション・スレッドを使用する場合は、-Xgcthreads を指定します。 このガーベッジ・コレクション技法は、パラレル・ガーベッジ・コレクション と呼ばれます。 この引数は、 IBM Developer Kit の場合にのみ有効です。

Generic JVM arguments（汎用JVM引数） フィールドにこの値を入力する場合は、マシンで動作しているプロセッサーの数も入力してください。

以下のように -Xgcthreads を指定します。

-Xgcthreads<プロセッサーの数>

-Xgcthreads とプロセッサ数 n の間にはスペースを入れないでください。

-Xgcthreads5 は、5 つのプロセッサーで -Xgcthreads を指定する例です。

ご使用のマシンに複数のプロセッサーが搭載されている場合は、パラレル・ガーベッジ・コレクションを使用する必要があります。

-Xnocompactgc

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

-Xgcポリシー

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

この引数を optthruput スループットを最適化したい場合、ガベージ コレクションによる長時間の一時停止が発生しても問題が発生しません。

世代的ガーベッジ・コレクターを使用する場合、この引数に gencon を設定します。 この世代的な方式では、ガーベッジ・コレクションの収集休止時間を短縮するとともに、高スループットを実現します。 この目的を達成するために、ヒープは新旧のセグメントに分割されます。 存続時間が長いオブジェクトは古いスペースにプロモートされますが、存続時間が短いオブジェクトは新規スペースに格納されて短時間にガーベッジ・コレクションが実行されます。 gencon ポリシーは、多くのアプリケーションに大きなメリットをもたらす。 ただし、すべてのアプリケーションにとって適切なわけではなく、一般に調整が難しくなります。

ヒープが一杯になる前にスタックからスタートするアプリケーション・スレッドを追跡するために、同時実行マーキングを使用したい場合は、この引数を optavgpause に設定する。 このパラメーターが指定されると、 ガーベッジ・コレクターの一時停止は均一になり、長時間の一時停止は発生しなくなります。 しかし、このポリシーを使用すると、スレッドが余分な作業をしなければならなくなる可能性があるため、スループットが低下する。

マーク、スウィープ、コンパクト、ジェネレーショナル・スタイルのガベージ・コレクションを使用したい場合は、この引数を balanced に設定する。 並行マーク・フェーズは使用できません。並行ガーベッジ・コレクション・テクノロジーは使用されますが、他のポリシーに実装されている並行マークと同じ方法では使用されません。 balanced ポリシーでは、Java™ ヒープに領域ベースのレイアウトが使用されます。 これらの領域は、ラージ・ヒープでの最大休止時間を削減し、ガーベッジ・コレクションの効率を高めるために個々に管理されます。 このポリシーは、オブジェクトの割り振り回数と残存率を釣り合わせることによって、グローバル・コレクションを回避しようとします。 グローバル・ガーベッジ・コレクションの特に圧縮に起因するアプリケーション休止時間の問題がある場合は、このポリシーによってアプリケーションのパフォーマンスが改善される可能性があります。 NUMA (Non-Uniform Memory Architecture) 特性を持つ大規模システム (x86 および POWER ® プラットフォームのみ) を使用している場合、バランスの取れたポリシーにより、アプリケーションのスループットがさらに向上する可能性があります。

-XX

ガーベッジ・コレクション・サイクルでは、存続期間に応じて、相互に独立してオブジェクトを収集します。 追加パラメーターを使用することで、メモリー・プールのサイズを個々に設定できます。 より良好なパフォーマンスを達成するには、ライフサイクルの短いオブジェクトを含むプールのサイズ設定を、プール内のオブジェクトが複数のガーベッジ・コレクション・サイクルにわたって存続することがないような設定にします。 新しい世代プールのサイズを指定するには、 NewSize と MaxNewSize パラメータを使用する。

最初のガーベッジ・コレクション・サイクルが経過しても存続しているオブジェクトは、他のプールに転送されます。 SurvivorRatio パラメーターを使用して、サバイバー・プールのサイズを指定します。SurvivorRatioTivoli Performance Viewer が収集するオブジェクト統計を使用するか、または構成設定に引数 verbose: gc を組み込んで、ガーベッジ・コレクション統計をモニターすることができます。 ガーベッジ・コレクションによってボトルネックが発生した場合は、以下の引数を指定して、ご使用の環境により適合するように世代プール設定をカスタマイズします。

-XX:NewSize=lower_bound 
-XX:MaxNewSize=upper_bound
 -XX:SurvivorRatio=new_ratio_size 

デフォルト値は、以下のとおりです。

• NewSize=2m
• MaxNewSize=32m
• SurvivorRatio=32

ベスト・プラクティス: ヒープ・サイズが 1 GB を超える JVM がある場合は、以下の値を使用する必要があります。

• -XX:NewSize=640m
• -XX:MaxNewSize=640m
• -XX:SurvivorRatio=16

あるいは、総ヒープ・サイズの 50% から 60% を新規の世代プールに設定することができます。

-エックスミンエフ

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

-Dcom.ibm.CORBA.RequestTimeout=timeout_interval

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

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

-Dcom.ibm.server.allow.sigkill =真

-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 =真

native_stdout および native_stderr ログ・ファイルに出力されるすべてのサーバー・デバッグ・メッセージの前にタイム・スタンプとスレッド 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 と指定します。 このプロパティーは、クラスター環境で使用するためのものではありません。 このプロパティを設定することで、VMMはリポジトリを共有する WebSphere Application Server インストレーションからのコールを同期できるようになる。

-Dcom.ibm.websphere.wlm.unusable.interval =インターバル

クライアントのワークロード管理状態のリフレッシュが早過ぎるかまたは遅過ぎる場合は、-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 準拠検査が使用可能になります。

z/OS WebSphere Application Server Network Deployment環境でプロキシ・サーバを実行しており、プロキシ・サーバがクラスタの一部でない場合は、isSipComplianceEnabledSIP プロキシ・サーバ・カスタム・プロパティを使用して、その SIP プロキシ・サーバの SIP コンプライアンス・チェックを有効または無効にできます。 ただし、スタンドアロン・アプリケーション・サーバーを実行しているか、プロキシー・サーバーがクラスターの一部である場合、この汎用 JVM 引数を使用して、SIP 準拠検査を使用可能または使用不可にする必要があります。

-Xshareclasses:なし

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

場合によっては、アプリケーション・コードを変更するときや WebSphere Application Serverをアップグレードするときなどに、共有クラス・キャッシュをクリアする必要があります。 キャッシュをクリアするには、ディレクトリー <app_server_root>/bin/から clearClassCache スクリプトを実行します。

./clearClassCache.sh

clearClassCache.bat

clearClassCache

システムを再起動するとキャッシュもクリアされる。

注: clearClassCache スクリプトを使用する前に、接続されているすべての JVM を停止する必要があります。 clearClassCache スクリプトの使い方については、 clearClassCache スクリプトを参照。

問題の回避:

• クラス共有とそれに関連する設定は、以下ではサポートされません。
  • Solaris
  • HP-UX

移行ユーザーの場合:

• バージョン 9.0.5.0より前では、アプリケーション・サーバー・プロセスで実行されている Java EE アプリケーション・クラスは、共有クラス・キャッシュに追加されません。
• バージョン 9.0.5.0 以降では、Java EE アプリケーション・クラスが共有クラス・キャッシュに追加されます。

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

9.0.5.24 では、管理された Liberty サーバーについて、 実行可能 JAR ファイル名フィールドが削除されました。

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

9.0.5.24 で、管理された Liberty サーバーのために Disable JIT フィールドが削除された。

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

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

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