Java 仮想マシン設定

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

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

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

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

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

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

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

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

冗長ガーベッジ・コレクションが有効になっている場合、デバッグ出力は 10 個の循環 verbosegc ログ・ファイルに送信されます。このログ・ファイルには、約 7000 個のガーベッジ・コレクション・サイクル (概算サイズ 10 M) を含めることができます。 冗長ガーベッジ・コレクションのパフォーマンス・オーバーヘッドは無視できます。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

複数のアプリケーション・サーバーのデバッグを使用可能にする場合は、アドレス引数に同じ値が指定されていないことを確認してください。 アドレス引数により、デバッグに使用されるポートが定義されます。 デバッグが使用可能な 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 処理のパフォーマンスが向上します。

-Xquickstart

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

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

-Xverify:none

クラス・ロード中にクラス検証ステージをスキップする場合は、-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 の場合にのみ有効です。

この値を「汎用 JVM 引数」フィールドに入力する場合は、ご使用のマシンで実行中のプロセッサーの数も入力してください。

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

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

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

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

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

-Xnocompactgc

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

-Xgcpolicy

-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

最低フリー・ヒープ・サイズのパーセンテージを変更する場合は、-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=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

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

この引数は、 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

SIP 準拠検査が SIP プロキシー・サーバーで有効になっているかどうかを指定します。 SIP 準拠検査により、SIP メッセージが Session Initiation Protocol 標準に準拠するようにします。 このプロパティーが true に設定されると、SIP 準拠検査が使用可能になります。

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

-Xshareclasses:none

-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 ファイルの絶対パス名を指定します。

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

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

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

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