WebSphere Application Server for z/OS, Version 6.1   
             オペレーティング・システム: z/OS

             目次と検索結果のパーソナライズ化

Java 仮想マシンの調整

アプリケーション・サーバーは Java ベースのプロセスであり、アプリケーション・サーバーで稼働する Java アプリケーションを実行およびサポートするには、Java 仮想マシン (JVM) 環境が必要です。 Java ランタイム環境を構成し、パフォーマンスおよびシステム・リソース使用率を 調整することができます。

始める前に

以下のことを確認してください。
  1. サポート対応の最新バージョンの JVM がシステムにインストールされている。
  2. 最新のサービス更新がシステムにインストールされている。ほぼすべての 新規サービス・レベルに、JVM パフォーマンスの改善が組み込まれます。

このタスクについて

z/OS プラットフォームでは、コントローラーとサーバントの両方に JVM があります。 ここに記載された情報は、サーバントの JVM に適用されます。 通常、コントローラーの JVM は調整する必要がありません。

Java ランタイム環境には、WebSphere Application Server などの Java ベース・アプリケーションおよびサーバーの実行環境が用意されています。 したがって、WebSphere Application Server およびそこで稼働するアプリケーションのパフォーマンスやシステム・リソース消費量を判別する場合に、Java 構成が重要な役割を果たします。

サポートされる JVM は、異なる JVM プロバイダーから入手できます。 これらの JVM は次のとおりです。
  • IBM JVM

    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 ごとに以下のタイプの調整を実行するための具体的な手順を示します。 これらのステップは、特定の順序で実行する必要はありません。

プロシージャー

  1. JIT (Just In Time) コンパイラーがアクティブになっていない場合は、使用可能にします。

    「構成」タブの「一般プロパティー」セクションで、「JIT を使用不可にする」が選択されていないことを確認してください。

  2. 開始パフォーマンスとランタイム・パフォーマンスの最適化

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

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

    • -Xquickstart

      この設定値は、IBM JVM が低い最適化レベルをクラス・メソッド・ コンパイルに使用する方法に影響します。最適化レベルを低くすると、サーバ開始時間が短縮されますが、ランタイム・パフォーマンスは低下します。 このパラメーターが 指定されていない場合、IBM JVM はデフォルトでコンパイルに高い初期最適化レベルを使用して開始するため、ランタイム・パフォーマンスは向上しますが、サーバーの開始時間が長くなります。

      デフォルト: 高い初期コンパイラー最適化レベル
      推奨: 高い初期コンパイラー最適化レベル
      使用法: -Xquickstart はサーバー開始時間を短縮します。
    JVM の初期化をスピードアップし、サーバー起動時間を改善するには、 「構成」タブの「一般プロパティー」セクションにある「General JVM Arguments」フィールドで 以下のコマンド行引数を指定します。
    -Xquickstart
    -Xverify:none
    
  3. JVM libjava_g のデバッグ・バージョンが LIBPATH に含まれていないことを確認します。
  4. ヒープ・サイズの構成

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

    JVM には、JVM のストレージを管理するために使用するしきい値があります。しきい値に達すると、 ガーベッジ・コレクターが起動し、未使用のストレージを解放します。 そのため、ガーベッジ・コレクションが Java パフォーマンスの大幅な低下の原因となる場合があります。 初期ヒープ・サイズおよび最大ヒープ・サイズを変更する前に、以下の情報を 考慮する必要があります。
    • ほとんどの場合、最大 JVM ヒープ・サイズの値を、初期 JVM ヒープ・サイズよりも高く設定する必要があります。 そうすることにより、JVM は、通常の定常状態の期間では初期ヒープの範囲内で効率的に動作し、トランザクション量が大きい期間では、ヒープを最大 JVM ヒープ・サイズまで拡張することで効果的に動作することができます。 まれに絶対的に最適なパフォーマンスが必要になりますが、その場合に初期ヒープ・サイズと最大ヒープ・サイズの両方に同じ値を設定する必要があることがあります。 これにより、JVM が JVM ヒープ・サイズを拡張または縮小する必要がある場合に生じる オーバーヘッドの一部が解消します。領域が十分に大きく、指定の JVM ヒープを保持できるか確認します。
    • 初期ヒープ・サイズを大きくしすぎない ように注意します。 ガーベッジ・コレクションの発生を遅らせることで、最初はパフォーマンスが改善されても、 ガーベッジ・コレクションがいずれ作動すると (長い間実行されるため)、結局、応答時間に影響を与えます。

    developerWorks Web サイトで入手可能な「IBM Developer Kit and Runtime Environment, Java2 Technology Edition, Version 5.0 Diagnostics Guide」には、ヒープ・サイズ調整に関する追加情報が記載されています。

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

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

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

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

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

      初期ヒープ・サイズの設定は、 ガーベッジ・コレクションの実行頻度を MB 単位で指定します。最大ヒープ・サイズの設定は、ガーベッジ・コレクションの実行頻度を指定します。 これらの設定は、いずれもパフォーマンスに重大な影響を及ぼします。

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



      この図は、3 つの CPU プロファイルを示し、 それぞれ固定ワークロードで Java ヒープ設定値を変えながら稼働しています。 中央のプロファイルでは、初期ヒープ・サイズと最大ヒープ・サイズは 128MB に設定されています。ガーベッジ・コレクションは 4 回行われています。ガーベッジ・コレクションの合計時間は、合計実行時間の約 15% です。 ヒープ・パラメーターを倍の 256MB にすると、一番上のプロファイルのように、 ガーベッジ・コレクション間の作業時間の長さが増えていきます。 ガーベッジ・コレクションは 3 回しか行われませんが、それぞれのガーベッジ・コレクションの長さも増大しています。3 番目のプロファイルでは、ヒープ・サイズが 64MB に削減され、逆の結果が示されています。ヒープ・サイズが小さくなると、ガーベッジ・コレクション間の時間と個々のガーベッジ・コレクションの時間は、どちらも短くなります。 これらの 3 つの構成すべてについて、ガーベッジ・コレクションの合計時間 は、約 15% です。 この例は、Java ヒープおよびそれとオブジェクト使用率との関係について重要な概念 を示しています。Java アプリケーションには、 常にガーベッジ・コレクションのコストがかかります。

      一連のテスト実験を、Java ヒープ設定値を変えながら実行します。 例えば、128MB、192MB、256MB、および 320MB で実験を行います。 各実験の間、合計メモリー使用量をモニターします。 ヒープをあまり拡張しすぎると、ページングが起こります。 ページングが起こったら、ヒープのサイズを減らすか、またはシステムにメモリーを追加してください。 実行がすべて終了したら、以下の統計値を比較してください。
      • ガーベッジ・コレクションの呼び出し回数
      • ガーベッジ・コレクション 1 回分の呼び出しの平均所要時間
      • ガーベッジ・コレクション 1 回分の呼び出し時間の長さと、 呼び出し間の平均時間間隔の比率。
      アプリケーションがオブジェクトを過剰に使用しておらず、 メモリー・リークもない場合は、メモリーの使用状況は定常状態に達しています。ガーベッジ・コレクションが実行される頻度も 少なく、所要時間も短く済みます。

      ヒープのフリー・スペースが 85% 以上で安定している場合は、アプリケーション・サーバーおよびアプリケーションがヒープに割り振られたメモリーをあまり使用していないため、ヒープ・サイズの最大値を小さくすることを検討してください。

      64 ビット・モードで実行するように構成された サーバーがある場合、これらのサーバーにデフォルト設定より大幅に大きい JVM 最大ヒープ・サイズを 指定できます。 例えば、サーバーが 64 ビット・モードで実行するように構成されている場合、 コントローラーおよびサーバントに対して初期最大ヒープ・サイズ 1844m を 指定できます。

    5. 適用」または「OK」をクリックします。
    6. 変更をマスター構成に保管します。
    7. アプリケーション・サーバーを停止して再始動します。

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

    • -Xms

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

      デフォルト: 50 MB。このデフォルト値は、31 ビットおよび 64 ビットの構成の両方に適用されます。
      推奨: ワークロードに固有ですが、デフォルトより大きい値にします。
      使用法: -Xms256m は初期ヒープ・サイズを 256 メガバイトに設定します。
    • -Xmx

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

      デフォルト: 256 MB。このデフォルト値は、31 ビットおよび 64 ビットの構成の両方に適用されます。
      推奨: ワークロードに固有ですが、使用可能な物理メモリー・サイズに応じてデフォルトより 大きい値にします。
      使用法: -Xmx512m は、最大ヒープ・サイズを 512 メガバイトに設定します。
    • -Xlp

      この設定を IBM JVM で使用し、ラージ・ページ (16 MB) を使用してヒープを割り振ります。 ただし、この設定を使用する場合、ご使用のオペレーティング・システムが ラージ・ページをサポートするよう構成されている必要があります。 ラージ・ページを使用すると、ヒープ・メモリーの追跡に必要となる CPU オーバーヘッドを削減することができ、 より大きなヒープを作成することもできます。

      オペレーティング・システムの調整についての詳細は、オペレーティング・システムの調整 を参照してください。

    • –Xlp64k

      この設定を IBM JVM で使用すると、64 キロバイトのページ・サイズ (ミディアム・ページ) を使用してヒープを割り振ることができます。 アプリケーションに必要なメモリーにこの仮想メモリー・ページ・サイズを使用すると、ラージ・ページ・サイズに関連したハードウェアが効率化されるため、アプリケーションのパフォーマンスおよびスループットを改善できます。

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

      デフォルト: 4 KB
      推奨: -Xlp64k は 64 KB ページ・サイズをサポートします。
  5. Java メモリーの調整
    Java 言語で作成されたエンタープライズ・アプリケーションは、 複雑なオブジェクト関係を持ち、多数のオブジェクトを使用します。Java 言語はオブジェクトのライフ・サイクルに関連したメモリーを自動的に管理しますが、アプリケーションのオブジェクト使用パターンを理解することは重要です。特に、以下を確認してください。
    • アプリケーションが、オブジェクトを過剰に使用していない。
    • アプリケーションが、オブジェクトをリークしていない。
    • Java ヒープ・パラメーターが、指定したオブジェクトの使用パターンを処理するように適切に設定されている。
    1. オブジェクトの過剰使用の確認

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

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

    2. メモリー・リークのテスト

      メモリー・リークは、Java 言語ではガーベッジ・コレクションのボトルネックの原因となる危険な状況です。 メモリー・リークは最終的にシステムの不安定性につながるため、メモリーの過剰使 用よりも有害です。時間が経過するにつれて、ガーベッジ・コレクションが頻繁に発生し、 最終的にはヒープが使い尽くされて、Java コードは致命的なメモリー不足例外により停止します。 メモリー・リークは、使われていないオブジェクトが参照され、解放されないときに起こります。 メモリー・リークは、Hashtable などの集合クラスでよく発生します。 これは、この表が実際の参照情報が削除された後であっても、常にオブジェクトを参照していることが原因です。

      ワークロードが高いと、アプリケーションが、実稼働環境でのデプロイメント直後に破損することが頻繁に起こります。このような状況は、リークを起こしているアプリケーションで、ワークロードの高さがリークの拡大を加速し、メモリー割り振りの失敗が生じる場合に特に顕著です。

      メモリー・リークをテストする目的は、数を拡大することです。 メモリー・リークはほんの数バイトから数 K バ イトの大きさにすぎないため、ガーベッジ・コレクションでは検出されません。使用可能なメモリーと使用不能なメモリー の予期されるサイズを見分けることは、微妙な作業です。 数が増大してギャップが大きくなり、矛盾を簡単に認識できるようになれば、 この作業はもっと簡単になります。以下のリストは、メモリー・リークについての重要な結論です。
      • 長期間実行するテスト

        メモリー・リークの問題は、一定の期間を経てからでないと表面化しないため、メモリー・リークは長期間実行するテストでは検出されやすいと言えます。 短期間の稼働テストでは誤った警告を受ける可能性があります。Java 言語では、いつメモリー・リークが発生しているかを認識しにくい場合があります。メモリーの使用が突然に、あるいは一定の期間内に単調に増加したように見える場合には、特に判断がむずかしいでしょう。 メモリー・リークの検出がむずかしいのは、このような増加が妥当なものであったり、開発者が意図的に行ったものであったりする可能性があるためです。 後になって使用されるオブジェクトと、まったく使用されないオブジェクトとを区別する方法は、アプリケーションを長期間実行していればわかってきます。 長期間実行するアプリケーションのテストでは、実際にオブジェクトが後になって使用されているかどうかについて、 より確信が持てるようになります。

      • 反復テスト

        多くの場合、同じテスト・ケースを続けて反復する場合に、メモリー・リークの問題が起こります。メモリー・リークのテストのゴー ルは、使用不能なメモリーと使用中のメモリーとの間で、相対的サイズに大きなギャッ プを作り出すことです。同じシナリオを何度も繰り返すことによって、このギャップは非常に累進的に増えていきます。このテストは、テスト・ケースの実行により発生するリーク数がごくわずかであるために、1 回の実行ではほとんど検出できないような場合に役立ちます。

        反復テストは、システム・レベルまたはモジュール・レベルで使用できま す。モジュラー・テストの利点は、管理の点でより優れていることです。モジュールが、専用のモジュールを保持して、メモリーの使用など外部の副次作用が発生しないように設計されている場合、メモリー・リークのテストは簡単になります。最初に、モジュールを実行する前のメモリー使用量が記録されます。次に、固定セットのテスト・ケースが 繰り返し実行されます。テスト実行の終了時には、現在のメモリー使用量が記録され、顕著な変化がないかどうかチェックされます。実際のメモリー使用量を記録するときには、ガーベッジ・コレクションを行う必要があることを覚えておいてください。これを行うには、ガーベッジ・コレクションを実行したいモジュールに System.gc() を挿入するか、このイベントを強制的に発生させるプロファイル作成ツールを使用します。

      • 並行性テスト

        一部のメモリー・リーク問題は、アプリ ケーションでいくつかのスレッドが実行中の場合にのみ起こる可能性があります。 残念なことに、プログラム・ロジックの複雑さが増したため、同期点からメモリー・リークが発生することが非常に多くなっています。プログラミング時に注意を怠ると、参照が保持されたままになったり、解放されなかったりする可能性があります。メモリー・リークの問題は、システムの並行性が 増すことによって、促進されたり、加速されたりすることがよくあります。 並行性を高める最も一般的な方法は、テスト・ドライバー内のクライアント数を増やすことです。

        メモリー・リークのテストで使用するテスト・ケースを選択するときには、以下の点を考慮してください。
        • 優れたテスト・ケースは、アプリケーションでオブジェクトが作成される領域を使用します。ほとんどの場合、アプリケーショ ンの知識が必要になります。シナリオの説明で、新規レコードの追加、HTTP セッションの作成、ト ランザクションの実行、およびレコードの検索などのような、データ・スペースの作成を 推奨している場合があります。
        • オブジェクトのコレクションが使用されている領域を調べてください。通常、メモリー・リークは同じクラス内のオブジェクトから構成されています。また、対応する追加メソッドを呼び出すことによって、オブジェク トへの参照が暗黙的に保管される場所である、vector や hashtable などのコレクション ・クラスも一般的です。例えば、Hashtable オブジェクトのゲット・メソッドは、検索済みのオブジェクトへの参照を除去しません。

      ヒープの消費が、ワークロードが高いときにリークが起こった可能性を示している (アプリケーション・サーバーの CPU 使用率が常に 100% 近くなっている) のに、その後、ワークロードが低いかほとんどアイドル状態になったときにはヒープが回復するように見えるのは、ヒープのフラグメント化が起きている兆候です。ヒープのフラグメント化は、JVM がガーベッジ・コレクションのサイクル中にメモリー割り振り要求を満たすために十分な量のオブジェクトを解放することができたとしても、ヒープ内の小さな空きメモリー域を圧縮して、連続した大きなスペースを作成する時間がない場合には、起こる可能性があります。

      この他に、ヒープのフラグメント化は、小さなオブジェクト (512 バイト未満) が解放された場合にも起こります。オブジェクトが解放されても、ストレージは回復しません。この結果、ヒープ圧縮が実行されるまでは、メモリーのフラグメント化が進みます。

      ヒープのフラグメント化は圧縮を強制するによって削減できますが、これを行う場合パフォーマンス・ペナルティーがあります。 Java -X コマンドを使用して、メモリー・オプションのリストを参照します。

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

    Java 仮想マシン (JVM) は、 並列ガーベッジ・コレクターを使用して、大部分のガーベッジ・コレクション・サイクルの間に、 SMP を最大限に活用します。HotSpot ベース JVM には、単一スレッドのガーベッジ・コレクターがあります。

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

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

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

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

    ガーベッジ・コレクションのモニターの詳細については、以下を参照してください。

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

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

    以下のリストでは、さまざまな JVM ガーベッジ・コレクターの –X オプションについて 説明しています。

    IBM JVM ガーベッジ・コレクター。
    IBM Java ガーベッジ・コレクターについて詳しくは、『IBM Developer Kit and Runtime Environment, Java2 Technology Edition, Version 5.0 Diagnostics Guide』を参照してください。この文書は developerWorks Web サイトで入手できます。

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

    • -Xgcpolicy
      Java 5.0 以降、IBM JVM にはガーベッジ・コレクション用の 4 つのポリシーが用意されています。 各ポリシーには固有の利点があります。
      • optthruput。デフォルトのこのポリシーは高いスループットを実現しますが、ガーベッジ・コレクションの休止時間が長くなります。 すべてのアプリケーション・スレッドは、ガーベッジ・コレクション中にマーク、スイープ、および圧縮のために停止します (圧縮が必要な場合)。 ほとんどのアプリケーションでは、optthruput で十分に対応することができます。
      • optavgpause。アプリケーションを実行すると同時にガーベッジ・コレクションのマークおよびスイープ・フェーズを実行して、ガーベッジ・コレクションの休止時間を短縮します。 この同時実行により、スループット全体のパフォーマンスがわずかに低下します。
      • gencon。IBM Java 5.0 で新規に導入されたこのポリシーは、IBM JVM 世代のガーベッジ・コレクターです。 この世代的な方式では、ガーベッジ・コレクションの収集休止時間を短縮するとともに、高スループットを実現します。 この目的を達成するために、ヒープは新旧のセグメントに分割されます。 存続時間が長いオブジェクトは古いスペースにプロモートされますが、存続時間が短いオブジェクトは新規スペースに格納されて短時間にガーベッジ・コレクションが実行されます。 gencon ポリシーは多くのアプリケーションに多くの利点をもたらしますが、すべてのアプリケーションに適しているわけではなく、一般に調整は困難です。
      • subpool。一般に使用プロセッサー数が 8 つを超えるマルチプロセッサー・システムで、パフォーマンスを改善することができます。 このポリシーを使用できるのは、 IBM pSeries および zSeries プロセッサーのみです。subpool ポリシーは optthruput ポリシーと似ていますが、ヒープがサブプールに分割されて、オブジェクト割り振りのスケーラビリティーが改善される点が異なります。
      デフォルト: optthruput
      推奨: optthruput
      使用法: Xgcpolicy:optthruput は、ガーベッジ・コレクションを optthruput に設定します。

      gcpolicyoptthruput に設定すると、並行マークが使用不可になります。 アプリケーション応答時間が安定せず、休止時間に問題があると考えられる場合を除き、optthruput ポリシーを使用するとスループットが最適になります。

      gcpolicyoptavgpause に設定すると、そのデフォルト値で並行マークが使用可能になります。この設定は、 通常のガーベッジ・コレクションによって発生する、アプリケーションの不安定な応答時間を緩和します。 ただし、このオプションはスループット全体を減少させる可能性があります。

    • -Xnoclassgc

      クラスのライブ・インスタンスが残されていない場合、デフォルトで、JVM はメモリーからクラスをアンロードします。 そのため、クラスをアンロードすると、パフォーマンスが低下することがあります。

      -Xnoclassgc 引数を使用してクラス・ガーベッジ・コレクションを 使用不可にすることで、アプリケーションでクラスをさらに簡単に再利用できます。 クラス・ガーベッジ・コレクションをオフにすると、 同じクラスを複数回ロードおよびアンロードするオーバーヘッドが除去されます。

      デフォルト: クラス・ガーベッジ・コレクションは使用可能です。
      推奨:

      クラス・ガーベッジ・コレクションを使用不可にします。

      使用法: Xnoclassgc はクラス・ガーベッジ・コレクションを使用不可にします。
  7. キャッシュ内のクラス共有の使用可能化

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

    このオプションを使用すると、プロセスを使用していない場合にキャッシュをクリアする必要があります。 キャッシュをクリアするには、app_server_root/bin/clearClassCache.bat/sh ユーティリティーを呼び出すか、プロセスを停止してからそのプロセスを再始動します。

    特定のプロセスに対してクラス共用オプションを使用不可にする必要がある場合は、そのプロセスに汎用 JVM 引数 -Xshareclasses:none を指定します

    1. 管理コンソールで、「サーバー」 > 「アプリケーション・サーバー」 > 「server」をクリックします。
    2. 「サーバー・インフラストラクチャー」の下で、「Java およびプロセス管理」>「プロセス定義」をクリックします。
    3. 制御」または「サーバント」のいずれかを選択してから、 「Java 仮想マシン」を選択します。
    4. 「汎用 JVM 引数フィールド」に、-Xshareclasses:none を入力します。
    5. OK」をクリックします。
    6. 変更をマスター構成に保管します。
    7. アプリケーション・サーバーを停止して再始動します。
    デフォルト: キャッシュでのクラス共用オプションは使用可能です。
    推奨: キャッシュでのクラス共用オプションを使用可能のままにしておきます。
    使用法: -Xshareclasses:none はキャッシュでのクラス共用オプションを使用不可にします。
  8. 大規模なセル構成の構成更新プロセスを調整します。
    大規模なセル構成では、構成更新のパフォーマンスと整合性検査のどちらがより重要かを決定する必要があります。 構成の整合性検査がオンになっている場合は、構成変更の保管または多数のアプリケーションのデプロイに時間がかかることがあります。 必要となる時間に影響する要素は次のとおりです。
    • セル内に定義されたアプリケーション・サーバーまたはクラスターが多ければ多いほど、構成変更の保管にかかる時間が長くなります。
    • セル内にデプロイされたアプリケーションが多ければ多いほど、構成変更の保管にかかる時間が長くなります。
    構成変更にかかる時間に問題がある場合は、JVM 設定に config_consistency_check カスタム・プロパティーを追加して、このプロパティーの値を false に設定します。
    1. 管理コンソールで、「システム管理」>「デプロイメント・マネージャー」とクリックします。
    2. 「サーバー・インフラストラクチャー」の下で「Java およびプロセス管理」をクリックし、さらに「プロセス定義」をクリックします。
    3. 「追加プロパティー」の下で、「Java 仮想マシン」>「カスタム・プロパティー」>「新規」とクリックします。
    4. 「名前」フィールドに config_consistency_check を入力し、「値」フィールドに false と入力します。
    5. OK」をクリックしてから「保管」をクリックして、これらの変更をマスター構成に適用します。
    6. サーバーを再始動します。

次の作業

JVM のパフォーマンスおよび調整について詳しくは、各 Java ベンダーにお問い合わせください。 特定の Java ランタイム環境の調整に関する追加情報については、以下の Web サイトを参照してください。

DB2 を使用する場合、HP JVM for HP-UX で SafepointPolling テクノロジーを 使用不可にすることを検討してください。Java スレッドの safepoint を確保するために開発された SafepointPolling テクノロジーを使用すると、WebSphere Application Server と DB2 データベース間でシグナル干渉を引き起こす可能性のあるシグナルが生成されます。 この干渉が発生すると、頻繁にデータベースのデッドロックが生じます。 -XX:-SafepointPolling オプションで JVM を起動し、ランタイム中の SafepoinPolling を使用不可にして、干渉が起こらないようにしてください。




関連タスク
アプリケーション・サービス提供環境のチューニング
関連資料
Java 仮想マシン設定
タスク・トピック    

ご利用条件 | フィードバック

最終更新: Jan 21, 2008 9:12:22 PM EST
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.zseries.doc/info/zseries/ae/tprf_tunejvm_v61.html