このページを使用して、アプリケーション・サーバーのプロセスの Java 仮想マシン (JVM) 構成の表示および変更を行います。
この管理コンソール・ページを表示するには、管理コンソールに接続し、「Java 仮想マシン」パネルにナビゲートします。
i5/OS および分散プラットフォーム・ベースの WebSphere Application Server および WebSphere Application Server - Express の場合、 「サーバー」>「アプリケーション・サーバー」>「server1」とクリックします。 次に「サーバー・インフラストラクチャー」の下で、 「Java およびプロセス管理」>「プロセス定義」>「Java 仮想マシン」とクリックします。
ガーベッジ・コレクションの冗長デバッグ出力を使用するかどうかを指定します。 デフォルトでは、冗長ガーベッジ・コレクションは使用可能ではありません。
データ型 | ブール |
デフォルト | false |
このフィールドが使用可能な場合、ガーベッジ・コレクターが稼働するたびに、出力ストリームにレポートが書き込まれます。 このレポートは、Java ガーベッジ・コレクションで何が起こっているかを伝えます。
83.29/3724.32 * 100 = 2.236%
GC に 5% を超える時間を費やし、GC が頻繁に発生している場合、 ご使用の Java ヒープ・サイズを増やす必要があります。
これを明らかにするには、%free を見ます。 数が減少し続けていないか確認します。%free が減少し続けている場合、GC から GC に 割り振られたヒープが徐々に増加しており、ご使用のアプリケーションにメモリー・リークがあることを示している可能性があります。
ネイティブ・メソッドの起動のために冗長デバッグ出力を使用するかどうかを指定します。 デフォルトでは、 冗長 Java ネイティブ・インターフェース (JNI) アクティビティーは使用可能ではありません。
データ型 | ブール |
デフォルト | false |
HProf プロファイラー・サポートを使用するかどうかを指定します。別のプロファイラーを使用するには、「HProf 引数」の設定を使用してカスタム・プロファイラーの設定を指定します。 デフォルトでは、HProf プロファイラー・サポートは使用可能ではありません。
この設定は、 基本 WebSphere Application Server および WebSphere Application Server - Express 製品にのみ適用されます。
「HProf の実行」プロパティーを true に設定する場合は、「HProf 引数」プロパティーの値としてコマンド行プロファイラー引数を指定する必要があります。
データ型 | ブール |
デフォルト | false |
アプリケーション・サーバー・プロセスを開始する JVM コードに渡すコマンド行プロファイラー引数を指定します。 HProf プロファイラー・サポートが使用可能であるときは、引数を指定できます。
この設定は、 基本 WebSphere Application Server および WebSphere Application Server - Express 製品にのみ適用されます。
HProf 引数が必要になるのは、「HProf の実行」プロパティーが true に設定されている場合のみです。
データ型 | ストリング |
JVM をデバッグ・モードで実行するかどうかを指定します。 デフォルトでは、デバッグ・モード・サポートは使用可能ではありません。
「デバッグ・モード」プロパティーを true に設定する場合は、 「デバッグ引数」プロパティーの値としてコマンド行デバッグ引数を指定する必要があります。
データ型 | ブール |
デフォルト | false |
アプリケーション・サーバー・プロセスを開始する JVM コードに渡すコマンド行デバッグ引数を指定します。 「デバッグ・モード」が使用可能である場合に、引数を指定できます。
基本 WebSphere Application Server および WebSphere Application Server - Express の構成では、デバッグ引数が必要になるのは、「デバッグ・モード」プロパティーが true に設定されている場合のみです。 複数のアプリケーション・サーバーでデバッグを使用可能にする場合は、各サーバーで、異なる address 引数 (この引数によって、デバッグ用のポートが定義される) を使用していることを確認してください。例えば、2 つのサーバーでデバッグを使用可能にし、 それぞれのサーバーのデフォルトのデバッグ・ポートを address=7777 のままにしておくと、 サーバーは正常に始動できない場合があります。
データ型 | ストリング |
単位 | Java コマンド行の引数 |
アプリケーション・サーバー・プロセスを始動する Java 仮想マシン・コードに渡すコマンド行引数を指定します。
-Xquickstart は、デフォルト・モードの場合よりも低い最適化レベルでの初期コンパイルに使用できます。後で抽出結果に応じて、 デフォルト・モードでの初期コンパイル・レベルに再コンパイルすることができます。-Xquickstart は、 長時間に渡るスループットよりも、初期段階での適度な速度が重要とされるアプリケーションに使用します。 一部のデバッグ・シナリオ、一連のテスト、および実行時間の短いツールなどでは、起動時間を 15 - 20% 程度改善させることが可能です。
クラス・ロード中にクラス検証の段階をスキップしたい場合は、-Xverify:none を使用することができます。ジャストインタイム (JIT) コンパイラーを使用可能にして -Xverify:none を使用することにより、起動時間は 10 から 15% 改善されます。
-Xnoclassgc を使用すると、クラス・ガーベッジ・コレクションを使用不可にすることができます。 このアクションにより、クラスの再利用率が上がり、パフォーマンスが若干向上します。代わりに、これらのクラスが所有するリソースを収集できません。 verbose:gc 構成設定を使用すると、ガーベッジ・コレクションをモニターできます。 この設定で、クラス・ガーベッジ・コレクションの統計が出力されます。 これら統計を検査することによって、リソースの再利用と、リソースの再利用で必要なガーベッジ・コレクションの量との間のトレードオフについて理解できます。 ただし、同一のクラスのセットがワークロードで繰り返し収集される場合には、ガーベッジ・コレクションを使用不可にしてください。 デフォルトで、このクラス・ガーベッジ・コレクションは使用可能になっています。
ガーベッジ・コレクションのスレッドは、一度に複数使用することができます。 これは並列ガーベッジ・コレクション としても知られています。 この値を汎用 JVM 引数フィールドに入力する場合は、使用マシンに搭載されているプロセッサーの数も入力してください。例えば、-Xgcthreadsn とします。ここで、n はプロセッサー数です。n 個のプロセッサーを使用するノードでは、デフォルトのスレッド数は n です。 使用マシンに複数のプロセッサーが搭載されている場合は、 並列ガーベッジ・コレクションを使用する必要があります。 この引数は、IBM Developer Kit にのみ有効です。
コストが最も高いガーベッジ・コレクション操作であるヒープ圧縮を使用不可にする場合には、-Xnocompactgc を使用することができます。IBM Developer Kit では圧縮を行わないでください。ヒープ圧縮を使用不可にすると、それに付随するすべてのオーバーヘッドがなくなります。
-Xinitsh を使用すると、クラス・オブジェクトが格納される初期ヒープ・サイズを設定できます。 クラス・オブジェクトだけではなく、メソッド定義および静的フィールドも格納されます。 システムのヒープ・サイズに上限はありませんが、初期サイズを設定し、 システムのヒープ・サイズの拡張 (これには、オペレーティング・システムのメモリー・マネージャーの呼び出しが伴います) によるコストが発生しないようにしてください。WebSphere Application Server 製品にロードされるクラスの数 (約 8,000 クラス) およびその平均サイズを知ることにより、適切な初期システム・ヒープ・サイズを算出できます。 アプリケーションに関する知識がある場合は、それらを計算に含めることができます。 この引数は、IBM Developer Kit でのみ使用できます。
-Xgpolicy を使用すると、ガーベッジ・コレクション・ポリシーを設定できます。ガーベッジ・コレクション・ポリシー (gcpolicy) が、optavgpause に設定されている場合には、 並行マーキングを使用して、ヒープがフルになる前に、 スタックから開始されるアプリケーション・スレッドのトラッキングを行います。 このように設定すると、ガーベッジ・コレクターの休止が定期的になり、長期間休止することはなくなります。 このトレードオフとして、 スレッドが余分な処理を行わねばならないことによるスループットの低下が発生する場合があります。デフォルトで、推奨されている値は optthruput です。 値を -Xgcpolicy:[optthruput|optavgpause] として入力します。 この引数は、IBM Developer Kit でのみ使用できます。
Sun ベースの Java Development Kit (JDK) バージョン 1.4.2 には、世代ガーベッジ・コレクションがあります。 これによって、存続期間が異なるオブジェクトを、それぞれ個別のメモリー・プールに入れることができます。ガーベッジ・コレクション・サイクルでは、存続期間に応じて、相互に独立してオブジェクトを収集します。 追加パラメーターを使用することで、メモリー・プールのサイズを個々に設定できます。 より良いパフォーマンスを得るには、存続期間の短いオブジェクトを含むプールを設定してください。 これによって、プール内のオブジェクトが、複数のガーベッジ・コレクション・サイクルに渡って存続することがなくなります。 新しい世代プールのサイズは、NewSize および MaxNewSize パラメーターによって決まります。
-XX:NewSize (下限) -XX:MaxNewSize (上限) -XX:SurvivorRatio=NewRatioSize
デフォルト値は、NewSize=2m MaxNewSize=32m SurvivorRatio=2 です。 ただし、JVM のヒープ・サイズが 1 GB より大きい場合には、次の値 -XX:newSize=640m -XX:MaxNewSize=640m -XX:SurvivorRatio=16 を使用するか、新規世代プールに対してトータル・ヒープ・サイズを 50% から 60% に設定します。
-Xminf を使用すると、最小フリー・ヒープ・サイズの割合を指定できます。フリー・スペースが指定量よりも少ない場合、 ヒープは大きくなります。リセット可能モードで、 このオプションは、ミドルウェアおよび一過性ヒープのフリー・スペースの最小割合を指定します。 これは、浮動小数点数 0 から 1 です。デフォルトは .3 (30%) です。
Sun ベースの Java Development Kit (JDK) バージョン 1.4.2 の Java HotSpot Technology には、バイト・コードの実行を長期にわたり最適化するアルゴリズムを含む最適な JVM が導入されています。JVM は、-server および -client の 2 つのモードで実行します。 デフォルトの -client モードを使用する場合には、起動時間が短縮され、 メモリーのフットプリントが減少します。ただし、拡張パフォーマンスは低下します。 HotSpot JVM の立ち上げに十分な時間がかけられる場合には、-server モードを使用して、 バイト・コードを連続して実行することによって、パフォーマンスを向上させることができます。 ほとんどの場合、-server モードを使用します。これにより、長期間にわたるランタイム実行の効率をあげることができます。 プロセス・サイズとサーバー起動時間をモニターすることで、-client と -server の違いを確認できます。
データ型 | ストリング |
単位 | Java コマンド行引数 |
JVM コードで使用する実行可能な JAR ファイルの絶対パス名を指定します。
データ型 | ストリング |
単位 | パス名 |
JVM コードのジャストインタイム (JIT) コンパイラー・オプションを使用不可にするかどうかを指定します。
JIT コンパイラーを使用不可にしている場合は、スループットが著しく減少します。したがって、 パフォーマンス上の理由から、JIT は使用可能のままにしてください。
データ型 | ブール |
デフォルト | false (JIT は使用可能) |
推奨 | JIT は使用可能 |
所定のオペレーティング・システムの JVM 設定を指定します。
基本 WebSphere Application Server および WebSphere Application Server - Express 製品では、プロセスは、開始時に、サーバーに関して指定された JVM 設定をオペレーティング・システムの JVM 設定として使用します。
データ型 | ストリング |
ガーベッジ・コレクションの冗長デバッグ出力を使用するかどうかを指定します。 デフォルトでは、冗長ガーベッジ・コレクションは使用可能ではありません。
データ型 | ブール |
デフォルト | false |
このフィールドが使用可能な場合、ガーベッジ・コレクターが稼働するたびに、出力ストリームにレポートが書き込まれます。 このレポートは、Java ガーベッジ・コレクションで何が起こっているかを伝えます。
83.29/3724.32 * 100 = 2.236%
GC に 5% を超える時間を費やし、GC が頻繁に発生している場合、 ご使用の Java ヒープ・サイズを増やす必要があります。
これを明らかにするには、%free を見ます。 数が減少し続けていないか確認します。%free が減少し続けている場合、GC から GC に 割り振られたヒープが徐々に増加しており、ご使用のアプリケーションにメモリー・リークがあることを示している可能性があります。