IBM の Java 仮想マシンの調整

アプリケーション・サーバーは、Java™ ベースのサーバーであり、そこで実行されるエンタープライズ・アプリケーションを実行およびサポートするために Java 仮想マシン (JVM) 環境を必要とします。 アプリケーション・サーバーの構成の一部として、パフォーマンスおよびシステム・リソースの使用量を調整するように Java SE ランタイム環境を構成できます。 このトピックは、Java 用の IBM® 仮想マシンに適用されます。

1. 特定の状況で取得されるダンプの数を制限します。

   エラー状況によっては、複数のアプリケーション・サーバー・スレッドが失敗し、 その各スレッドに対して 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) 

2. 始動パフォーマンスとランタイム・パフォーマンスを最適化します。

   開発環境など一部の環境では、ランタイム・パフォーマンスではなく、アプリケーション・サーバーの開始パフォーマンスを最適化することがより重要です。 別の環境では、ランタイム・パフォーマンスを最適化することがより重要になります。 デフォルトでは、Java 用の IBM 仮想マシンはランタイム・パフォーマンス用に最適化されていますが、 HotSpotベースの JVM は始動パフォーマンス用に最適化されています。

   Java ジャストインタイム (JIT) コンパイラーは、始動またはランタイム・パフォーマンスが最適化されるかどうかに影響します。 コンパイラーで使用される初期の最適化レベルは、クラス・メソッドのコンパイルにかかる時間と、サーバーの始動にかかる時間に影響を与えます。 始動時の速度を速めるには、コンパイラーで使用される初期の最適化レベルを低くします。 ただし、初期の最適化レベルを低くすると、 クラス・メソッドが低い最適化レベルでコンパイルされるため、 アプリケーションのランタイム・パフォーマンスが低下する可能性があります。

   • -Xquickstart

     この設定は、 IBM Virtual Machine for Java がクラス・メソッド・コンパイルのために縮小された最適化レベルをどのように使用するかに影響します。 最適化レベルが低いと、サーバーの始動が速くなりますが、実行時のパフォーマンスは低下します。 このパラメーターが指定されていない場合、Java 用の IBM 仮想マシンは、デフォルトで、コンパイル用の高い初期最適化レベルを使用して始動します。これにより、ランタイム・パフォーマンスは向上しますが、サーバーの始動は遅くなります。

     このプロパティーは、管理コンソールを使用して「Java 仮想マシン」パネルで設定できます。 詳しくは、Java 仮想マシン設定に関する情報を参照してください。

     情報	値
     デフォルト	高い初期コンパイラー最適化レベル
     推奨	高い初期コンパイラー最適化レベル
     使用法	-Xquickstart を指定すると、サーバーの始動時間が短くなります。

   JVM の初期化を高速化し、サーバーの起動時間を短縮するには、「構成」タブの「一般プロパティー」セクションにある 「一般 JVM 引数」 フィールドに、以下のコマンド行引数を指定します。

   -Xquickstart
   -Xverify:none

3. ヒープ・サイズを構成します。

   Java ヒープ・パラメーターは、ガーベッジ・コレクションの動作に影響します。 ヒープ・サイズを増やすと、より多くのオブジェクトを作成することができます。 大きなヒープは満杯になるまでに時間がかかるので、 ガーベッジ・コレクションが実行されるまでにアプリケーションが 稼働する時間が長くなります。 ただし、大きなヒープは圧縮にも時間がかかるので、ガーベッジ・コレクションの所要時間が長くなります。

   JVM では、割り振られるストレージを管理するためにしきい値を使用します。 しきい値に達すると、ガーベッジ・コレクターが起動し、未使用のストレージを解放します。 したがって、ガーベッジ・コレクションによって Java パフォーマンスが大幅に低下する可能性があります。 初期ヒープ・サイズおよび最大ヒープ・サイズを変更する前に、以下の情報を 考慮する必要があります。

   • ほとんどの場合、最大 JVM ヒープ・サイズの値を、初期 JVM ヒープ・サイズよりも高く設定する必要があります。 この設定により、JVM は通常の定常状態の期間に初期ヒープの範囲内で効率的に動作することができます。 また、この設定で、JVM はトランザクション量が大きい期間でも効率的に動作します。これは、JVM が最大 JVM ヒープ・サイズに指定された値までヒープを拡大することができるからです。 絶対的に最適なパフォーマンスが必要な場合は、初期ヒープ・サイズと最大ヒープ・サイズの両方を同じ値に設定しますが、このようなケースはめったにありません。 この設定により、JVM が JVM ヒープ・サイズを拡大または縮小する必要がある場合に生じるオーバーヘッドの一部が解消します。 JVM ヒープ・サイズのいずれかを変更する前に、JVM ストレージ割り振りが新しいヒープ・サイズに対応する十分な大きさであることを確認してください。
   • ガーベッジ・コレクションを遅らせることで初期パフォーマンスが向上している間は、初期ヒープ・サイズをあまり大きく設定しないでください。ガーベッジ・コレクションが実行されると、収集プロセスに時間がかかり応答時間に影響があります。

   Java ヒープ情報は SMF レコードに含まれており、 DISPLAY,JVMHEAP コンソール・コマンドを使用して動的に表示できます。

   管理コンソールを使用して、ヒープ・サイズを構成するには、次のようにします。

   1. 管理コンソールで、 「サーバー」>「サーバー・タイプ」>「 WebSphere アプリケーション・サーバー」> サーバー名をクリックします。
   2. 「サーバー・インフラストラクチャー」セクションで、 「Java およびプロセス管理」>「プロセス定義」>「Java 仮想マシン」をクリックします。
   3. 「サーバー・インフラストラクチャー」セクションで、 「Java およびプロセス管理」>「プロセス定義」をクリックします。
   4. 「制御」 または 「サーバント」を選択し、 「Java 仮想マシン」を選択します。
   5. 「初期ヒープ・サイズ」 または 「最大ヒープ・サイズ」 フィールドに新しい値を指定します。

      両方の設定を調整する必要がある場合も、両方のフィールドで値を指定することができます。

      パフォーマンス分析のためには、初期ヒープ・サイズと最大ヒープ・サイズを等しくします。

      初期ヒープ・サイズの設定は、JVM が始動するときに JVM ヒープに割り振られるストレージの量をメガバイト単位で指定します。 最大ヒープ・サイズの設定は、JVM ヒープに割り振ることができるストレージの最大量をメガバイト単位で指定します。 これらの設定は、いずれもパフォーマンスに重大な影響を及ぼします。

      実動システムを調整する場合に、そのシステム上で動作するエンタープライズ・アプリケーションの作業セット・サイズが不明なときは、まず初期ヒープ・サイズを、最大ヒープ・サイズの 25 % にしてみることをお勧めします。 これにより、JVM はヒープのサイズをアプリケーションの作業セットのサイズに適合させようとします。

      次の図は、3 つの CPU プロファイルを表しており、それぞれがさまざまな Java ヒープ設定を持つ固定ワークロードを実行しています。 2 番目のプロファイルでは、初期ヒープ・サイズと最大ヒープ・サイズは 128 MB に設定されています。 ガーベッジ・コレクションは 4 回行われています。 ガーベッジ・コレクションの合計時間は、合計実行時間の約 15 % です。 ヒープ・パラメーターを倍の 256 MB にすると、1 番目のプロファイルのように、ガーベッジ・コレクション間の作業時間の長さが増えていきます。 ガーベッジ・コレクションは 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 を指定できます。

   6. 「適用」をクリックする。
   7. 変更内容を構成リポジトリーに保存するには、 「保存」 をクリックします。
   8. アプリケーション・サーバーを停止して再始動します。

   以下のコマンド行パラメーターを使用して、これらの設定値を調整することもできます。 以下のパラメーターは、サポートされているすべての JVM に適用され、 各アプリケーション・サーバーまたはアプリケーション・サーバー・インスタンスの最小および最大ヒープ・サイズを 調整するために使用されます。

   • -Xms

     このパラメーターは、Java ヒープの初期サイズを制御します。 このパラメーターを調整すると、ガーベッジ・コレクションのオーバーヘッドが削減され、サーバーの応答時間とスループットが改善されます。 アプリケーションによっては、このオプションのデフォルト設定は低すぎるため、多数の小さなガーベッジ・コレクションが発生します。

     情報	値
     デフォルト	50 MB
     推奨	ワークロードに固有ですが、デフォルトより大きい値にします。
     使用法	-Xms256m を指定すると、初期ヒープ・サイズが 256 MB に設定されます。

   • -Xmx

     このパラメーターは、Java ヒープの最大サイズを制御します。 このパラメーターを大きな値に設定すると、アプリケーション・サーバーで使用可能なメモリーが増え、ガーベッジ・コレクションの頻度が小さくなります。 この設定を大きくすると、サーバーの応答時間およびスループットを改善することができます。 ただし、この設定を大きくすると、ガーベッジ・コレクションが発生した場合の所要時間も増加します。 この設定は、アプリケーション・サーバー・インスタンスに使用可能なシステム・メモリーを超えて増やさないでください。 使用可能なシステム・メモリーを超えて設定を増やすと、システム・ページングが発生し、パフォーマンスが大幅に低下する可能性があります。

     情報	値
     デフォルト	デフォルトでは、JVM はシステム内の使用可能メモリーに基づいて Java ヒープ・サイズを動的に計算します。
     推奨	使用可能な物理メモリー・サイズに応じて、ワークロード固有の、デフォルト値より 大きい値にします。
     使用法	-Xmx512m を指定すると、最大ヒープ・サイズが 512 MB に設定されます。

     問題の回避: -Xmx パラメーターに値を指定して、メモリー不足の問題が発生する可能性を減らします。
   • -Xlp

     このパラメーターを IBM Virtual Machine for Java で使用して、16 MB ページなどのラージ・ページを使用する場合にヒープを割り振ります。 このパラメーターを指定する前に、オペレーティング・システムがラージ・ページをサポートするように構成されていることを確認してください。 ラージ・ページを使用すると、ヒープ・メモリーの追跡に必要となる CPU オーバーヘッドを削減することができ、 より大きなヒープを作成することもできます。

     デフォルト
     64 KB (Java 6 SR 7 以降を使用している場合) Java 6 SR 6 以前を使用している場合は 4 KB

   • -Xlp64k

     このパラメーターは、64 KB のような中間サイズのページを使用する際のヒープを割り振るために使用できます。 アプリケーションが必要とするメモリーにこの仮想メモリー・ページ・サイズを使用すると、ラージ・ページ・サイズに関連したハードウェアが効率化されるため、アプリケーションのパフォーマンスおよびスループットを改善できます。

     i5/OS および AIX® では、64 KB ページは汎用ページとして意図されているため、64 KB ページについて豊富なサポートを提供しています。 64 KB ページは簡単に使用可能にすることができ、64 KB ページを使用すると、アプリケーションのパフォーマンスが向上します。 Java 6 SR 7 から、Java ヒープは、デフォルトで 64K ページを使用して割り振られます。 Java 6 SR 6 以前の場合は、4K ページがデフォルト設定です。この設定は、オペレーティング・システムの構成を変更せずに変更できます。 ただし、64 KB ページを使用する場合は、アプリケーション・サーバーを別のストレージ・プールで実行することをお勧めします。

     Java 6 SR 6 以前を使用している場合、64 KB ページ・サイズをサポートするには、管理コンソールで 「サーバー」>「アプリケーション・サーバー」> server_name >「プロセス定義」>「環境エントリー」>「新規」とクリックし、 「名前」 フィールドに LDR_CNTRL を指定し、 「値」 フィールドに DATAPSIZE=64K@TEXTPSIZE=64K@STACKPSIZE=64K を指定します。

     推奨
     可能な限り、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 6 SR 7 以降、Java ヒープにはデフォルトで 64K ページが割り振られます。 Java 6 SR 6 以前の場合は、4K ページがデフォルト設定です。この設定は、オペレーティング・システムの構成を変更せずに変更できます。 ただし、64 KB ページを使用する場合は、アプリケーション・サーバーを別のストレージ・プールで実行することをお勧めします。

     Java 6 SR 7 以上を使用している場合、4 KB ページ・サイズをサポートするには、管理コンソールで、 「サーバー」>「アプリケーション・サーバー」> server_name >「プロセス定義」>「環境エントリー」>「新規」をクリックし、 「名前」 フィールドに LDR_CNTRL を指定し、 「値」 フィールドに DATAPSIZE=4K@TEXTPSIZE=4K@STACKPSIZE=4K を指定します。

     推奨
     可能な限り、-Xlp4k ではなく、-Xlp64k を使用してください。

4. Java メモリーを調整します。
   Java 言語で作成されたエンタープライズ・アプリケーションは、複雑なオブジェクト関係を持ち、多数のオブジェクトを使用します。 Java 言語はオブジェクトのライフ・サイクルに関連したメモリーを自動的に管理しますが、オブジェクトのアプリケーション使用パターンを理解することは重要です。 特に、以下の状況であることを確認してください。

   • アプリケーションが、オブジェクトを過剰に使用していない。
   • アプリケーションが、オブジェクトをリークしていない。
   • Java ヒープ・パラメーターが、指定されたオブジェクト使用パターンを処理するように適切に設定されている。
   1. オブジェクトの過剰使用の確認

      Tivoli ® Performance Viewer レポートに組み込まれている JVM ランタイムのカウンターを検討して、アプリケーションがオブジェクトを過剰に使用しているかどうかを判別することができます。 Java 仮想マシン・プロファイラー・インターフェース (JVMTI) カウンターを使用可能にするには、 -XrunpmiJvmtiProfiler コマンド行オプションと、JVM モジュールの最大レベルを指定する必要があります。

      ガーベッジ・コレクション間の平均時間の最適な結果は、単一のガーベッジ・コレクションの平均所要時間の少なくとも 5 倍から 6 倍です。 この数値に達しない場合、アプリケーションがガーベッジ・コレクションに費やす時間は、実行時間の 15 % を超えます。

      JVM ランタイムのカウンターを監視することによって、アプリケーションがオブジェクトを乱用しているかどうかを確認できます。 Java 仮想マシン・プロファイラー・インターフェース (JVMTI) カウンターを使用可能にするには、 -XrunpmiJvmtiProfiler コマンド行オプションと、JVM モジュールの最大レベルを指定する必要があります。 ガーベッジ・コレクション間の平均時間の最適な結果は、ガーベッジ・コレクション 1 回分の平均所要時間の少なくとも 5 倍から 6 倍です。 この数値に達しない場合、アプリケーションがガーベッジ・コレクションに費やす時間は、実行時間の 15 % を超えます。

      ガーベッジ・コレクションのボトルネックを示す情報がある場合、 ボトルネックを解消する方法は 2 つあります。 アプリケーションを最適化する最も経済的な方法は、オブジェクト・キャッシュとプールを実装することです。 Java プロファイラーを使用して、ターゲットにするオブジェクトを決定します。 アプリケーションを最適化できない場合は、メモリー、プロセッサー、およびクローンを追加してみてください。 メモリーを追加することによって、各クローンが妥当なヒープ・サイズを維 持できるようになります。 プロセッサーを追加すると、 クローンを並列に実行できます。

   2. メモリー・リークがないかどうかテストします。

      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 コマンドを使用します。

5. ガーベッジ・コレクションの調整

   JVM は並列ガーベッジ・コレクターを使用して、大部分のガーベッジ・コレクション・サイクルの間に、SMP を最大限に活用します。

   Java ガーベッジ・コレクションを調べると、アプリケーションがメモリーをどのように使用しているかについての洞察が得られます。 ガーベッジ・コレクションは Java の強度です。 アプリケーション作成者からメモリー管理の負担を奪うことにより、Java アプリケーションは、ガーベッジ・コレクションを提供しない言語で作成されたアプリケーションよりも堅固になります。 ただし、この堅固さが生かされるのは、アプリケーションがオブジェクトを 過剰に使用していない場合に限ります。 ガーベッジ・コレクションは通常、適切に機能するアプリケーションの合計実行時間の 5 から 20 % を消費します。 管理を行わない場合、ガーベッジ・コレクションはアプリケーションにとって最大のボトルネックの 1 つになります。

   固定したワークロードが実行されている間にガーベッジ・コレクションをモニターすることによって、アプリケーションがオブジェクトを過剰使用しているかどうかを見極めることができます。 ガーベッジ・コレクションによって、メモリー・リークがあるかどうか検出することもできます。

   JVM 設定を使用して、ガーベッジ・コレクションのタイプおよび動作を構成することができます。 連続したスペースがないために JVM が現行ヒープからオブジェクトを割り振ることができない場合、使用されなくなった Java オブジェクトからメモリーを再利用するためにガーベッジ・コレクターが呼び出されます。 JVM ベンダーごとに、固有のガーベッジ・コレクター・ポリシーおよび調整パラメーターがあります。

   管理コンソールで 「冗長ガーベッジ・コレクション」設定を使用して、ガーベッジ・コレクションのモニターを有効にすることができます。 この設定の出力には、クラス・ガーベッジ・コレクション統計が含まれます。 生成されるレポートのフォーマットは、異なる JVM またはリリース・レベルの間では標準化されません。

   ご使用の JVM ガーベッジ・コレクションの設定を調整するには、次のようにします。

   1. 管理コンソールで、 「サーバー」>「サーバー・タイプ」>「 WebSphere アプリケーション・サーバー」> サーバー名をクリックします。
   2. 「サーバー・インフラストラクチャー」セクションで、 「Java およびプロセス管理」>「プロセス定義」>「Java 仮想マシン」 をクリックします。
   3. 変更する -X オプションを 「汎用 JVM 引数」 フィールドに入力してください。
   4. 「サーバー・インフラストラクチャー」セクションで、 「Java およびプロセス管理」>「プロセス定義」>「サーバント」をクリックします。
   5. 「追加プロパティー」の下の「 環境エントリー」をクリックします。
   6. IBM_JAVA_OPTIONS の環境エントリーを以下のように追加または更新します。
      1. IBM_JAVA_OPTIONS という名前の既存の環境エントリーがある場合は、そのエントリーを編集して、既存の値に追加する -X Java オプションを追加します。
      2. それ以外の場合は、「新規」をクリックして、新規の環境エントリーを作成します。 フォームの個々のフィールドに以下の値を入力します。

         情報	値
         名前:	IBM_JAVA_OPTIONS
         値:	追加する Java オプション ( -X J)
         説明:	オプションの説明

      この手順では、 WebSphereApplication Server 構成ディレクトリー内の was.env ファイルを更新します。 この変更によって、設定がサーバント、制御、および付属領域のすべてに適用されます。

   7. 「適用」をクリックする。
   8. 変更内容を構成リポジトリーに保存するには、 「保存」 をクリックします。
   9. アプリケーション・サーバーを停止して再始動します。

   以下のリストでは、-Xさまざまな JVM ガーベッジ・コレクターのオプション。

   Java ガーベッジ・コレクター用の IBM 仮想マシン。

   Java ガーベッジ・コレクターの IBM 実装の完全なガイドは、「 IBM SDK, Java Technology Edition, Version 8 User Guide」に記載されています。

   メモリー・オプションのリストを表示するには、Java -X オプションを使用します。

   • -Xgcpolicy
     IBM Virtual Machine for Java は、ガーベッジ・コレクションのための 4 つのポリシーを提供します。 各ポリシーには固有の利点があります。

     注: 各ポリシーには固有の利点がありますが、 WebSphere Application Server バージョン 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 は常にメモリーからそのクラスをアンロードします。 同じクラスを複数回ロードおよびアンロードするオーバーヘッドによって、パフォーマンスが低下する場合があります。

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

     このオプションを使用して、アプリケーションを再デプロイする場合は、必ずアプリケーション・サーバーを再始動して、前のバージョンのアプリケーションからクラスと静的データをクリアする必要があります。

     情報	値
     デフォルト	クラス・ガーベッジ・コレクションは使用可能です。
     推奨	クラス・ガーベッジ・コレクションを使用不可にしないでください。
     使用法	Xnoclassgc を指定して、クラス・ガーベッジ・コレクションを使用不可にします。

6. ローカル・ホスト名のキャッシングを使用可能にする
   IBM SDK for Java では、デフォルトで、静的メソッド java/net/InetAddress.getLocalHost はその結果をキャッシュしません。 このメソッドは、 WebSphere Application Server全体で使用されますが、特にデプロイメント・マネージャーやノード・エージェントなどの管理エージェントで使用されます。 実行時にプロセスのローカル・ホスト・アドレスが 変更されない場合は、com.ibm.cacheLocalHost システム・プロパティーを設定してローカル・ ホスト検索用の組み込みキャッシュを使用することをお奨めします。 さまざまなタイプのプロセスで JVM カスタム・プロパティーを設定する手順については、Java 仮想マシンのカスタム・プロパティーのトピックを参照してください。

   トラブルの回避: DHCP を使用して構成されたサーバーのアドレスは、時間の経過とともに変化します。 サーバーに静的に割り当てられる IP アドレスを使用している場合を除き、このプロパティーは設定しないでください。

   情報	値
   デフォルト	com.ibm.cacheLocalHost = false
   推奨	com.ibm.cacheLocalHost = true (説明を参照)
   使用法	-Dcom.ibm.cacheLocalHost=true を指定すると、 getLocalHost キャッシュが使用可能になります。

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

   トラブルの回避: クラス共有およびその関連設定は、Solaris または HP-UXではサポートされていません。

   このオプションは、アプリケーション・サーバーではデフォルトで使用可能に設定されています。

   キャッシュをクリアするには、すべてのサーバー・プロセスを停止して app_server_root/bin/clearClassCache スクリプトを呼び出すか、アプリケーション・サーバーを停止してキャッシュをクリアしてから、アプリケーション・サーバーを再始動します。

   このオプションを使用する場合は、サーバー・プロセスが使用されていないときにキャッシュをクリアする必要があります。 キャッシュをクリアするには、すべてのサーバー・プロセスを停止してから、 app_server_root\bin\clearClassCache.bat スクリプトを呼び出すか、アプリケーション・サーバーを停止してキャッシュをクリアしてから、アプリケーション・サーバーを再始動します。

   このオプションを使用する場合は、サーバー・プロセスが使用されていないときにキャッシュをクリアする必要があります。 キャッシュをクリアするには、すべてのサーバー・プロセスを停止してから、 app_server_root/bin/clearClassCache.sh スクリプトを呼び出すか、アプリケーション・サーバーを停止してからアプリケーション・サーバーを再始動することによってキャッシュをクリアします。

   注: clearClassCache を使用してキャッシュ全体をクリアする場合は、接続されているすべての JVM を停止する必要があります。

   プロセスのクラス共有オプションを無効にする必要がある場合は、そのプロセスの汎用 JVM 引数 -Xshareclasses:none を指定します。

   1. 管理コンソールで、 「サーバー」>「サーバー・タイプ」>「 WebSphere アプリケーション・サーバー」> サーバー名をクリックします。
   2. 「サーバー・インフラストラクチャー」セクションで、 「Java およびプロセス管理」>「プロセス定義」>「Java 仮想マシン」 をクリックします。
   3. 「サーバー・インフラストラクチャー」セクションで、 「Java およびプロセス管理」>「プロセス定義」 をクリックします。
   4. 「制御」 または 「サーバント」のいずれかを選択してから、 「Java 仮想マシン」を選択します。
   5. 「 汎用 JVM 引数 」フィールドに -Xshareclasses:none を入力します。
   6. 「OK」をクリックします。
   7. 変更内容を構成リポジトリーに保存するには、 「保存」 をクリックします。
   8. アプリケーション・サーバーを停止して再始動します。

   情報	値
   デフォルト	「キャッシュでのクラス共有」オプションは使用可能になっています。
   推奨	キャッシュでのクラス共有オプションを使用可能のままにしておきます。
   使用法	-Xshareclasses:none を指定すると、「キャッシュでのクラス共有」オプションが使用不可になります。

8. 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 ビットすべてを必要とするヒープは必要ありません。 参照を圧縮すると、アドレスのサイズが削減され、ヒープの効率的な使用が可能になります。 これらの参照を圧縮すると、プロセッサー・キャッシュとバスの使用量も改善され、パフォーマンスが向上します。

   問題の回避:

   以下のプラットフォームでは、圧縮参照はサポートされていません。

   • HP-UX 64 ビット JVM
   • iSeries クラシック 64 ビット JVM

   64 ビット JVM を圧縮参照モードで実行できるようにするには、 WebSphereApplication Server 構成で新しい環境変数を指定する必要があります。 管理コンソールで以下を実行します。

   1. 「サーバー」>「サーバー・タイプ」> WebSphere アプリケーション・サーバー」>「server_name」とクリックします。
   2. 「構成」タブをクリックします。 「サーバー・インフラストラクチャー」の下で、 「Java およびプロセス管理」> ProcessDefinition >「サーバント」とクリックします。
   3. 「追加プロパティー」の下の「環境エントリー」をクリックします。
      以下のように、 IBM_JAVA_OPTIONS の環境エントリーを追加または更新します。

      1. IBM_JAVA_OPTIONSという名前の既存の環境エントリーがある場合は、それを編集して、既存の値に Java オプション -Xcompressedrefs を追加します。
      2. それ以外の場合は、「新規」をクリックして、新規の環境エントリーを作成します。 フォームの個々のフィールドに以下の値を入力します。

         情報	値
         名前:	IBM_JAVA_OPTIONS
         値:	-Xcompressedrefs
         説明:	64 ビット圧縮参照モードを使用可能にします

   この手順では、 WebSphereApplication Server 構成ディレクトリー内の was.env ファイルを更新します。 この変更によって、設定がサーバント、制御、および付属領域のすべてに適用されます。

   問題の回避: 汎用 JVM 引数として Xcompressedrefs を指定すると、サポートされない Java オプション・エラーのために WebSphereApplication Server の始動が失敗します。 アプリケーションが 30 GB を超える Java ヒープを必要とする場合は、64 ビットのデフォルト・モードを使用する必要があります。

   ヒープ・サイズ ( -Xmx パラメーターによって制御される) が特定のヒープ・サイズ (プラットフォームに応じて約 25 GB) の下に設定されている場合、製品はデフォルトで、サポートされるプラットフォーム上でポインター圧縮を自動的に使用可能にします。それ以外の場合は、非圧縮参照にデフォルト設定されます。 ユーザーは以下のコマンド行オプションを使用して、これらのデフォルトをオーバーライドすることができます。

   WebSphere Application Server for z/OS は、ポインター圧縮を自動的に使用可能にするわけではありません。 コマンド行オプションを使用して、ポインターの圧縮を手動で有効にするようにお奨めします。

   次のコマンド行オプションは圧縮参照フィーチャーを制御します。

   -Xcompressedrefs

   このコマンド行オプションは圧縮参照フィーチャーを使用可能にします。 このコマンド行オプションにより JVM が起動した場合は、ヒープにアドレッシングするのに 32 ビット幅メモリー参照が使用されます。 このフィーチャーは、-Xmx パラメーターで制御される一定のヒープ・サイズ (プラットフォームによるが、29 GB 前後) まで使用できます。

   -Xnocompressedrefs

   このコマンド行オプションは圧縮参照フィーチャーを明示的に使用不可にします。 このコマンド行オプションにより JVM が起動する場合は、ヒープにアドレッシングするのに全 64 ビット幅のメモリー参照が使用されます。 このオプションを使用すると、デフォルトで使用可能になっているポインター圧縮を必要に応じてオーバーライドすることができます。

9. 大規模なセル構成の構成更新プロセスを調整します。
   大規模なセル構成では、構成更新のパフォーマンスと整合性検査のどちらがより重要かを決定する必要があります。 デプロイメント・マネージャーは、セル全体のメイン構成リポジトリーを保守します。 デフォルトで、製品は構成変更があると、ワークスペースの構成と構成リポジトリーを比較して、ワークスペースの整合性を維持します。 ただし、整合性検査プロセスにより、構成変更を保存したり、多くのアプリケーションをデプロイしたりする時間が増加する可能性があります。 必要となる時間に影響する要素は次のとおりです。

   • セル内に定義されたアプリケーション・サーバーまたはクラスターが多ければ多いほど、構成変更の保存にかかる時間が長くなります。
   • セル内にデプロイされたアプリケーションが多ければ多いほど、構成変更の保存にかかる時間が長くなります。

   構成変更にかかる時間に問題がある場合は、JVM 設定に config_consistency_check カスタム・プロパティーを追加して、このプロパティーの値を false に設定します。

   1. 管理コンソールで、 「システム管理」>「デプロイメント・ マネージャー」とクリックします。
   2. 「サーバー・インフラストラクチャー」の下で「Java およびプロセス管理」をクリックし、さらに「プロセス定義」をクリックします。
   3. 「追加プロパティー」において、 「Java 仮想マシン」>「カスタム・ プロパティー」>「新規」とクリックします。
   4. 「名前」 フィールドに config_consistency_check と入力し、 「値」 フィールドに false と入力します。
   5. 「OK」をクリックして、これらの変更を構成リポジトリーに保存します。
   6. サーバーを再始動してください。

   サポートされる構成: config_consistency_check カスタム・プロパティーは、デプロイメント・マネージャー・プロセスにのみ影響します。 ノード・エージェントやアプリケーション・サーバーなどの その他のプロセスには影響しません。 これらのプロセスでは、整合性検査は実行されません。 しかし、これらのプロセス用の SystemOut.log ファイル内で、 整合性検査が無効であることを示す注記が表示されることがあります。 デプロイメント・マネージャー・プロセス以外のこれらのプロセスの場合、このメッセージは無視してかまいません。

   wsadmin コマンド wsadmin -conntype none をローカル・モードで使用する場合は、このコマンドを発行する前に config_consistency_check プロパティーを false に設定する必要があります。