アプリケーション・サーバーは Java ベースのプロセスであり、アプリケーション・サーバーで稼働する Java アプリケーションを実行およびサポートするには、Java 仮想マシン (JVM) 環境が必要です。 Java ランタイム環境を構成し、パフォーマンスおよびシステム・リソース使用率を 調整することができます。
z/OS プラットフォームでは、コントローラーとサーバントの両方に JVM があります。
ここに記載された情報は、サーバントの JVM に適用されます。
通常、コントローラーの JVM は調整する必要がありません。
Java ランタイム環境には、WebSphere Application Server などの Java ベース・アプリケーションおよびサーバーの実行環境が用意されています。 したがって、WebSphere Application Server およびそこで稼働するアプリケーションのパフォーマンスやシステム・リソース消費量を判別する場合に、Java 構成が重要な役割を果たします。
IBM Java 5.0 以上のバージョンの主な改良点は、IBM の初期 Java 実行テクノロジーのパフォーマンスおよび保守容易性を大幅に強化する仮想マシン・テクノロジーです。 この新規テクノロジーのについて詳しくは、http://www.ibm.com/software/webservers/appserv/was/performance.htmlを参照してください。
ご使用のアプリケーション・サーバーが稼働している JVM プロバイダーを判別するには、アプリケーション・サーバーの app_server_root/java/bin ディレクトリーから java –fullversion コマンドを発行します。 アプリケーション・サーバーはこのコマンドに応答して、JVM プロバイダー情報を含む、JVM に関する情報を SystemOut.log ファイルに書き込みます。
JVM 調整は使用する JVM プロバイダーに依存していますが、すべての JVM に該当する一般の調整概念もあります。 これらの一般概念には、以下のものがあります。
以下のステップでは、JVM ごとに以下のタイプの調整を実行するための具体的な手順を示します。 これらのステップは、特定の順序で実行する必要はありません。
Just-In-Time (JIT) コンパイラーは、必要に応じてメソッドごとにマシン・インストラクションを生成するプラットフォーム固有のコンパイラーです。 詳しくは、i5/OS インフォメーション・センターのトピック『IBM Developer Kit for Java』内の「Just-In-Time コンパイラーの使用』および『Just-In-Time コンパイラー』を参照してください。
デフォルト: | JIT は使用可能です。 |
推奨: | JIT コンパイラーを使用不可にしないで、完全な JIT コンパイラーを使用可能にすることをお勧めします (ステップ 4.d を参照)。 os400.jit.mmi.threshold はパフォーマンスに重大な影響を及ぼすことがあります。 JIT コンパイラーおよび os400.jit.mmi.threshold プロパティーについて詳しくは、i5/OS インフォメーション・センターのトピック『IBM Developer Kit for Java』内の『Just-In-Time コンパイラー』を参照してください。 |
「構成」タブの「一般プロパティー」セクションで、「JIT を使用不可にする」が選択されていないことを確認してください。
開発環境など一部の環境では、ランタイム・パフォーマンスではなく、アプリケーション・サーバーの開始パフォーマンスを最適化することがより重要です。 別の環境では、ランタイム・パフォーマンスを最適化することがより重要になります。 デフォルトで、IBM JVM はランタイム・パフォーマンスが最適化され、HotSpot ベース の JVM は開始パフォーマンスが最適化されています。
Java JIT コンパイラーは、開始およびランタイムのパフォーマンスが最適化されるかどうかに大きく影響します。 コンパイラーで使用される初期の最適化レベルは、クラス・メソッドのコンパイルにかかる時間と、 サーバーの開始にかかる時間に影響を与えます。 開始を速めるには、コンパイラーで使用される初期の最適化レベルを低くする必要があります。 ただし、初期の最適化レベルを低くすると、クラス・メソッドが低い最適化レベルでコンパイルされるため、アプリケーションのランタイム・パフォーマンスが低下する可能性があります。
この設定値は、IBM JVM が低い最適化レベルをクラス・メソッド・ コンパイルに使用する方法に影響します。最適化レベルを低くすると、サーバ開始時間が短縮されますが、ランタイム・パフォーマンスは低下します。 このパラメーターが 指定されていない場合、IBM JVM はデフォルトでコンパイルに高い初期最適化レベルを使用して開始するため、ランタイム・パフォーマンスは向上しますが、サーバーの開始時間が長くなります。
デフォルト: | 高い初期コンパイラー最適化レベル |
推奨: | 高い初期コンパイラー最適化レベル |
使用法: | -Xquickstart はサーバー開始時間を短縮します。 |
-Xquickstart -Xverify:none
HotSpot ベース JVM は、最初に低い最適化レベルでクラス・メソッドを
コンパイルします。以下の JVM オプションを使用して、この振る舞いを変更します。
Java ヒープ・パラメーターは、ガーベッジ・コレクションの動作に影響します。
ヒープ・サイズを増やすと、より多くのオブジェクトを作成することができます。大きなヒープは満杯になるまでに時間がかかるので、
ガーベッジ・コレクションが実行されるまでにアプリケーションが
稼働する時間が長くなります。
ただし、大きなヒープは圧縮にも時間がかかるので、ガーベッジ・コレクションの所要時間が長くなります。
ヒープ・サイズの設定により、i5/OS JVM のガーベッジ・コレクションが制御されます。
初期ヒープ・サイズは、新しいガーベッジ・コレクション・サイクルを起動するしきい値です。
例えば、初期ヒープ・サイズが 10 MB の場合、JVM が最後のコレクション・サイクル以降に 10 MB が割り振られたことを検出すると同時に、新しいコレクション・サイクルが起動されます。
ヒープ・サイズを小さくすると、サイズが大きい場合に比べて頻繁にガーベッジ・コレクションが実行されます。
最大ヒープ・サイズに達した場合は、ガーベッジ・コレクターが非同期の操作を停止し、ユーザー・スレッドがコレクション・サイクルが完了するまで待機するよう強制されます。
この状態は、パフォーマンスに重大な悪影響を与えます。
最大ヒープ・サイズが 0 (*NOMAX) の場合は、ガーベッジ・コレクションが常に非同期に実行されることになります。
最大ヒープ・サイズは、アプリケーションのパフォーマンスに影響を与えることがあります。
最大ヒープ・サイズは、ガーベッジ・コレクションされたヒープが消費できるオブジェクト・スペースの最大量を指定します。
最大ヒープ・サイズが小さすぎる場合は、パフォーマンスが大幅に低下するか、最大ヒープ・サイズに達したときにアプリケーションがメモリー不足エラーを受け取る可能性があります。
最大ヒープ・サイズの正しい値を決定することは困難であるため、ガーベッジ・コレクションされたヒープ・サイズのオブジェクト・スペースで絶対限度が必要でない限りは、値 0 (サイズの制限がないことを意味します) を使用することをお勧めします。
最大ヒープ・サイズの適切な値を決定する場合は、適切な値が各構成またはワークロードの組み合わせで異なるため、複数のテストを実行する必要があります。
ランナウェイ JVM を防止する場合は、最大ヒープ・サイズを予想されるサイズよりも大きく、かつ残りのマシンのパフォーマンスに影響を与えない大きさで設定します。
パフォーマンスに影響を与えることなく、最大ヒープ・サイズにより大きな値を指定できるため、JVM のリソース制限またはご使用のシステム構成の制限に基づいて、可能な限り最大の値を設定することをお勧めします。
最大ヒープ・サイズの適切な値を決定した後、JVM を実行するプールのセットアップまたは調整が必要になる場合があります。
デフォルトでは、WebSphere Application Server のジョブは基本システム・プール (WRKSYSSTS で示されるストレージ・プール 2) で実行されますが、別のプールを指定することもできます。
最大ヒープ・サイズは、JVM が実行されているプールのサイズの 125% より大きく設定しないようにします。
可能な限り、メモリーが永続的に割り振られた独自のメモリー・プールで JVM を実行することをお勧めします。
メモリー・プールを調整するためのパフォーマンス調整機構が設定されている (つまり、システム値 QPFRADJ が 0 以外の値に設定されている) 場合、WRKSHRPOOL を使用しているプールに対して最小値を指定することをお勧めします。
この最小値は、ガーベッジ・コレクションされたヒープ作業セットのサイズとほぼ等しくなります。
最大ヒープ・サイズを正しく設定し、メモリー・プールを正しく構成することで、JVM でシステム・リソースを消費するメモリー・リークを防止する一方で、優れたパフォーマンスを実現できます。
JVM を共用プールで実行する必要がある場合は、最大ヒープ・サイズの適切な値を決定することがさらに難しくなります。
プール内で実行されている他のジョブにより、ガーベッジ・コレクションされたヒープ・ページがプールからエージアウトされる可能性があります。
ガーベッジ・コレクションされたヒープ・ページがプールからエージアウトされた場合、ガーベッジ・コレクターは次のガーベッジ・コレクション・サイクルでそれらのページをプール内に戻す必要があります。これは、ガーベッジ・コレクターがガーベッジ・コレクションされたヒープ内のすべてのページにアクセスする必要があるためです。
i5/OS JVM では、ヒープを消去するためにすべての JVM スレッドが停止されないため、過度のページ不在は、ガーベッジ・コレクターのスローダウンおよびガーベッジ・コレクションされたヒープの増加を引き起こします。
ヒープのサイズは増加しますが、スレッドは引き続き実行されます。
ヒープ・サイズが所定のレベルを確実に超えることのない最大ヒープ・サイズを設定する必要がある場合は、初期ヒープ・サイズを最大ヒープ・サイズの 80% から 90% の大きさに指定します。
ただし、指定された値は、パフォーマンスに悪影響を与えないだけの十分な大きさにする必要があります。
developerWorks Web サイトで入手可能な「IBM Developer Kit and Runtime Environment, Java2 Technology Edition, Version 5.0 Diagnostics Guide」には、ヒープ・サイズ調整に関する追加情報が記載されています。
Java ヒープ情報は SMF レコードに含まれており、
コンソール・コマンド DISPLAY,JVMHEAP で動的に表示することができます。
管理コンソールを使用して、ヒープ・サイズを構成するには、次のようにします。
両方の設定を調整する必要がある場合も、両方のフィールドで値を指定することができます。
パフォーマンス分析のためには、初期ヒープ・サイズと最大ヒープ・ サイズを等しくします。
初期ヒープ・サイズの設定は、 ガーベッジ・コレクションの実行頻度を MB 単位で指定します。最大ヒープ・サイズの設定は、ガーベッジ・コレクションの実行頻度を指定します。 これらの設定は、いずれもパフォーマンスに重大な影響を及ぼします。
Java アプリケーションの作業セット・サイズが不明な実動システムを調整する場合は、
初期ヒープ・サイズを、まず、最大ヒープ・サイズの 25% にするとよいでしょう。
これにより、JVM はヒープのサイズをアプリケーションの作業セットのサイズに適合させようとします。
Java アプリケーションの作業セット・サイズが不明な実動システムを調整する場合は、
初期ヒープ・サイズをプロセッサー当たり 96 MB に設定することをお勧めします。
i5/OS JVM の合計ヒープ・サイズは、最後のガーベッジ・コレクションの終了時のライブ (使用中の) ヒープ・スペースの量と初期ヒープ・サイズの合計として概算できます。
この図は、3 つの CPU プロファイルを示し、 それぞれ固定ワークロードで Java ヒープ設定値を変えながら稼働しています。 中央のプロファイルでは、初期ヒープ・サイズと最大ヒープ・サイズは 128MB に設定されています。ガーベッジ・コレクションは 4 回行われています。ガーベッジ・コレクションの合計時間は、合計実行時間の約 15% です。 ヒープ・パラメーターを倍の 256MB にすると、一番上のプロファイルのように、 ガーベッジ・コレクション間の作業時間の長さが増えていきます。 ガーベッジ・コレクションは 3 回しか行われませんが、それぞれのガーベッジ・コレクションの長さも増大しています。3 番目のプロファイルでは、ヒープ・サイズが 64MB に削減され、逆の結果が示されています。ヒープ・サイズが小さくなると、ガーベッジ・コレクション間の時間と個々のガーベッジ・コレクションの時間は、どちらも短くなります。 これらの 3 つの構成すべてについて、ガーベッジ・コレクションの合計時間 は、約 15% です。 この例は、Java ヒープおよびそれとオブジェクト使用率との関係について重要な概念 を示しています。Java アプリケーションには、 常にガーベッジ・コレクションのコストがかかります。
ヒープのフリー・スペースが 85% 以上で安定している場合は、アプリケーション・サーバーおよびアプリケーションがヒープに割り振られたメモリーをあまり使用していないため、ヒープ・サイズの最大値を小さくすることを検討してください。
64 ビット・モードで実行するように構成された
サーバーがある場合、これらのサーバーにデフォルト設定より大幅に大きい JVM 最大ヒープ・サイズを
指定できます。
例えば、サーバーが 64 ビット・モードで実行するように構成されている場合、
コントローラーおよびサーバントに対して初期最大ヒープ・サイズ 1844m を
指定できます。
デフォルトの最大ヒープ・サイズは 0 であり、
これは最大値がないことを示します。最大ヒープ・サイズは変更しないことをお勧めします。最大ヒープ・サイズによってガーベッジ・コレクション・サイクルが起動すると、i5/OS JVM のガーベッジ・コレクションは非同期に動作を停止します。
この動作が起こると、アプリケーション・サーバーはガーベッジ・コレクション・サイクルが終了するまでユーザー・スレッドを処理できなくなり、パフォーマンスが大幅に低下します。
初期および最大ヒープ・サイズについて詳しくは、i5/OS インフォメーション・センターのトピック『Tuning Garbage Collection for Java and WebSphere on iSeries』を
参照してください。
以下のコマンド行パラメーターを使用して、これらの設定を調整することもできます。 以下のパラメーターは、サポートされているすべての JVM に適用され、 各アプリケーション・サーバーまたはアプリケーション・サーバー・インスタンスの最小および最大ヒープ・サイズを 調整するために使用されます。
この設定は、Java ヒープの初期サイズを制御します。 このパラメーターを適切に調整すると、ガーベッジ・コレクションのオーバーヘッドが削減され、 サーバーの応答時間とスループットが改善されます。 アプリケーションによっては、このオプションのデフォルト設定は低すぎるため、多数の小さなガーベッジ・コレクションが発生します。
デフォルト: | 50 MB。このデフォルト値は、31 ビットおよび 64 ビットの構成の両方に適用されます。 |
推奨: | ワークロードに固有ですが、デフォルトより大きい値にします。 |
使用法: | -Xms256m は初期ヒープ・サイズを 256 メガバイトに設定します。 |
この設定は、Java ヒープの最大サイズを制御します。 このパラメーターを大きな値に設定すると、アプリケーション・サーバーで使用可能なメモリーが増え、ガーベッジ・コレクションの頻度が小さくなります。 この設定を大きくすると、サーバーの応答時間およびスループットを改善することができます。 ただし、この設定を大きくすると、ガーベッジ・コレクションが発生した場合の所要時間も増加します。 この設定値は、アプリケーション・サーバー・インスタンスで使用可能なシステム・メモリーよりも大きな値に設定しないでください。 使用可能なシステム・メモリーよりも設定値を大きくすると、システムのページングが発生し、パフォーマンスが著しく低下することがあります。
デフォルト: | 256 MB。このデフォルト値は、31 ビットおよび 64 ビットの構成の両方に適用されます。 |
推奨: | ワークロードに固有ですが、使用可能な物理メモリー・サイズに応じてデフォルトより 大きい値にします。 |
使用法: | -Xmx512m は、最大ヒープ・サイズを 512 メガバイトに設定します。 |
この設定を IBM JVM で使用し、ラージ・ページ (16 MB) を使用してヒープを割り振ります。 ただし、この設定を使用する場合、ご使用のオペレーティング・システムが ラージ・ページをサポートするよう構成されている必要があります。 ラージ・ページを使用すると、ヒープ・メモリーの追跡に必要となる CPU オーバーヘッドを削減することができ、 より大きなヒープを作成することもできます。
オペレーティング・システムの調整についての詳細は、オペレーティング・システムの調整 を参照してください。
この設定を IBM JVM で使用すると、64 キロバイトのページ・サイズ (ミディアム・ページ) を使用してヒープを割り振ることができます。 アプリケーションに必要なメモリーにこの仮想メモリー・ページ・サイズを使用すると、ラージ・ページ・サイズに関連したハードウェアが効率化されるため、アプリケーションのパフォーマンスおよびスループットを改善できます。
64 KB のページ・サイズをサポートするには、管理コンソールで「サーバー」>「アプリケーション・サーバ」>「server_name」>「プロセス定義」>「環境エントリー」>「新規」をクリックしてから、「名前」フィールドで LDR_CNTRL を、「値」フィールドで DATAPSIZE=64K@TEXTPSIZE=64K@STACKPSIZE=64K を指定します。
AIX には、汎用の 64 KB ページに関する豊富なサポート機能があります。
64 KB ページは簡単に使用することができ、多くのアプリケーションではデフォルトの 4 KB ページでなく 64 KB ページを使用した場合に、パフォーマンスが向上すると予測されます。この設定を変更する場合に、オペレーティング・システムの構成を変更する必要はありません。
デフォルト: | 4 KB |
推奨: | -Xlp64k は 64 KB ページ・サイズをサポートします。![]() |
Tivoli Performance Viewer を使用して
、JVM ランタイムのカウンターを監視することによって、アプリケーションがオブジェクトを乱用しているかどうかを確認できます。Java 仮想マシン・プロファイラー・インターフェース (JVMPI) カウンターを
使用可能にするには、-XrunpmiJvmpiProfiler コマンド行オプションとともに
、JVM モジュールの最大レベルも設定しなければなりません。
JVMPI カウンターについて詳しくは、
Java 仮想マシン・プロファイラー・データの使用可能化
を参照してください。
Tivoli Performance Viewer を使用して
、JVM ランタイムのカウンターを監視することによって、アプリケーションがオブジェクトを乱用しているかどうかを確認できます。Java 仮想マシン・プロファイラー・インターフェース (JVMPI) カウンターを
使用可能にするには、-XrunpmiJvmpiProfiler コマンド行オプションとともに
、JVM モジュールの最大レベルも設定しなければなりません。
ガーベッジ・コレクション間の平均時間は、最もよい結果が出た場合で、ガーベッジ・コレクション 1 回分の平均所要時間の少なくとも 5 から 6 倍です。この数値に達しない場合、アプリケーションがガーベッジ・コレクションに費やす時間は、実行時間の 15% を超えています。
JVM ランタイムのカウンターを監視することによって、アプリケーションがオブジェクトを乱用しているかどうかを確認できます。Java 仮想マシン・プロファイラー・インターフェース (JVMPI) カウンターを
使用可能にするには、-XrunpmiJvmpiProfiler コマンド行オプションとともに
、JVM モジュールの最大レベルも設定しなければなりません。ガーベッジ・コレクション間の平均時間は、最もよい結果が出た場合で、ガーベッジ・コレクション 1 回分の平均所要時間の少なくとも 5 から 6 倍です。この数値に達しない場合、アプリケーションがガーベッジ・コレクションに費やす時間は、実行時間の 15% を超えています。
ガーベッジ・コレクションのボトルネックを示す情報がある場合、 ボトルネックを解消する方法は 2 つあります。 アプリケーションを最適化する最も経済的な方法は、オブジェクト・キャッシュとプールをインプリメントすることです。 Java プロファイラーを使用して、ターゲットにするオブジェクトを 決定します。アプリケーションを最適化できない場合は、メモリー、プロセッサー、およびクローンの追加が役に立つことがあります。 メモリーを追加することによって、各クローンが妥当なヒープ・サイズを維 持できるようになります。プロセッサーを追加すると、 クローンを並列に実行できます。
メモリー・リークは、Java 言語ではガーベッジ・コレクションのボトルネックの原因となる危険な状況です。 メモリー・リークは最終的にシステムの不安定性につながるため、メモリーの過剰使 用よりも有害です。時間が経過するにつれて、ガーベッジ・コレクションが頻繁に発生し、 最終的にはヒープが使い尽くされて、Java コードは致命的なメモリー不足例外により停止します。 メモリー・リークは、使われていないオブジェクトが参照され、解放されないときに起こります。 メモリー・リークは、Hashtable などの集合クラスでよく発生します。 これは、この表が実際の参照情報が削除された後であっても、常にオブジェクトを参照していることが原因です。
ワークロードが高いと、アプリケーションが、実稼働環境でのデプロイメント直後に破損することが頻繁に起こります。このような状況は、リークを起こしているアプリケーションで、ワークロードの高さがリークの拡大を加速し、メモリー割り振りの失敗が生じる場合に特に顕著です。
メモリー・リークの問題は、一定の期間を経てからでないと表面化しないため、メモリー・リークは長期間実行するテストでは検出されやすいと言えます。 短期間の稼働テストでは誤った警告を受ける可能性があります。Java 言語では、いつメモリー・リークが発生しているかを認識しにくい場合があります。メモリーの使用が突然に、あるいは一定の期間内に単調に増加したように見える場合には、特に判断がむずかしいでしょう。 メモリー・リークの検出がむずかしいのは、このような増加が妥当なものであったり、開発者が意図的に行ったものであったりする可能性があるためです。 後になって使用されるオブジェクトと、まったく使用されないオブジェクトとを区別する方法は、アプリケーションを長期間実行していればわかってきます。 長期間実行するアプリケーションのテストでは、実際にオブジェクトが後になって使用されているかどうかについて、 より確信が持てるようになります。
多くの場合、同じテスト・ケースを続けて反復する場合に、メモリー・リークの問題が起こります。メモリー・リークのテストのゴー ルは、使用不能なメモリーと使用中のメモリーとの間で、相対的サイズに大きなギャッ プを作り出すことです。同じシナリオを何度も繰り返すことによって、このギャップは非常に累進的に増えていきます。このテストは、テスト・ケースの実行により発生するリーク数がごくわずかであるために、1 回の実行ではほとんど検出できないような場合に役立ちます。
反復テストは、システム・レベルまたはモジュール・レベルで使用できま す。モジュラー・テストの利点は、管理の点でより優れていることです。モジュールが、専用のモジュールを保持して、メモリーの使用など外部の副次作用が発生しないように設計されている場合、メモリー・リークのテストは簡単になります。最初に、モジュールを実行する前のメモリー使用量が記録されます。次に、固定セットのテスト・ケースが 繰り返し実行されます。テスト実行の終了時には、現在のメモリー使用量が記録され、顕著な変化がないかどうかチェックされます。実際のメモリー使用量を記録するときには、ガーベッジ・コレクションを行う必要があることを覚えておいてください。これを行うには、ガーベッジ・コレクションを実行したいモジュールに System.gc() を挿入するか、このイベントを強制的に発生させるプロファイル作成ツールを使用します。
一部のメモリー・リーク問題は、アプリ ケーションでいくつかのスレッドが実行中の場合にのみ起こる可能性があります。 残念なことに、プログラム・ロジックの複雑さが増したため、同期点からメモリー・リークが発生することが非常に多くなっています。プログラミング時に注意を怠ると、参照が保持されたままになったり、解放されなかったりする可能性があります。メモリー・リークの問題は、システムの並行性が 増すことによって、促進されたり、加速されたりすることがよくあります。 並行性を高める最も一般的な方法は、テスト・ドライバー内のクライアント数を増やすことです。
Tivoli Performance Viewer を使用すると、メモリー・リークの検出に役立ちます。
ヒープの消費が、ワークロードが高いときにリークが起こった可能性を示している (アプリケーション・サーバーの CPU 使用率が常に 100% 近くなっている) のに、その後、ワークロードが低いかほとんどアイドル状態になったときにはヒープが回復するように見えるのは、ヒープのフラグメント化が起きている兆候です。ヒープのフラグメント化は、JVM がガーベッジ・コレクションのサイクル中にメモリー割り振り要求を満たすために十分な量のオブジェクトを解放することができたとしても、ヒープ内の小さな空きメモリー域を圧縮して、連続した大きなスペースを作成する時間がない場合には、起こる可能性があります。
この他に、ヒープのフラグメント化は、小さなオブジェクト (512 バイト未満) が解放された場合にも起こります。オブジェクトが解放されても、ストレージは回復しません。この結果、ヒープ圧縮が実行されるまでは、メモリーのフラグメント化が進みます。
ヒープのフラグメント化は圧縮を強制するによって削減できますが、これを行う場合パフォーマンス・ペナルティーがあります。
Java -X コマンドを使用して、メモリー・オプションのリストを参照します。
i5/OS JVM は、同時 (非同期) ガーベッジ・コレクションを使用します。
このタイプのガーベッジ・コレクションでは、休止時間が短くなり、アプリケーション・スレッドがガーベッジ・コレクション・サイクル中に要求の処理を継続できるようになります。
Java 仮想マシン (JVM) は、
並列ガーベッジ・コレクターを使用して、大部分のガーベッジ・コレクション・サイクルの間に、
SMP を最大限に活用します。HotSpot ベース JVM には、単一スレッドのガーベッジ・コレクターがあります。
Java ガーベッジ・コレクションをテストすることによって、 アプリケーションがどのようにメモリーを使用するかが理解できます。 ガーベッジ・コレクションは Java の強みです。アプリケーション作成者からメモリー管理の負担をなくす ことによって、Java アプリケーションは、ガーベッジ・コレクション機能を持たない言 語で作成されたアプリケーションよりも堅固になっています。ただし、この堅固さが生かされるのは、アプリケーションがオブジェクトを 過剰に使用していない場合に限ります。 ガーベッジ・コレクションは通常、適切に機能するアプリケーションの合計実行時間の 5% から 20% を消費します。管理を行わない場合、ガーベッジ・コレクションはアプリケーションにとって最大のボトルネックの 1 つになります。
固定ワークロードの実行中にガーベッジ・コレクションをモニターすることによって、 アプリケーションによるオブジェクトの使用が過剰になっているかどうかが分かります。 ガーベッジ・コレクションによって、メモリー・リークがあるかどうか検出することもできます。
JVM 設定を使用して、ガーベッジ・コレクションのタイプおよび動作を構成することができます。 連続スペースがないために JVM が現在のヒープからオブジェクトを割り振ることができない場合、ガーベッジ・コレクターが呼び出されて、使用されていない Java オブジェクトのメモリーが再利用されます。 JVM ベンダーごとに、固有のガーベッジ・コレクター・ポリシーおよび調整パラメーターがあります。
管理コンソールで Verbose ガーベッジ・コレクション設定を使用して、 ガーベッジ・コレクションのモニターを有効にすることができます。 この設定の出力には、クラス・ガーベッジ・コレクション統計が含まれます。 生成されるレポートのフォーマットは、異なる JVM またはリリース・レベルの間では標準化されません。
意味のある統計値を得るには、アプリケーションが定常状態になるまで固定ワークロードを実行します。
定常状態に達するまで、通常は数分かかります。
また、Tivoli Performance Viewer のオブジェクト統計を使用すると、ガーベッジ・コレクション統計をモニターできます。
ご使用の JVM ガーベッジ・コレクションの設定を調整するには、次のようにします。
以下のリストでは、さまざまな JVM ガーベッジ・コレクターの –X オプションについて 説明しています。
Java -X オプションを使用して、メモリー・オプションのリストを表示します。
デフォルト: | optthruput |
推奨: | optthruput |
使用法: | Xgcpolicy:optthruput は、ガーベッジ・コレクションを optthruput に設定します。 |
gcpolicy を optthruput に設定すると、並行マークが使用不可になります。 アプリケーション応答時間が安定せず、休止時間に問題があると考えられる場合を除き、optthruput ポリシーを使用するとスループットが最適になります。
gcpolicy を optavgpause に設定すると、そのデフォルト値で並行マークが使用可能になります。この設定は、 通常のガーベッジ・コレクションによって発生する、アプリケーションの不安定な応答時間を緩和します。 ただし、このオプションはスループット全体を減少させる可能性があります。
クラスのライブ・インスタンスが残されていない場合、デフォルトで、JVM はメモリーからクラスをアンロードします。 そのため、クラスをアンロードすると、パフォーマンスが低下することがあります。
-Xnoclassgc 引数を使用してクラス・ガーベッジ・コレクションを 使用不可にすることで、アプリケーションでクラスをさらに簡単に再利用できます。 クラス・ガーベッジ・コレクションをオフにすると、 同じクラスを複数回ロードおよびアンロードするオーバーヘッドが除去されます。
デフォルト: | クラス・ガーベッジ・コレクションは使用可能です。 |
推奨: |
|
使用法: | Xnoclassgc はクラス・ガーベッジ・コレクションを使用不可にします。 |
Solaris プラットフォームでは、アプリケーション・サーバーは IBM JVM でなく Sun HotSpot JVM で稼働します。 Sun JVM のパフォーマンス最適化フィーチャーを利用するために、Sun JVM で正しいチューニング・パラメーターを使用することが重要です。
Sun HotSpot JVM では、 世代ガーベッジ・コレクションによって、最適なパフォーマンスを実現します。 以下のコマンド行パラメーターは、ガーベッジ・コレクションの調整に便利です。
Java ヒープは、古い (長期間) オブジェクトのセクションと 若いオブジェクトのセクションに分割されます。 若いオブジェクトのセクションは、新規オブジェクトが割り振られるセクション (エデン) と、 使用中の新規オブジェクトが、古いオブジェクト (サバイバー・スペース) にプロモートされる前に、 最初のいくつかのガーベッジ・コレクションで存続しているセクションにさらに分割されます。 Survivor Ratio は、ヒープの若いオブジェクト・セクションでの、 サバイバー・スペースに対するエデンの比率です。 この設定を高くすると、アプリケーションでのオブジェクトの作成率を高くし、 オブジェクトの保持率を低くするよう JVM を最適化します。 WebSphere Application Server インスタンスは、他のアプリケーション・サーバーよりも中長期間のオブジェクトを生成するため、この設定はデフォルトより低くする必要があります。
デフォルト: | 32 |
推奨: | 16 |
使用法: | -XX:SurvivorRatio=16 |
永続世代に予約されたヒープのセクションは、JVM のすべての反射データを保持します。 このサイズは、動的に多くのクラスをロードおよびアンロードするアプリケーションのパフォーマンスを最適化するために増やす必要があります。 これを 128 MB に設定すると、ヒープのこの部分を増やす場合のオーバーヘッドが除去されます。
推奨: | 128 MB |
使用法: | XX:PermSize=128m は PermSize を 128 メガバイトに設定します。 |
この設定は、若い世代がヒープで消費することができるスペース量を制御します。 このパラメーターを適切に調整すると、ガーベッジ・コレクションのオーバーヘッドを削減でき、 サーバー応答時間とスループットが改善されます。 このデフォルト設定は通常は低すぎるため、多数の小さなガーベッジ・コレクションが発生します。 この設定値が高すぎると、JVM は主要な (フル) ガーベッジ・コレクションのみを実行することになります。 これらは通常、数秒かかり、サーバー全体のパフォーマンスに極めて有害な影響を及ぼします。 この状況を回避するには、この設定を全体のヒープ・サイズの半分以下に抑える必要があります。
デフォルト: | 2228224 バイト |
推奨: | 全ヒープ・サイズの約 1/4 |
使用法: | -Xmn256m はサイズを 256 メガバイトに設定します。 |
クラスのライブ・インスタンスが残されていない場合、デフォルトで、JVM はメモリーからクラスをアンロードしますが、 これはパフォーマンスを低下させることがあります。 クラス・ガーベッジ・コレクションをオフにすると、 同じクラスを複数回ロードおよびアンロードするオーバーヘッドが除去されます。
クラスが必要なくなった場合、そのクラスがヒープに占めていたスペースは通常、新規オブジェクトの作成に使用されます。 ただし、アプリケーションがクラスの新規インスタンスの作成による要求を処理し、 そのアプリケーションの要求が不定期に入って来る場合、 通常のクラス・ガーベッジ・コレクションは、前の要求側の終了後に、このクラスが属していたヒープ・スペースを 解放することによって、このクラスをクリーンアップします。 その結果、次の要求が来たときはクラスを再インスタンス化する必要があります。 この状態では、このオプションを使用して、クラスのガーベッジ・コレクションを使用不可にすることができます。
デフォルト: | クラス・ガーベッジ・コレクションは使用可能です。 |
推奨: | クラス・ガーベッジ・コレクションは使用不可です。 |
使用法: | Xnoclassgc はクラス・ガーベッジ・コレクションを使用不可にします。 |
Sun JVM の調整に関する追加情報については、「Performance Documentation for the Java HotSpot VM」を参照してください。
HP JVM では、 世代ガーベッジ・コレクションによって、最適なパフォーマンスを実現します。 以下のコマンド行パラメーターは、ガーベッジ・コレクションの調整に便利です。
この設定は、アプリケーションで短期間のオブジェクトを 多く生成するよう JVM を最適化します。 このパラメーターが指定されないと、JVM は通常、主要な (フル) ガーベッジ・コレクションを行います。 フル・ガーベッジ・コレクションは、数秒かかり、サーバー・パフォーマンスを大幅に低下させることがあります。
デフォルト: | off |
推奨: | on |
使用法: | -Xoptgc は最適化されたガーベッジ・コレクションを使用可能にします。 |
Java ヒープは、古い (長期間) オブジェクトのセクションと 若いオブジェクトのセクションに分割されます。 若いオブジェクトのセクションは、新規オブジェクトが割り振られるセクション (エデン) と、 使用中の新規オブジェクトが、古いオブジェクト (サバイバー・スペース) にプロモートされる前に、 最初のいくつかのガーベッジ・コレクションで存続しているセクションにさらに分割されます。 Survivor Ratio は、ヒープの若いオブジェクト・セクションでの、 サバイバー・スペースに対するエデンの比率です。 この設定を高くすると、アプリケーションでのオブジェクトの作成率を高くし、 オブジェクトの保持率を低くするよう JVM を最適化します。 WebSphere Application Server インスタンスは、他のアプリケーション・サーバーよりも中長期間のオブジェクトを生成するため、この設定はデフォルトより低くする必要があります。
デフォルト: | 32 |
推奨: | 16 |
使用法: | -XX:SurvivorRatio=16 |
永続世代に予約されたヒープのセクションは、JVM のすべての反射データを保持します。 このサイズは、動的に多くのクラスをロードおよびアンロードするアプリケーションのパフォーマンスを最適化するために増やす必要があります。 値 128 メガバイトを指定すると、ヒープのこの部分を増やすオーバーヘッドを除去します。
デフォルト: | 0 |
推奨: | 128 メガバイト |
使用法: | -XX:PermSize=128m は PermSize を 128 メガバイトに設定します。 |
このコマンドは遅延スワップ機能を使用不可にし、オペレーティング・システムが大きなメモリー・ページを 使用できるようにします。これにより、Java ヒープを構成するメモリーへのアクセスが最適化されます。 デフォルトで、Java ヒープでは遅延スワップ・スペースが割り振られます。 遅延スワップ機能を使用すると、メモリー・ページが必要に応じて割り振られるため、スワップ・スペースが節約されます。 ただし、遅延スワップ機能では強制的に 4 KB ページが使用されます。 このメモリー割り振りは、大きなヒープ・システムの多数のページわたってこのヒープを広げることができます。
デフォルト: | off |
推奨: | on |
使用法: | -XX:+ForceMmapReserved は遅延スワップ機能を使用不可にします。 |
この設定は、若い世代がヒープで消費することができるスペース量を制御します。 このパラメーターを適切に調整すると、ガーベッジ・コレクションのオーバーヘッドを削減でき、 サーバー応答時間とスループットが改善されます。 このデフォルト設定は通常は低すぎるため、多数の小さなガーベッジ・コレクションが発生します。
デフォルト: | デフォルトなし |
推奨: | 全ヒープ・サイズの約 3/4 |
使用法: | -Xmn768m はサイズを 768 MB に設定します。 |
Java 仮想マシンの命令およびデータ・ページ・サイズを 64 MB に設定すると、 パフォーマンスを改善できます。
デフォルト: | 4 MB |
推奨: | 64 MB |
使用法: | 以下のコマンドを使用します。このコマンド出力により、現行オペレーティング・システムの、
実行可能なプロセスの特性が提供されます。
chatr +pi64M +pd64M /opt/WebSphere/ AppServer/java/bin/PA_RISC2.0/ native_threads/java |
クラスのライブ・インスタンスが残されていない場合、デフォルトで、JVM はメモリーからクラスをアンロードしますが、 これはパフォーマンスを低下させることがあります。 クラス・ガーベッジ・コレクションをオフにすると、 同じクラスを複数回ロードおよびアンロードするオーバーヘッドが除去されます。
クラスが必要なくなった場合、そのクラスがヒープに占めていたスペースは通常、新規オブジェクトの作成に使用されます。 ただし、アプリケーションがクラスの新規インスタンスの作成による要求を処理し、 そのアプリケーションの要求が不定期に入って来る場合、 通常のクラス・ガーベッジ・コレクションは、前の要求側の終了後に、このクラスが属していたヒープ・スペースを 解放することによって、このクラスをクリーンアップします。 その結果、次の要求が来たときはクラスを再インスタンス化する必要があります。 この状態では、このオプションを使用して、クラスのガーベッジ・コレクションを使用不可にすることができます。
デフォルト: | クラス・ガーベッジ・コレクションは使用可能です。 |
推奨: | クラス・ガーベッジ・コレクションは使用不可です。 |
使用法: | Xnoclassgc はクラス・ガーベッジ・コレクションを使用不可にします。 |
HP 仮想マシンの調整に関する追加情報については、「Java technology
software HP-UX 11i」を参照してください。
-XX:SchedulerPriorityRange=SCHED_NOAGE -XX:-ExtraPollBeforeRead -XX:+UseSpinning
HP 仮想マシンの調整に関する追加情報については、「Java technology
software HP-UX 11i」を参照してください。
WebSphere Application Server が Solaris プラットフォームで使用する Java Virtual Machine は、クライアントとサーバーの 2 つのモードで動作します。 各モードにはそれぞれ利点があります。
再始動頻度が少ないアプリケーション・サーバーのパフォーマンスを最大にするには、HotSpot JVM をサーバー・モードで実行する必要があります。JVM がサーバー・モードの場合は、アプリケーション・サーバーが多数の要求を処理できる状態に達するまでの所要時間が数倍になります。 ただし、この状態に達すると、サーバー・モードはクライアント・モードで動作している JVM と比較してパフォーマンスが著しく向上します。
サーバー・モードで動作している HotSpot JVM は高レベルの最適化コンパイラーを使用して、初期ウォームアップ・ステージ中に Java コードを最適化および再最適化します。 この最適化作業をすべて実行するには時間がかかりますが、いったん JVM がウォームアップされると、同じハードウェアでのクライアント・モード動作に比べて、アプリケーション・サーバーは著しく高速に実行されます。
Java 5.0 の Solaris インプリメンテーションはご使用のハードウェアを調べて、環境に適した JVM モードを選択しようとします。 JVM がサーバー・レベル・マシンで稼働していると判別された場合、JVM では自動的にサーバー・モードが使用可能になります。 Java 1.4.2 以前の場合は、デフォルト・モードがクライアント・モードであるため、サーバー・モードを使用可能にするには、JVM コマンド行で -server フラグを使用する必要があります。
ご使用のマシンに少なくとも 2 つ以上の CPU および 2 GB のメモリーが搭載されている場合は、自動的にサーバー・モードが使用可能になるため、通常は JVM がデフォルトでサーバー・モードになります。 ただし、JVM が選択したモードが環境に適さない場合は、汎用 JVM 引数で -client および -server フラグを使用して、仮想マシンを強制的にいずれかのモードに設定することができます。
IBM Java 2 Runtime Environment (J2RE) バージョン 1.5.0 の共用クラス・オプションにより、キャッシュでクラスを共有できます。 キャッシュでクラスを共有すると、起動時間が短縮され、メモリー占有スペースを縮小できます。 アプリケーション・サーバー、ノード・エージェントおよびデプロイメント・マネージャーなどのプロセスは、この共有クラス・オプションを使用できます。
このオプションを使用すると、プロセスを使用していない場合にキャッシュをクリアする必要があります。 キャッシュをクリアするには、app_server_root/bin/clearClassCache.bat/sh ユーティリティーを呼び出すか、プロセスを停止してからそのプロセスを再始動します。
特定のプロセスに対してクラス共用オプションを使用不可にする必要がある場合は、そのプロセスに汎用 JVM 引数 -Xshareclasses:none を指定します
デフォルト: | キャッシュでのクラス共用オプションは使用可能です。 |
推奨: | キャッシュでのクラス共用オプションを使用可能のままにしておきます。 |
使用法: | -Xshareclasses:none はキャッシュでのクラス共用オプションを使用不可にします。 |
-client -XX:MaxPermSize=256m -XX:-UseLargePages -XX:+UseSerialGC
これらのパラメーターを設定することによって、スループットに影響を与え、わずかにサーバーの起動が遅くなる可能性があります。
かなり大容量のアプリケーションを実行している場合は、MaxPermSize 設定に、より大きな値を指定することができます。
-XX:-UseParallelGC –XX:-UseAdaptiveSizePolicyこれらのパラメーターを設定することによって、わずかにサーバーの起動が遅くなる可能性があります。
DB2 を使用する場合、HP JVM for HP-UX で SafepointPolling テクノロジーを 使用不可にすることを検討してください。Java スレッドの safepoint を確保するために開発された SafepointPolling テクノロジーを使用すると、WebSphere Application Server と DB2 データベース間でシグナル干渉を引き起こす可能性のあるシグナルが生成されます。 この干渉が発生すると、頻繁にデータベースのデッドロックが生じます。 -XX:-SafepointPolling オプションで JVM を起動し、ランタイム中の SafepoinPolling を使用不可にして、干渉が起こらないようにしてください。
ご使用のアプリケーションの始動時または最初の操作時に応答速度が遅い場合は、Java ユーザークラス・ローダー・キャッシュを使用することができます。詳しくは、ユーザー・クラス・ローダーによってあらかじめロード済みのクラスのキャッシング
を参照してください。