IBM の Java 仮想マシンの調整
アプリケーション・サーバーは Java™ ベースのサーバーです。このサーバーで稼働するエンタープライズ・アプリケーションを実行してサポートするには、Java 仮想マシン (JVM) 環境が必要です。 ご使用のアプリケーション・サーバーの構成として、Java SE ランタイム環境を構成し、パフォーマンスおよびシステム・リソース使用率を調整することができます。このトピックは、IBM® Java 仮想マシンを対象とします。
始める前に
- ご使用のアプリケーション・サーバーが稼働している JVM のタイプを判別します。
アプリケーション・サーバーの app_server_root/java/bin ディレクトリーから java –fullversion コマンドを実行します。
Java はこのコマンドに応答して、JVM プロバイダー情報を含む、JVM に関する情報をコマンドを実行したウィンドウに書き込みます。例えば、以下のようになります。
java full version "JRE 1.6.0 IBM Windows 32 build pwi3260sr7-20091217_01 (SR7)"
Java はこのコマンドに応答して、JVM プロバイダー情報を含む、JVM に関する情報を STDERR に書き込みます。
profile_root/bin ディレクトリーから dspwasinst コマンドを実行します。 このコマンドからの出力には JAVA_HOME 設定と、アプリケーション・サーバー・プロファイルに対して使用可能な JVM についてのその他の情報が含まれています。
ご使用のアプリケーションが Sun HotSpot JVM で稼働している場合は、トピック『Tuning Sun HotSpot Java virtual machines (Solaris & HP-UX)』を参照してください。
アプリケーション・サーバー・プロファイルを有効にして別の JVM を使用する場合は、managesdk コマンドを使用します。
以下のことを検証してください。
- サポート対応の最新バージョンの JVM がシステムにインストールされている。
- 最新のサービス更新がシステムにインストールされている。ほぼすべての新規サービス・レベルに、JVM パフォーマンスの改善が組み込まれます。
最新のサービス更新がシステムにインストールされていることを検証してください。ほぼすべての 新規サービス・レベルに、JVM パフォーマンスの改善が組み込まれます。
このタスクについて
JVM ベンダー各社は、それぞれの JVM のパフォーマンスおよび調整についての詳細情報を提供しています。 このトピックで提供される情報は、ご使用のシステムで稼働している JVM で提供される情報と併せてご利用ください。
コントローラーとサーバントにはどちらも JVM が含まれています。
このトピックに記載された情報は、サーバントの JVM のみに適用されます。
通常、コントローラーの JVM は調整する必要がありません。
Java SE ランタイム環境は、エンタープライズ・アプリケーションおよびアプリケーション・サーバーを実行するための環境を提供します。 したがって、アプリケーション・サーバーおよびそのサーバーで実行されるアプリケーションのパフォーマンスとシステム・リソース消費量の決定について、Java 構成は重要なロールを果たします。
Java バージョン 6.0 用の IBM 仮想マシンは最新の Java Platform, Enterprise Edition (Java EE) 仕様を含み、以前のバージョンの Java に比べてパフォーマンスと安定性が改善されました。
JVM 調整は使用する JVM プロバイダーに依存していますが、すべての JVM に該当する一般の調整概念もあります。 これらの一般概念には、以下のものがあります。
- コンパイラー調整。すべての JVM は、Just-In-Time (JIT) コンパイラーを使用して、サーバーの実行時に Java バイトコードをネイティブ命令にコンパイルします。
- Java メモリーまたはヒープ調整。JVM メモリー管理機能またはガーベッジ・コレクションの調整は、JVM のパフォーマンスを改善する第一歩です。
- クラス・ロード調整。
- 開始パフォーマンスとランタイム・パフォーマンスの最適化
以下のステップでは、JVM ごとに以下のタイプの調整を実行するための具体的な手順を示します。 これらのステップは、特定の順序で実行する必要はありません。
手順
特定の状況で出力されるダンプの数を制限します。
エラー状況によっては、複数のアプリケーション・サーバー・スレッドが失敗し、 その各スレッドに対して JVM が TDUMP を要求する可能性があります。膨大な数のスレッドが同時に失敗した場合、その結果多数の TDUMP が同時に取られ、補助ストレージの不足などのその他のシステム問題を引き起こす可能性があります。 JAVA_DUMP_OPTS 環境変数を使用して、特定の環境で JVM が出力するダンプの数を指定します。 この変数に指定する値は、アプリケーション・サーバーで実行中のアプリケーションからの com.ibm.jvm.Dump.SystemDump() 呼び出しによって生成されている TDUMPS の数には影響しません。
例えば、JVM を以下のように構成するとします。- TDUMP を取る数を 1 に制限する
- JAVADUMP を取る数を最大 3 に制限する
- INTERRUPT 発生時にはドキュメンテーションを収集しない
この場合、JAVA_DUMP_OPTS 変数は以下の値に設定します。JAVA_DUMP_OPTS=ONANYSIGNAL(JAVADUMP[3],SYSDUMP[1]),ONINTERRUPT(NONE)
- 始動パフォーマンスとランタイム・パフォーマンスを最適化します。
開発環境など一部の環境では、ランタイム・パフォーマンスではなく、アプリケーション・サーバーの開始パフォーマンスを最適化することがより重要です。 別の環境では、ランタイム・パフォーマンスを最適化することがより重要になります。 デフォルトで、IBM の Java 仮想マシンはランタイム・パフォーマンスが最適化されるのに対し、HotSpot ベースの JVM は始動パフォーマンスが最適化されます。
Java Just-in-Time (JIT) コンパイラーは、始動パフォーマンスが最適化されるのかランタイム・パフォーマンスが最適化されるのかに影響します。 コンパイラーで使用される初期の最適化レベルは、クラス・メソッドのコンパイルにかかる時間と、サーバーの始動にかかる時間に影響を与えます。 始動時の速度を速めるには、コンパイラーで使用される初期の最適化レベルを低くします。 ただし、初期の最適化レベルを低くすると、クラス・メソッドが低い最適化レベルでコンパイルされるため、アプリケーションのランタイム・パフォーマンスが低下する可能性があります。
- -Xquickstart
この設定値は、IBM Java 仮想マシンが低い最適化レベルをクラス・メソッド・コンパイルにどのように使用するのかに影響します。 最適化レベルを低くすると、サーバー開始時間が短縮されますが、ランタイム・パフォーマンスは低下します。 このパラメーターが指定されていない場合、IBM Java 仮想マシンはデフォルトでコンパイルに高い初期最適化レベルを使用して始動するため、ランタイム・パフォーマンスは向上しますが、サーバーの始動時間が長くなります。
このプロパティーは、管理コンソールを使用して「Java 仮想マシン」パネルで設定できます。詳しくは、Java 仮想マシンの設定に関する情報を参照してください。
通知 値 デフォルト 高い初期コンパイラー最適化レベル 推奨 高い初期コンパイラー最適化レベル 使用法 -Xquickstart を指定すると、サーバーの始動時間が短くなります。
JVM の初期化をスピードアップし、サーバーの始動時間を短くするには、「構成」タブの「一般プロパティー」セクションにある「汎用 JVM 引数」フィールドで、以下のコマンド行引数を指定します。
-Xquickstart -Xverify:none
- -Xquickstart
- ヒープ・サイズを構成します。
Java ヒープ・パラメーターは、ガーベッジ・コレクションの動作に影響します。ヒープ・サイズを増やすと、より多くのオブジェクトを作成することができます。大きなヒープは満杯になるまでに時間がかかるので、 ガーベッジ・コレクションが実行されるまでにアプリケーションが 稼働する時間が長くなります。 ただし、大きなヒープは圧縮にも時間がかかるので、ガーベッジ・コレクションの所要時間が長くなります。
JVM では、割り振られるストレージを管理するためにしきい値を使用します。 しきい値に達すると、ガーベッジ・コレクターが起動し、未使用のストレージを解放します。 そのため、ガーベッジ・コレクションが Java パフォーマンスの大幅な低下の原因となる場合があります。 初期ヒープ・サイズおよび最大ヒープ・サイズを変更する前に、以下の情報を 考慮する必要があります。- ほとんどの場合、最大 JVM ヒープ・サイズの値を、初期 JVM ヒープ・サイズよりも高く設定する必要があります。この設定により、JVM は通常の定常状態の期間に初期ヒープの範囲内で効率的に動作することができます。 また、この設定で、JVM はトランザクション量が大きい期間でも効率的に動作します。これは、JVM が最大 JVM ヒープ・サイズに指定された値までヒープを拡大することができるからです。 絶対的に最適なパフォーマンスが必要な場合は、初期ヒープ・サイズと最大ヒープ・サイズの両方を同じ値に設定しますが、このようなケースはめったにありません。 この設定により、JVM が JVM ヒープ・サイズを拡大または縮小する必要がある場合に生じるオーバーヘッドの一部が解消します。 JVM ヒープ・サイズのいずれかを変更する前に、JVM ストレージ割り振りが新しいヒープ・サイズに対応する十分な大きさであることを確認してください。
- ガーベッジ・コレクションを遅らせることで初期パフォーマンスが向上している間は、初期ヒープ・サイズをあまり大きく設定しないでください。ガーベッジ・コレクションが実行されると、収集プロセスに時間がかかり応答時間に影響があります。
Java ヒープ情報は SMF レコードに含まれており、DISPLAY,JVMHEAP コンソール・コマンドで動的に表示することができます。
管理コンソールを使用して、ヒープ・サイズを構成するには、次のようにします。
- 管理コンソールで、「サーバー」>「サーバー・タイプ」>「WebSphere Application Server」> 「server_name」とクリックします。
「サーバー・インフラストラクチャー」セクションで、「Java およびプロセス管理」>「プロセス定義」>「Java 仮想マシン」とクリックします。
「サーバー・インフラストラクチャー」セクションで、「Java およびプロセス管理」>「プロセス定義」とクリックします。
「コントロール」または「サーバント」のいずれかを選択してから、「Java 仮想マシン」を選択します。
- 「初期ヒープ・サイズ」または「最大ヒープ・サイズ」フィールドに新規の値を指定します。
両方の設定を調整する必要がある場合も、両方のフィールドで値を指定することができます。
パフォーマンス分析のためには、初期ヒープ・サイズと最大ヒープ・サイズを等しくします。
初期ヒープ・サイズの設定は、JVM が始動するときに JVM ヒープに割り振られるストレージの量をメガバイト単位で指定します。 最大ヒープ・サイズの設定は、JVM ヒープに割り振ることができるストレージの最大量をメガバイト単位で指定します。 これらの設定は、いずれもパフォーマンスに重大な影響を及ぼします。
実動システムを調整する場合に、そのシステム上で動作するエンタープライズ・アプリケーションの作業セット・サイズが不明なときは、まず初期ヒープ・サイズを、最大ヒープ・サイズの 25 % にしてみることをお勧めします。 これにより、JVM はヒープのサイズをアプリケーションの作業セットのサイズに適合させようとします。
次の図は、3 つの CPU プロファイルを示し、それぞれ固定ワークロードで Java ヒープ設定値を変えながら稼働しています。中央のプロファイルは、初期ヒープ・サイズと最大ヒープ・サイズが 128 MB に設定されています。ガーベッジ・コレクションは 4 回行われています。ガーベッジ・コレクションの合計時間は、合計実行時間の約 15 % です。ヒープ・パラメーターを倍の 256 MB にすると、一番上のプロファイルのように、ガーベッジ・コレクション間の作業時間が長くなります。 ガーベッジ・コレクションは 3 回しか行われませんが、それぞれのガーベッジ・コレクションの長さも増大しています。3 番目のプロファイルでは、ヒープ・サイズが 64 MB に削減され、逆の結果が示されています。ヒープ・サイズが小さくなると、ガーベッジ・コレクション間の時間と個々のガーベッジ・コレクションの時間は、どちらも短くなります。 これらの 3 つの構成すべてについて、ガーベッジ・コレクションの合計時間は約 15 % です。この例は、Java ヒープおよびそれとオブジェクト使用率との関係について重要な概念を示しています。エンタープライズ・アプリケーションの実行時は、常にガーベッジ・コレクションのコストが発生します。
一連のテストを、Java ヒープ設定値を変えながら実行します。例えば、 128 MB、192 MB、256 MB、および 320 MB で実験します。各実験の間、合計メモリー使用量をモニターします。 ヒープをあまり拡張しすぎると、ページングが起こります。
vmstat コマンドまたは Windows パフォーマンス・モニターを使用して、ページングが発生していないかどうかをチェックします。 ページングが起こったら、ヒープのサイズを減らすか、またはシステムにメモリーを追加してください。
IBM i WRKSYSSTS コマンドを使用して、ページングが発生していないかどうかを調べます。ページングが起こったら、ヒープのサイズを減らすか、またはシステムにメモリーを追加してください。
ページングが起こったら、ヒープのサイズを減らすか、またはシステムにメモリーを追加してください。
実行がすべて終了したら、以下の統計値を比較してください。- ガーベッジ・コレクションの呼び出し回数
- ガーベッジ・コレクション 1 回分の呼び出しの平均所要時間
- ガーベッジ・コレクション 1 回分の呼び出し時間の長さと、 呼び出し間の平均時間間隔の比率。
アプリケーションがオブジェクトを過剰に使用しておらず、 メモリー・リークもない場合は、メモリーの使用状況は定常状態に達しています。ガーベッジ・コレクションが実行される頻度も 少なく、所要時間も短く済みます。
ヒープのフリー・スペースが 85 % 以上で安定している場合は、アプリケーション・サーバーおよびアプリケーションが、ヒープに割り振られたメモリーをあまり使用していないため、ヒープ・サイズの最大値を小さくすることを検討してください。
64 ビット・モードで実行するように構成された サーバーがある場合、これらのサーバーにデフォルト設定より大幅に大きい JVM 最大ヒープ・サイズを 指定できます。 例えば、サーバーが 64 ビット・モードで実行するように構成されている場合、コントローラーおよびサーバントに対して初期最大ヒープ・サイズ 1844 MB を指定できます。
- 「適用」をクリックします。
- 「保存」をクリックして、マスター構成に対して行った変更を保存します。
- アプリケーション・サーバーを停止して再始動します。
以下のコマンド行パラメーターを使用して、これらの設定値を調整することもできます。 以下のパラメーターは、サポートされているすべての JVM に適用され、 各アプリケーション・サーバーまたはアプリケーション・サーバー・インスタンスの最小および最大ヒープ・サイズを 調整するために使用されます。
- -Xms
このパラメーターは Java ヒープの初期サイズを制御します。 このパラメーターを調整すると、ガーベッジ・コレクションのオーバーヘッドが削減され、サーバーの応答時間とスループットが改善されます。 アプリケーションによっては、このオプションのデフォルト設定は低すぎるため、多数の小さなガーベッジ・コレクションが発生します。
通知 値 デフォルト 50 MB 推奨 ワークロードに固有ですが、デフォルトより大きい値にします。 使用法 -Xms256m を指定すると、初期ヒープ・サイズが 256 MB に設定されます。 - -Xmx
このパラメーターは Java ヒープの最大サイズを制御します。 このパラメーターを大きな値に設定すると、アプリケーション・サーバーで使用可能なメモリーが増え、ガーベッジ・コレクションの頻度が小さくなります。 この設定を大きくすると、サーバーの応答時間およびスループットを改善することができます。 ただし、この設定を大きくすると、ガーベッジ・コレクションが発生した場合の所要時間も増加します。 この設定値は、アプリケーション・サーバー・インスタンスで使用可能なシステム・メモリーより高い値に設定しないでください。 使用可能なシステム・メモリーよりも設定値を大きくすると、システムのページングが発生し、パフォーマンスが著しく低下することがあります。
通知 値 デフォルト デフォルトで、JVM は、システムで使用可能なメモリーに基づいて Java ヒープ・サイズを動的に計算します。 推奨 使用可能な物理メモリー・サイズに応じて、ワークロード固有の、デフォルト値より 大きい値にします。 使用法 -Xmx512m を指定すると、最大ヒープ・サイズが 512 MB に設定されます。 トラブルの回避 (Avoid trouble): メモリー不足による問題が発生する可能性を少なくするために、 -Xmx パラメーターに値を指定してください。gotcha
-Xlp
このパラメーターは、IBM Java 仮想マシンで、16 MB のページのようなラージ・ページを使用する際のヒープを割り振るために使用します。このパラメーターを指定する前に、オペレーティング・システムがラージ・ページをサポートするように構成されていることを確認してください。 ラージ・ページを使用すると、ヒープ・メモリーの追跡に必要となる CPU オーバーヘッドを削減することができ、 より大きなヒープを作成することもできます。
デフォルト 64 KB (Java 8 を使用している場合) –Xlp64k
このパラメーターは、64 KB のような中間サイズのページを使用する際のヒープを割り振るために使用できます。アプリケーションが必要とするメモリーにこの仮想メモリー・ページ・サイズを使用すると、ラージ・ページ・サイズに関連したハードウェアが効率化されるため、アプリケーションのパフォーマンスおよびスループットを改善できます。
i5/OS™ および AIX® は、64 KB ページについて豊富なサポートを提供します。64 KB ページは汎用ページとして用いられるからです。64 KB ページは簡単に使用可能にすることができ、64 KB ページを使用すると、アプリケーションのパフォーマンスが向上します。この設定を変更する場合に、オペレーティング・システムの構成を変更する必要はありません。 ただし、64 KB ページを使用する場合は、アプリケーション・サーバーを別のストレージ・プールで実行することをお勧めします。
推奨 可能な限り、64 KB のページ・サイズを使用してください。 i5/OS POWER5+ システム、および i5/OS バージョン 6、リリース 1 は 64 KB ページ・サイズをサポートします。
POWER5+ システム、および 5300-04 推奨保守パッケージが適用された AIX 5L™ バージョン 5.3 は、64 ビット・カーネルを実行している場合に 64 KB ページ・サイズをサポートします。
–Xlp4k
このパラメーターは、4 KB ページのヒープを割り振る場合に使用できます。アプリケーションが必要とするメモリーに 64 KB の代わりにこの仮想メモリー・ページ・サイズを使用すると、ページ・サイズが小さくなることに伴ってハードウェアが非効率になるため、アプリケーションのパフォーマンスおよびスループットに悪影響が出る可能性があります。
Java ヒープ割り振りの設定は、オペレーティング・システム構成を変更せずに変更できます。 ただし、64 KB ページを使用する場合は、アプリケーション・サーバーを別のストレージ・プールで実行することをお勧めします。
推奨 可能な限り、-Xlp4k ではなく、-Xlp64k を使用してください。
- Java メモリーを調整します。 Java 言語で作成されたエンタープライズ・アプリケーションは、複雑なオブジェクト関係を持ち、多数のオブジェクトを使用します。 オブジェクトのライフ・サイクルに関連したメモリーは、Java 言語によって自動的に管理されますが、アプリケーションのオブジェクト使用パターンを理解することは重要です。特に、以下の状況であることを確認してください。
- アプリケーションが、オブジェクトを過剰に使用していない。
- アプリケーションが、オブジェクトをリークしていない。
- Java ヒープ・パラメーターが、指定したオブジェクトの使用パターンを処理するように適切に設定されている。
- オブジェクトの過剰使用の確認
Tivoli® Performance Viewer レポートに含まれている JVM ランタイムのカウンターを確認して、アプリケーションがオブジェクトを過剰使用しているかどうかを判別することができます。Java 仮想マシン・プロファイラー・インターフェース (JVMTI) カウンターを使用可能にするには、-XrunpmiJvmtiProfiler コマンド行オプションとともに、JVM モジュールの最大レベルも設定しなければなりません。
ガーベッジ・コレクション間の平均時間の最適な結果は、ガーベッジ・コレクション 1 回分の平均所要時間の少なくとも 5 倍から 6 倍です。 この数値に達しない場合、アプリケーションがガーベッジ・コレクションに費やす時間は、実行時間の 15 % を超えます。
JVM ランタイムのカウンターを監視することによって、アプリケーションがオブジェクトを乱用しているかどうかを確認できます。Java 仮想マシン・プロファイラー・インターフェース (JVMTI) カウンターを使用可能にするには、-XrunpmiJvmtiProfiler コマンド行オプションとともに、JVM モジュールの最大レベルも設定しなければなりません。ガーベッジ・コレクション間の平均時間の最適な結果は、ガーベッジ・コレクション 1 回分の平均所要時間の少なくとも 5 倍から 6 倍です。 この数値に達しない場合、アプリケーションがガーベッジ・コレクションに費やす時間は、実行時間の 15 % を超えます。
ガーベッジ・コレクションのボトルネックを示す情報がある場合、 ボトルネックを解消する方法は 2 つあります。 アプリケーションを最適化する最も経済的な方法は、オブジェクト・キャッシュとプールを実装することです。 Java プロファイラーを使用して、ターゲットにするオブジェクトを決定します。 アプリケーションを最適化できない場合は、メモリー、プロセッサー、およびクローンを追加してみてください。 メモリーを追加することによって、各クローンが妥当なヒープ・サイズを維 持できるようになります。プロセッサーを追加すると、 クローンを並列に実行できます。
- メモリー・リークがないかどうかテストします。
メモリー・リークは、Java 言語ではガーベッジ・コレクションのボトルネックの原因となる危険な状況です。 メモリー・リークは最終的にシステムの不安定性につながるため、メモリーの過剰使 用よりも有害です。時間が経過するにつれて、ガーベッジ・コレクションの発生頻度が高くなり、最終的にはヒープが使い尽くされて、Java コードは致命的なメモリー不足例外により停止します。 メモリー・リークは、使われていないオブジェクトが参照され、解放されないときに起こります。 メモリー・リークは、Hashtable などの集合クラスでよく発生します。 これは、この表が実際の参照情報が削除された後であっても、常にオブジェクトを参照していることが原因です。
ワークロードが高いと、アプリケーションが、実稼働環境でのデプロイメント直後に破損することが頻繁に起こります。アプリケーションでメモリー・リークが発生した場合、ワークロードが高いとリークの拡大が加速され、メモリーの割り振りに失敗する可能性があります。
メモリー・リークをテストする目的は、数を拡大することです。 メモリー・リークはほんの数バイトから数 K バ イトの大きさにすぎないため、ガーベッジ・コレクションでは検出されません。使用可能なメモリーと使用不能なメモリー の予期されるサイズを見分けることは、微妙な作業です。 数が増大してギャップが大きくなり、矛盾を簡単に認識できるようになれば、 この作業はもっと簡単になります。次のリストは、メモリー・リーク・テストの結果をどう解釈するかについて、説明しています。- 長期間実行するテスト
メモリー・リークの問題は、一定の期間を経てからでないと表面化しないため、メモリー・リークは長期間実行するテストでは検出されやすいと言えます。短期間実行するテストの場合は、メモリー・リークがどこで発生しているかについて、無効な表示が出ることがあります。 Java 言語では、いつメモリー・リークが発生しているかを認識しにくい場合があります。特に、メモリーの使用量が一定期間内に突然あるいは直線的に増加したように見える場合は判断が難しくなります。メモリー・リークの検出がむずかしいのは、このような増加が妥当なものであったり、開発者が意図的に行ったものであったりする可能性があるためです。 後になって使用されるオブジェクトと、まったく使用されないオブジェクトとを区別する方法は、アプリケーションを長期間実行していればわかってきます。 長期間実行するアプリケーションのテストでは、実際にオブジェクトが後になって使用されているかどうかについて、 より確信が持てるようになります。
- 反復テスト
多くの場合、同じテスト・ケースを続けて反復する場合に、メモリー・リークの問題が起こります。メモリー・リークのテストのゴー ルは、使用不能なメモリーと使用中のメモリーとの間で、相対的サイズに大きなギャッ プを作り出すことです。同じシナリオを何度も繰り返すことによって、このギャップは非常に累進的に増えていきます。このテストは、テスト・ケースの実行により発生するリーク数がごくわずかであるために、1 回の実行ではほとんど検出できないような場合に役立ちます。
反復テストは、システム・レベルまたはモジュール・レベルで使用できま す。モジュラー・テストの利点は、管理の点でより優れていることです。モジュールが、専用のモジュールを保持して、メモリーの使用など外部の副次作用が発生しないように設計されている場合、メモリー・リークのテストは簡単になります。最初に、モジュールを実行する前のメモリー使用量が記録されます。次に、固定セットのテスト・ケースが 繰り返し実行されます。テスト実行の終了時には、現在のメモリー使用量が記録され、顕著な変化がないかどうかチェックされます。実際のメモリー使用量を記録するときには、ガーベッジ・コレクションを行う必要があることを覚えておいてください。これを行うには、ガーベッジ・コレクションを実行したいモジュールに System.gc() を挿入するか、このイベントを強制的に発生させるプロファイル作成ツールを使用します。
- 並行性テスト
一部のメモリー・リーク問題は、アプリ ケーションでいくつかのスレッドが実行中の場合にのみ起こる可能性があります。 残念なことに、プログラム・ロジックの複雑さが増したため、同期点からメモリー・リークが発生することが非常に多くなっています。プログラミング時に注意を怠ると、参照が保持されたままになったり、解放されなくなったりする可能性があります。 メモリー・リークの問題は、システムの並行性が 増すことによって、促進されたり、加速されたりすることがよくあります。 並行性を高める最も一般的な方法は、テスト・ドライバー内のクライアント数を増やすことです。
メモリー・リークのテストで使用するテスト・ケースを選択するときには、以下の点を考慮してください。- 優れたテスト・ケースは、アプリケーションでオブジェクトが作成される領域を使用します。ほとんどの場合、アプリケーショ ンの知識が必要になります。シナリオの説明で、新規レコードの追加、HTTP セッションの作成、ト ランザクションの実行、およびレコードの検索などのような、データ・スペースの作成を 推奨している場合があります。
- オブジェクトのコレクションが使用されている領域を調べてください。通常、メモリー・リークは同じクラス内のオブジェクトから構成されています。また、対応する追加メソッドを呼び出すことによって、オブジェク トへの参照が暗黙的に保管される場所である、vector や hashtable などのコレクション ・クラスも一般的です。例えば、Hashtable オブジェクトのゲット・メソッドは、検索済みのオブジェクトへの参照を除去しません。
Tivoli Performance Viewer を使用すると、メモリー・リークの検出に役立ちます。
最適な結果を得るには、要求を 1,000 ページ、2,000 ページ、4,000 ページというように増やして期間を延ばしながら、実験を繰り返してください。Tivoli Performance Viewer のメモリー使用量のグラフは、ぎざぎざの形状になるはずです。 グラフの落ち込んでいる部分は、それぞれガーベッジ・コレクション に対応しています。 グラフに、次のいずれかの状態が発生した場合は、メモリー・リークが起こっています。
- それぞれのガーベッジ・コレクションの直後に、メモリー使用量が急激 に増加する。 この状態が発生すると、ぎざぎざのパターンはさらに階段のような形状になります。
- ぎざぎざのパターンが不規則な形状をしている。
- 割り振られたオブジェクト数と解放されたオブジェクト数の差が、時間の経過とともに増えている。
アプリケーション・サーバーの CPU 使用率が常に 100% 近くなっているときにヒープの消費がリークの可能性を示しているにもかかわらず、その後、ワークロードが軽減するかほとんどアイドル状態になったときにその現象が解消するのは、ヒープのフラグメント化が起きている兆候です。ヒープのフラグメント化は、JVM がガーベッジ・コレクションのサイクル中にメモリー割り振り要求を満たすために十分な量のオブジェクトを解放することができたとしても、ヒープ内の小さな空きメモリー域を圧縮して、連続した大きなスペースを作成する時間がない場合には、起こる可能性があります。
この他に、ヒープのフラグメント化は、512 バイト未満のオブジェクトが解放された場合にも起こります。オブジェクトが解放されても、ストレージは回復しません。この結果、ヒープ圧縮が実行されるまでメモリーのフラグメント化が進行します。
ヒープのフラグメント化は強制的に圧縮することによって削減できます。 ただし、強制的な圧縮が行われるとパフォーマンスが低下します。 Java -X コマンドを使用して、メモリー・オプションのリストを参照します。
- 長期間実行するテスト
- ガーベッジ・コレクションの調整
JVM は並列ガーベッジ・コレクターを使用して、大部分のガーベッジ・コレクション・サイクルの間に、SMP を最大限に活用します。
Java ガーベッジ・コレクションをテストすることによって、アプリケーションがどのようにメモリーを使用するかが理解できます。 ガーベッジ・コレクションは Java の長所です。アプリケーション作成者からメモリー管理の負担をなくすことによって、Java アプリケーションは、ガーベッジ・コレクション機能を持たない言語で作成されたアプリケーションよりも堅固になっています。 ただし、この堅固さが生かされるのは、アプリケーションがオブジェクトを 過剰に使用していない場合に限ります。 ガーベッジ・コレクションは通常、適切に機能するアプリケーションの合計実行時間の 5 から 20 % を消費します。 管理を行わない場合、ガーベッジ・コレクションはアプリケーションにとって最大のボトルネックの 1 つになります。
固定したワークロードが実行されている間にガーベッジ・コレクションをモニターすることによって、アプリケーションがオブジェクトを過剰使用しているかどうかを見極めることができます。 ガーベッジ・コレクションによって、メモリー・リークがあるかどうか検出することもできます。
JVM 設定を使用して、ガーベッジ・コレクションのタイプおよび動作を構成することができます。 連続スペースがないために JVM が現在のヒープからオブジェクトを割り振ることができない場合、ガーベッジ・コレクターが呼び出されて、使用されていない Java オブジェクトのメモリーが再利用されます。JVM ベンダーごとに、固有のガーベッジ・コレクター・ポリシーおよび調整パラメーターがあります。
管理コンソールで 「冗長ガーベッジ・コレクション」設定を使用して、ガーベッジ・コレクションのモニターを有効にすることができます。 この設定の出力には、クラス・ガーベッジ・コレクション統計が含まれます。 生成されるレポートのフォーマットは、異なる JVM またはリリース・レベルの間では標準化されません。
ご使用の JVM ガーベッジ・コレクションの設定を調整するには、次のようにします。
- 管理コンソールで、「サーバー」>「サーバー・タイプ」>「WebSphere Application Server」> 「server_name」とクリックします。
「サーバー・インフラストラクチャー」セクションで、「Java およびプロセス管理」>「プロセス定義」>「Java 仮想マシン」とクリックします。
「汎用 JVM 引数」フィールドに、変更する –X オプションを入力します。
「サーバー・インフラストラクチャー」セクションで、「Java およびプロセス管理」>「プロセス定義」>「サーバント」とクリックします。
「追加プロパティー」の下の「環境エントリー」をクリックします。
以下のように、IBM_JAVA_OPTIONS の環境エントリーを追加または更新します。
- IBM_JAVA_OPTIONS という既存の環境エントリーがある場合は、そのエントリーを編集して、既存の値に追加する –X Java オプションを追加します。
- それ以外の場合は、「新規」をクリックして、新規の環境エントリーを作成します。
フォームの個々のフィールドに以下の値を入力します。
通知 値 名前: IBM_JAVA_OPTIONS 値: 追加する –X Java オプション 説明: オプションの説明
この手順では、WebSphereApplication Server 構成ディレクトリー内の was.env ファイルを更新します。この変更によって、設定がサーバント、制御、および付属領域のすべてに適用されます。
- 「適用」をクリックします。
- 「保存」をクリックして、マスター構成に対して行った変更を保存します。
- アプリケーション・サーバーを停止して再始動します。
以下のリストでは、さまざまな JVM ガーベッジ・コレクターの –X オプションについて説明しています。
- IBM Java 仮想マシン・ガーベッジ・コレクター。
- IBM の Java ガーベッジ・コレクターの実装について詳しくは、IBM SDK, Java Technology Edition, Version 8 User Guide を参照してください。
Java -X オプションを使用して、メモリー・オプションのリストを表示します。
- -XgcpolicyIBM の Java 仮想マシンには、ガーベッジ・コレクション用の 4 つのポリシーが用意されています。 各ポリシーには固有の利点があります。注: 各ポリシーに固有の利点がありますが、WebSphere Application Server Version 8.0 以降の場合、デフォルトのガーベッジ・コレクション・ポリシーは gencon です。旧バージョンのアプリケーション・サーバーでは、デフォルトのガーベッジ・コレクション・ポリシーは optthruput です。
- gencon はデフォルト・ポリシーです。このポリシーは、世代的ガーベッジ・コレクターで機能します。この世代的な方式では、ガーベッジ・コレクションの収集休止時間を短縮するとともに、高スループットを実現します。 この目的を達成するために、ヒープは新旧のセグメントに分割されます。 存続時間が長いオブジェクトは古いスペースにプロモートされますが、存続時間が短いオブジェクトは新規スペースに格納されて短時間にガーベッジ・コレクションが実行されます。 gencon ポリシーは多くのアプリケーションにとって大きなメリットを提供します。ただし、すべてのアプリケーションにとって適切なわけではなく、一般に調整が難しくなります。
- optthruput は高いスループットを実現しますが、ガーベッジ・コレクションの休止時間が長くなります。すべてのアプリケーション・スレッドは、ガーベッジ・コレクション中にマーク、スイープ、および圧縮のために停止します (圧縮が必要な場合)。 ほとんどのアプリケーションでは、gencon ポリシーで十分に対応することができます。
- optavgpause は、アプリケーションの稼働中にガーベッジ・コレクションのマークおよびスイープ・フェーズを実行して、ガーベッジ・コレクションの休止時間を短縮するポリシーです。 このポリシーでは、スループット全体のパフォーマンスがわずかに低下します。
- subpool は、一般に使用プロセッサーが 8 つを超えるマルチプロセッサー・システムで、パフォーマンスを向上させるポリシーです。 このポリシーは IBM System i® System p および System z® の各プロセッサーでのみ、使用できます。subpool ポリシーは gencon ポリシーと似ていますが、ヒープがサブプールに分割されて、オブジェクト割り振りのスケーラビリティーが改善される点が異なります。
通知 値 デフォルト gencon 推奨 gencon 使用法 Xgcpolicy:gencon を指定すると、ガーベッジ・コレクション・ポリシーが gencon に設定されます。 gcpolicy を gencon に設定すると、並行マークが使用不可になります。 アプリケーション応答時間が安定せず、休止時間に問題があると考えられる場合を除き、gencon ポリシーを使用するとスループットが最適になります。
gcpolicy を optavgpause に設定すると、そのデフォルト値で並行マークが使用可能になります。この設定は、 通常のガーベッジ・コレクションによって発生する、アプリケーションの不安定な応答時間を緩和します。 ただし、このオプションはスループット全体を減少させる可能性があります。
- -Xnoclassgc
クラスのライブ・インスタンスが残されていない場合、デフォルトで、JVM はメモリーからクラスをアンロードします。 同じクラスを複数回ロードおよびアンロードするオーバーヘッドによって、パフォーマンスが低下する場合があります。
トラブルの回避 (Avoid trouble): -Xnoclassgc 引数を使用すると、クラス・ガーベッジ・コレクションを使用不可にできます。ただし、クラス・ガーベッジ・コレクションのパフォーマンスへの影響は通常ごくわずかです。Java Platform, Enterprise Edition (Java EE) ベースのシステムでクラス・ガーベッジ・コレクションをオフにすると、アプリケーションのクラス・ローダーが頻繁に使用されるため、事実上クラス・データのメモリー・リークが発生し、JVM でメモリー不足による例外がスローされます。
このオプションを使用して、アプリケーションを再デプロイする場合は、必ずアプリケーション・サーバーを再始動して、前のバージョンのアプリケーションからクラスと静的データをクリアする必要があります。
gotcha通知 値 デフォルト クラス・ガーベッジ・コレクションは使用可能です。 推奨 クラス・ガーベッジ・コレクションを使用不可にしないでください。
使用法 Xnoclassgc を指定して、クラス・ガーベッジ・コレクションを使用不可にします。
- -Xgcpolicy
- ローカル・ホスト名キャッシュの使用可能化 IBM SDK
for Java のデフォルトでは、静的メソッド
java/net/InetAddress.getLocalHost はその結果をキャッシュに入れません。この
メソッドは、WebSphere Application
Server 全体で使用されますが、特にデプロイメント・マネージャーやノード・エージェント
などの管理エージェントで使用されます。実行時にプロセスのローカル・ホスト・アドレスが
変更されない場合は、com.ibm.cacheLocalHost システム・プロパティーを設定してローカル・
ホスト検索用の組み込みキャッシュを使用することをお奨めします。
さまざまなタイプのプロセスでの JVM カスタム・プロパティーの設定については、
インフォメーション・センターでJava 仮想マシンのカスタム・プロパティーに関するトピックの
説明を参照してください。
トラブルの回避 (Avoid trouble): DHCP を使用して構成された サーバーのアドレスは、時間の経過とともに変わります。サーバーに静的に割り当てられる IP アドレスを使用している場合を除き、このプロパティーは設定しないでください。gotcha
通知 値 デフォルト com.ibm.cacheLocalHost = false 推奨 com.ibm.cacheLocalHost = true (説明を参照) 使用法 -Dcom.ibm.cacheLocalHost=true を指定すると、 getLocalHost キャッシュが使用可能になります。 - キャッシュ内のクラス共有の使用可能化
共有クラス・オプションにより、キャッシュでクラスを共有できます。 キャッシュでクラスを共有すると、起動時間が短縮され、メモリー占有スペースを縮小できます。 アプリケーション・サーバー、ノード・エージェントおよびデプロイメント・マネージャーなどのプロセスは、この共有クラス・オプションを使用できます。
このオプションは、アプリケーション・サーバーではデフォルトで使用可能に設定されています。 キャッシュをクリアするには、app_server_root/bin/clearClassCache ユーティリティーを呼び出すか、アプリケーション・サーバーを停止してから再始動します。
このオプションを使用すると、プロセスを使用していない場合にキャッシュをクリアする必要があります。 キャッシュをクリアするには、app_server_root/bin/clearClassCache.bat/sh ユーティリティーを呼び出すか、プロセスを停止してからそのプロセスを再始動します。
注: clearclasscache を使用している場合、キャッシュ全体をクリアするには、接続されているすべての JVM を停止する必要があります。特定のプロセスに対してクラス共有オプションを使用不可にする必要がある場合は、そのプロセスに汎用 JVM 引数 -Xshareclasses:none を指定します
- 管理コンソールで、「サーバー」>「サーバー・タイプ」>「WebSphere Application Server」> 「server_name」とクリックします。
「サーバー・インフラストラクチャー」セクションで、「Java およびプロセス管理」>「プロセス定義」>「Java 仮想マシン」とクリックします。
「サーバー・インフラストラクチャー」セクションで、「Java およびプロセス管理」>「プロセス定義」とクリックします。
「コントロール」または「サーバント」のいずれかを選択してから、「Java 仮想マシン」を選択します。
- 「汎用 JVM 引数」フィールドに、-Xshareclasses:none を入力します。
- 「OK」をクリックします。
- 「保存」をクリックして、マスター構成に対して行った変更を保存します。
- アプリケーション・サーバーを停止して再始動します。
通知 値 デフォルト 「キャッシュでのクラス共有」オプションは使用可能になっています。 推奨 キャッシュでのクラス共有オプションを使用可能のままにしておきます。 使用法 -Xshareclasses:none を指定すると、「キャッシュでのクラス共有」オプションが使用不可になります。 64 ビット環境での圧縮参照の使用可能化
64 ビット環境 (AIX 64、Linux PPC 64、zLinux 64、および Microsoft Windows AMD64、Linux AMD64 など) で圧縮参照を使用可能にできます。
また、IBM i 64 ビット環境 (IBM i バージョン 6.1 など) でも圧縮参照を使用可能にできます。
64 ビット Java SE ランタイム環境 (JRE) バージョン 6.0 の IBM 実装の圧縮参照オプションにより、すべてのメモリー参照を 32 ビット・サイズに制限することができます。一般に、64 ビット JVM はメモリーにアドレッシングするために 64 ビット幅のメモリー参照を使用するため、32 ビット JVM に比べ、より多くのヒープ・スペースを使用します。 64 ビット参照によってアドレッシング可能なヒープは、32 ビット・ヒープよりも桁違いに大きい数ですが、実際には、アドレッシングに 64 ビットすべてを必要とするヒープは通常必要ありません。 参照を圧縮するとアドレスのサイズが小さくなり、ヒープをより効率的に使用できます。 また、これらの参照を圧縮すると、プロセッサー・キャッシュとバス使用率が改善され、それによってパフォーマンスが上がります。
トラブルの回避 (Avoid trouble): gotcha
以下のプラットフォームでは、圧縮参照はサポートされていません。- HP-UX 64 ビット JVM
- iSeries Classic 64 ビット JVM
64 ビット JVM を圧縮参照モードで実行できるようにするには、WebSphereApplication Server 構成で新しい環境変数を指定する必要があります。 管理コンソールで以下を実行します。
- 「サーバー」>「サーバー・タイプ」>「WebSphere Application Server」> server_name をクリックします。
- 「構成」タブをクリックします。「サーバー・インフラストラクチャー」の下の 「Java およびプロセス管理」>「プロセス定義」>「サーバント」をクリックします。
- 「追加プロパティー」の下の「環境エントリー」をクリックします。以下のように、 IBM_JAVA_OPTIONS の環境エントリーを追加または更新します。
- IBM_JAVA_OPTIONS という既存の環境エントリーがある場合は、そのエントリーを編集して、既存の値に Java オプション -Xcompressedrefs を追加します。
- それ以外の場合は、「新規」をクリックして、新規の環境エントリーを作成します。
フォームの個々のフィールドに以下の値を入力します。
通知 値 名前: IBM_JAVA_OPTIONS 値: -Xcompressedrefs 説明: 64 ビット圧縮参照モードを使用可能にします
この手順では、WebSphereApplication Server 構成ディレクトリー内の was.env ファイルを更新します。この変更によって、設定がサーバント、制御、および付属領域のすべてに適用されます。
トラブルの回避 (Avoid trouble): Xcompressedrefs を汎用 JVM 引数として指定すると、WebSphereApplication Server は、サポートされない Java オプション・エラーのために開始されません。 アプリケーションで 30 GB を超える Java ヒープを必要とする場合は、64 ビットのデフォルト・モードを使用してください。gotcha
ヒープ・サイズ (-Xmx パラメーターで制御) が一定のヒープ・サイズ (プラットフォームによるが、25 GB 前後) 以下に設定されていれば、製品は、対応プラットフォーム上でのポインター圧縮をデフォルトで自動的に使用可能にします。そのように設定されていない場合は、非圧縮参照がデフォルトとなります。 ユーザーは以下のコマンド行オプションを使用して、これらのデフォルトをオーバーライドすることができます。
注: WebSphere Application Server for z/OS では、ポインター圧縮は自動的に有効になりません。 コマンド行オプションを使用して、ポインターの圧縮を手動で有効にするようにお奨めします。
注: Java 8 SR2 FP10、または z/OS Java 8 SR3 の場合、-Xcompressedrefs オプションはデフォルトで 57GB まで有効になっており、プラットフォームによってはさらに高い値で使用可能です。次のコマンド行オプションは圧縮参照フィーチャーを制御します。- -Xcompressedrefs
- このコマンド行オプションは圧縮参照フィーチャーを使用可能にします。このコマンド行オプションにより JVM が起動した場合は、ヒープにアドレッシングするのに 32 ビット幅メモリー参照が使用されます。 このフィーチャーは、-Xmx パラメーターで制御される一定のヒープ・サイズ (プラットフォームによるが、29 GB 前後) まで使用できます。
- -Xnocompressedrefs
- このコマンド行オプションは圧縮参照フィーチャーを明示的に使用不可にします。 このコマンド行オプションにより JVM が起動する場合は、ヒープにアドレッシングするのに全 64 ビット幅のメモリー参照が使用されます。 このオプションを使用すると、デフォルトで使用可能になっているポインター圧縮を必要に応じてオーバーライドすることができます。
- 大規模なセル構成の構成更新プロセスを調整します。 大規模なセル構成では、構成更新のパフォーマンスと整合性検査のどちらがより重要かを決定する必要があります。デプロイメント・マネージャーは、セル全体のマスター構成リポジトリーを 保守します。デフォルトで、製品は構成変更があると、ワークスペースの構成とマスター・リポジトリーを 比較して、ワークスペースの整合性を維持します。しかし、整合性検査プロセスを実行すると、構成変更の保存にかかる時間や、多数のアプリケーションのデプロイにかかる時間が長くなることがあります。必要となる時間に影響する要素は次のとおりです。
- セル内に定義されたアプリケーション・サーバーまたはクラスターが多ければ多いほど、構成変更の保存にかかる時間が長くなります。
- セル内にデプロイされたアプリケーションが多ければ多いほど、構成変更の保存にかかる時間が長くなります。
構成変更にかかる時間に問題がある場合は、JVM 設定に config_consistency_check カスタム・プロパティーを追加して、このプロパティーの値を false に設定します。- 管理コンソールで、 「システム管理」>「デプロイメント・ マネージャー」とクリックします。
- 「サーバー・インフラストラクチャー」の下で「Java およびプロセス管理」をクリックし、さらに「プロセス定義」をクリックします。
- 「追加プロパティー」において、 「Java 仮想マシン」>「カスタム・ プロパティー」>「新規」とクリックします。
- 「名前」フィールドに config_consistency_check を入力し、「値」フィールドに false と入力します。
- 「OK」をクリックし、マスター構成に対して行った変更を保存します。
- サーバーを再始動します。
サポートされる構成: config_consistency_check カスタム・プロパティーが 影響するのは、デプロイメント・マネージャーのプロセスのみです。ノード・エージェントやアプリケーション・サーバーなどの その他のプロセスには影響しません。これらのプロセスでは、整合性検査は実行されません。 しかし、これらのプロセス用の SystemOut.log ファイル内で、 整合性検査が無効であることを示す注記が表示されることがあります。 デプロイメント・マネージャー・プロセス以外のこれらのプロセスの場合、このメッセージは無視してかまいません。sptcfg
ローカル・モードで wsadmin コマンド wsadmin -conntype none を使用している場合は、このコマンドを実行する前に config_consistency_check プロパティーを false に設定する必要があります。
次のタスク


http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=tprf_tunejvm_v61
ファイル名:tprf_tunejvm_v61.html