WebSphere Application Server Version 6.1 Feature Pack for Web Services   
             オペレーティング・システム: AIX , HP-UX, i5/OS, Linux, Solaris, Windows, Windows Vista, z/OS

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

Java 仮想マシンの調整

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

始める前に

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

このタスクについて

[z/OS] 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を参照してください。

  • [Solaris] HotSpot ベース JVM (Solaris 上の Sun HotSpot JVM など)
  • [HP-UX] HP JVM for HP-UX

ご使用のアプリケーション・サーバーが稼働している JVM プロバイダーを判別するには、アプリケーション・サーバーの app_server_root/java/bin ディレクトリーから java –fullversion コマンドを発行します。 アプリケーション・サーバーはこのコマンドに応答して、JVM プロバイダー情報を含む、JVM に関する情報を SystemOut.log ファイルに書き込みます。

JVM 調整は使用する JVM プロバイダーに依存していますが、すべての JVM に該当する一般の調整概念もあります。 これらの一般概念には、以下のものがあります。

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

プロシージャー

  1. [i5/OS] Just-In-Time (JIT) コンパイラーの設定の変更

    Just-In-Time (JIT) コンパイラーは、必要に応じてメソッドごとにマシン・インストラクションを生成するプラットフォーム固有のコンパイラーです。 詳しくは、i5/OS インフォメーション・センターのトピック『IBM Developer Kit for Java』内の「Just-In-Time コンパイラーの使用』および『Just-In-Time コンパイラー』を参照してください。

    1. 管理コンソールで、「サーバー」 > 「アプリケーション・サーバー」 > 「server」をクリックします。
    2. 「サーバー・インフラストラクチャー」の下で、 「Java およびプロセス管理」>「プロセス定義」>「Java 仮想マシン」をクリックします。
    3. JIT を使用不可にする場合は、「JIT を使用不可にする」オプションを選択します。
    4. 完全な JIT コンパイラーで実行する場合は、「汎用 JVM 引数」フィールドに -Djava.compiler=jitc を入力します。
    5. 適用」または「OK」をクリックします。
    6. 変更をマスター構成に保管します。
    7. アプリケーション・サーバーを停止して再始動します。
    デフォルト: JIT は使用可能です。
    推奨: JIT コンパイラーを使用不可にしないで、完全な JIT コンパイラーを使用可能にすることをお勧めします (ステップ 4.d を参照)。 os400.jit.mmi.threshold はパフォーマンスに重大な影響を及ぼすことがあります。 JIT コンパイラーおよび os400.jit.mmi.threshold プロパティーについて詳しくは、i5/OS インフォメーション・センターのトピック『IBM Developer Kit for Java』内の『Just-In-Time コンパイラー』を参照してください。
  2. [z/OS] JIT (Just In Time) コンパイラーがアクティブになっていない場合は、使用可能にします。

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

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

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

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

    • -Xquickstart

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

      デフォルト: 高い初期コンパイラー最適化レベル
      推奨: 高い初期コンパイラー最適化レベル
      使用法: -Xquickstart はサーバー開始時間を短縮します。
    [z/OS] JVM の初期化をスピードアップし、サーバー起動時間を改善するには、 「構成」タブの「一般プロパティー」セクションにある「General JVM Arguments」フィールドで 以下のコマンド行引数を指定します。
    -Xquickstart
    -Xverify:none
    

    [Solaris] HotSpot ベース JVM は、最初に低い最適化レベルでクラス・メソッドを コンパイルします。以下の JVM オプションを使用して、この振る舞いを変更します。

  4. [z/OS] JVM libjava_g のデバッグ・バージョンが LIBPATH に含まれていないことを確認します。
  5. ヒープ・サイズの構成

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

    [i5/OS] ヒープ・サイズの設定により、i5/OS JVM のガーベッジ・コレクションが制御されます。 初期ヒープ・サイズは、新しいガーベッジ・コレクション・サイクルを起動するしきい値です。 例えば、初期ヒープ・サイズが 10 MB の場合、JVM が最後のコレクション・サイクル以降に 10 MB が割り振られたことを検出すると同時に、新しいコレクション・サイクルが起動されます。

    [i5/OS] ヒープ・サイズを小さくすると、サイズが大きい場合に比べて頻繁にガーベッジ・コレクションが実行されます。 最大ヒープ・サイズに達した場合は、ガーベッジ・コレクターが非同期の操作を停止し、ユーザー・スレッドがコレクション・サイクルが完了するまで待機するよう強制されます。 この状態は、パフォーマンスに重大な悪影響を与えます。 最大ヒープ・サイズが 0 (*NOMAX) の場合は、ガーベッジ・コレクションが常に非同期に実行されることになります。

    [i5/OS] 最大ヒープ・サイズは、アプリケーションのパフォーマンスに影響を与えることがあります。 最大ヒープ・サイズは、ガーベッジ・コレクションされたヒープが消費できるオブジェクト・スペースの最大量を指定します。 最大ヒープ・サイズが小さすぎる場合は、パフォーマンスが大幅に低下するか、最大ヒープ・サイズに達したときにアプリケーションがメモリー不足エラーを受け取る可能性があります。

    [i5/OS] 最大ヒープ・サイズの正しい値を決定することは困難であるため、ガーベッジ・コレクションされたヒープ・サイズのオブジェクト・スペースで絶対限度が必要でない限りは、値 0 (サイズの制限がないことを意味します) を使用することをお勧めします。

    [i5/OS] 最大ヒープ・サイズの適切な値を決定する場合は、適切な値が各構成またはワークロードの組み合わせで異なるため、複数のテストを実行する必要があります。 ランナウェイ JVM を防止する場合は、最大ヒープ・サイズを予想されるサイズよりも大きく、かつ残りのマシンのパフォーマンスに影響を与えない大きさで設定します。

    [i5/OS] テストの 1 つで次のことを行う必要があります。
    1. 最大ヒープ値を 0 に設定し、負荷を重くしてアプリケーション・サーバーを実行します。
    2. DMPJVM コマンドまたは iDoctor を使用して、JVM のガーベッジ・コレクションされたヒープの最大サイズを決定します。
    3. ガーベッジ・コレクション・ヒープのサイズに 1.25 を乗算します。 最大ヒープ・サイズの最小許容値は、ガーベッジ・コレクションされたヒープのサイズの 125% であるため、この結果は適切な推定値になります。

    [i5/OS] パフォーマンスに影響を与えることなく、最大ヒープ・サイズにより大きな値を指定できるため、JVM のリソース制限またはご使用のシステム構成の制限に基づいて、可能な限り最大の値を設定することをお勧めします。

    [i5/OS] 最大ヒープ・サイズの適切な値を決定した後、JVM を実行するプールのセットアップまたは調整が必要になる場合があります。 デフォルトでは、WebSphere Application Server のジョブは基本システム・プール (WRKSYSSTS で示されるストレージ・プール 2) で実行されますが、別のプールを指定することもできます。 最大ヒープ・サイズは、JVM が実行されているプールのサイズの 125% より大きく設定しないようにします。 可能な限り、メモリーが永続的に割り振られた独自のメモリー・プールで JVM を実行することをお勧めします。

    [i5/OS] メモリー・プールを調整するためのパフォーマンス調整機構が設定されている (つまり、システム値 QPFRADJ が 0 以外の値に設定されている) 場合、WRKSHRPOOL を使用しているプールに対して最小値を指定することをお勧めします。 この最小値は、ガーベッジ・コレクションされたヒープ作業セットのサイズとほぼ等しくなります。 最大ヒープ・サイズを正しく設定し、メモリー・プールを正しく構成することで、JVM でシステム・リソースを消費するメモリー・リークを防止する一方で、優れたパフォーマンスを実現できます。

    [i5/OS] JVM を共用プールで実行する必要がある場合は、最大ヒープ・サイズの適切な値を決定することがさらに難しくなります。 プール内で実行されている他のジョブにより、ガーベッジ・コレクションされたヒープ・ページがプールからエージアウトされる可能性があります。 ガーベッジ・コレクションされたヒープ・ページがプールからエージアウトされた場合、ガーベッジ・コレクターは次のガーベッジ・コレクション・サイクルでそれらのページをプール内に戻す必要があります。これは、ガーベッジ・コレクターがガーベッジ・コレクションされたヒープ内のすべてのページにアクセスする必要があるためです。 i5/OS JVM では、ヒープを消去するためにすべての JVM スレッドが停止されないため、過度のページ不在は、ガーベッジ・コレクターのスローダウンおよびガーベッジ・コレクションされたヒープの増加を引き起こします。 ヒープのサイズは増加しますが、スレッドは引き続き実行されます。

    [i5/OS] このヒープの増加は、ガーベッジ・コレクションされたヒープの作業セットのサイズの人為的な増加であり、最大ヒープ値を指定する場合は考慮する必要があります。 小規模な人為的な増加が発生した場合は、スペースが未使用のままであればガーベッジ・コレクターがヒープのサイズを時間の経過とともに削減し、プールのアクティビティーが定常状態に戻ります。 ただし、共用プールの場合は、最大ヒープ・サイズが正しく設定されていないと、問題が発生する可能性があります。
    • 最大ヒープ・サイズが小さすぎる場合は、人為的な増加によって、JVM がメモリー不足エラーをスローした場合に、大幅なパフォーマンス低下またはシステム障害が発生する可能性があります。
    • 最大ヒープ・サイズが大きすぎる場合は、ガーベッジ・コレクターが、ガーベッジ・コレクションされたヒープの人為的な増加をリカバリーできないポイントに達する可能性があります。 この場合、パフォーマンスも悪影響を受けます。 値が大きすぎる場合は、ガーベッジ・コレクターが JVM 障害を防止できなくなります。 ただし、ガーベッジ・コレクターはランナウェイ JVM がシステム・リソースを過度に消費することは防ぐことができます。

    [i5/OS] ヒープ・サイズが所定のレベルを確実に超えることのない最大ヒープ・サイズを設定する必要がある場合は、初期ヒープ・サイズを最大ヒープ・サイズの 80% から 90% の大きさに指定します。 ただし、指定された値は、パフォーマンスに悪影響を与えないだけの十分な大きさにする必要があります。

    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」には、ヒープ・サイズ調整に関する追加情報が記載されています。

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

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

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

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

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

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

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

      [i5/OS] Java アプリケーションの作業セット・サイズが不明な実動システムを調整する場合は、 初期ヒープ・サイズをプロセッサー当たり 96 MB に設定することをお勧めします。 i5/OS JVM の合計ヒープ・サイズは、最後のガーベッジ・コレクションの終了時のライブ (使用中の) ヒープ・スペースの量と初期ヒープ・サイズの合計として概算できます。



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

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

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

      [i5/OS] 重要: 他の JVM 実装とは異なり、i5/OS JVM では、大容量のヒープ・フリー・スペースの有無は一般的に問題ではありません。

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

      [i5/OS] デフォルトの最大ヒープ・サイズは 0 であり、 これは最大値がないことを示します。最大ヒープ・サイズは変更しないことをお勧めします。最大ヒープ・サイズによってガーベッジ・コレクション・サイクルが起動すると、i5/OS JVM のガーベッジ・コレクションは非同期に動作を停止します。 この動作が起こると、アプリケーション・サーバーはガーベッジ・コレクション・サイクルが終了するまでユーザー・スレッドを処理できなくなり、パフォーマンスが大幅に低下します。 初期および最大ヒープ・サイズについて詳しくは、i5/OS インフォメーション・センターのトピック『Tuning Garbage Collection for Java and WebSphere on iSeries』を 参照してください。

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

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

    • -Xms

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

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

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

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

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

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

    • [z/OS] [AIX HP-UX Linux Solaris Windows] –Xlp64k

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

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

      [AIX] AIX には、汎用の 64 KB ページに関する豊富なサポート機能があります。 64 KB ページは簡単に使用することができ、多くのアプリケーションではデフォルトの 4 KB ページでなく 64 KB ページを使用した場合に、パフォーマンスが向上すると予測されます。この設定を変更する場合に、オペレーティング・システムの構成を変更する必要はありません。

      デフォルト: 4 KB
      推奨: -Xlp64k は 64 KB ページ・サイズをサポートします。
      [AIX] 注: AIX 5L バージョン 5.3 に 5300-04 Recommended Maintenance Package を組み込んだ POWER5+ システムでは、64 ビット・カーネルを実行するときに、新規の 64 KB ページ・サイズがサポートされます。
  6. Java メモリーの調整
    Java 言語で作成されたエンタープライズ・アプリケーションは、 複雑なオブジェクト関係を持ち、多数のオブジェクトを使用します。Java 言語はオブジェクトのライフ・サイクルに関連したメモリーを自動的に管理しますが、アプリケーションのオブジェクト使用パターンを理解することは重要です。特に、以下を確認してください。
    • アプリケーションが、オブジェクトを過剰に使用していない。
    • アプリケーションが、オブジェクトをリークしていない。
    • Java ヒープ・パラメーターが、指定したオブジェクトの使用パターンを処理するように適切に設定されている。
    1. オブジェクトの過剰使用の確認

      [i5/OS] Tivoli Performance Viewer を使用して 、JVM ランタイムのカウンターを監視することによって、アプリケーションがオブジェクトを乱用しているかどうかを確認できます。Java 仮想マシン・プロファイラー・インターフェース (JVMPI) カウンターを 使用可能にするには、-XrunpmiJvmpiProfiler コマンド行オプションとともに 、JVM モジュールの最大レベルも設定しなければなりません。 JVMPI カウンターについて詳しくは、 Java 仮想マシン・プロファイラー・データの使用可能化 を参照してください。

      [i5/OS] また、次のツールを使用して JVM のオブジェクト作成をモニターすることもできます。
      • DMPJVM コマンド。 DMPJVM (Dump Java Virtual Machine) コマンドは、特定のジョブの JVM 情報をダンプします。
      • ANZJVM コマンド。 ANZJVM (Analyze Java Virtual Machine) コマンドは、特定のジョブの Java 仮想マシン (JVM) に関する情報を収集します。 このコマンドは、i5/OS V5R2 以降で使用可能です。
      • Performance Trace Data Visualizer (PTDV)

      [AIX HP-UX Linux Solaris Windows] Tivoli Performance Viewer を使用して 、JVM ランタイムのカウンターを監視することによって、アプリケーションがオブジェクトを乱用しているかどうかを確認できます。Java 仮想マシン・プロファイラー・インターフェース (JVMPI) カウンターを 使用可能にするには、-XrunpmiJvmpiProfiler コマンド行オプションとともに 、JVM モジュールの最大レベルも設定しなければなりません。

      [i5/OS] [AIX HP-UX Linux Solaris Windows] ガーベッジ・コレクション間の平均時間は、最もよい結果が出た場合で、ガーベッジ・コレクション 1 回分の平均所要時間の少なくとも 5 から 6 倍です。この数値に達しない場合、アプリケーションがガーベッジ・コレクションに費やす時間は、実行時間の 15% を超えています。

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

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

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

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

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

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

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

      • 反復テスト

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

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

      • 並行性テスト

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

        メモリー・リークのテストで使用するテスト・ケースを選択するときには、以下の点を考慮してください。
        • 優れたテスト・ケースは、アプリケーションでオブジェクトが作成される領域を使用します。ほとんどの場合、アプリケーショ ンの知識が必要になります。シナリオの説明で、新規レコードの追加、HTTP セッションの作成、ト ランザクションの実行、およびレコードの検索などのような、データ・スペースの作成を 推奨している場合があります。
        • オブジェクトのコレクションが使用されている領域を調べてください。通常、メモリー・リークは同じクラス内のオブジェクトから構成されています。また、対応する追加メソッドを呼び出すことによって、オブジェク トへの参照が暗黙的に保管される場所である、vector や hashtable などのコレクション ・クラスも一般的です。例えば、Hashtable オブジェクトのゲット・メソッドは、検索済みのオブジェクトへの参照を除去しません。
      [i5/OS] これらのツールを使用してメモリー・リークを検出できます。
      • Tivoli Performance Viewer。 Tivoli Performance Viewer を使用したメモリー・リークの検出の詳細および例については、i5/OS インフォメーション・センター内の "Tuning Garbage Collection for Java(TM) and WebSphere on iSeries" のトピックを参照してください。
      • DMPJVM コマンド。 DMPJVM (Dump Java Virtual Machine) コマンドは、特定のジョブの JVM 情報をダンプします。
      • ANZJVM コマンド。 ANZJVM (Analyze Java Virtual Machine) コマンドは、特定のジョブの Java 仮想マシン (JVM) に関する情報を収集します。 このコマンドは、i5/OS V5R2 以降で使用可能です。
      • Heap Analysis Tools for Java。 このツールは、パフォーマンス・モニター・ツールの iDoctor for iSeries スイートのコンポーネントです。 ヒープ分析ツール・コンポーネントは、時間経過に応じた Java アプリケーションのヒープ分析およびオブジェクト作成プロファイリング (サイズおよび ID) を実行します。 このツールは、Java Watcher または Heap Analyzer と呼ばれることもあります。

      [AIX HP-UX Linux Solaris Windows] Tivoli Performance Viewer を使用すると、メモリー・リークの検出に役立ちます。

      [i5/OS] [AIX HP-UX Linux Solaris Windows] 最良の結果を得るには、 要求を 1000 ページ、2000 ページ、4000 ページと増やして期間を延ばしながら、実験を繰り返してください。Tivoli Performance Viewer のメモリー使用量のグラフは、ぎざぎ ざの形状になるはずです。グラフの落ち込んでいる部分は、それぞれガーベッジ・コレクション に対応しています。 次のいずれかの現象が発生している場合は、メモリー・リークが起こっています。
      • それぞれのガーベッジ・コレクションの直後に、メモリー使用量が急激 に増加する。 パターンはぎざぎざというより階段のような形状になります。
      • ぎざぎざのパターンが不規則な形状をしている。
      さらに、割り振られたオブジェクトの数と、解放されたオブジェクトの 数の差を調べてください。時間の経過とともに両者のギャップが大きくなって いく場合は、メモリー・リークが発生しています。

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

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

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

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

    [i5/OS] i5/OS JVM は、同時 (非同期) ガーベッジ・コレクションを使用します。 このタイプのガーベッジ・コレクションでは、休止時間が短くなり、アプリケーション・スレッドがガーベッジ・コレクション・サイクル中に要求の処理を継続できるようになります。

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

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

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

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

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

    [i5/OS] 意味のある統計値を得るには、アプリケーションが定常状態になるまで固定ワークロードを実行します。 定常状態に達するまで、通常は数分かかります。

    [i5/OS] また、Tivoli Performance Viewer のオブジェクト統計を使用すると、ガーベッジ・コレクション統計をモニターできます。

    ガーベッジ・コレクションのモニターの詳細については、以下を参照してください。
    • パフォーマンス: 学習用リソース for a description of the IBM verbose:gc output
    • [i5/OS] i5/OS インフォメーション・センター内の DMPJVM コマンドの説明。 このコマンドは、特定のジョブの JVM 情報をダンプします。
    • [i5/OS] iDoctor for iSeries の Java のヒープ分析ツールの説明。 このツールは、パフォーマンス・モニター・ツールの iDoctor for iSeries スイートのコンポーネントです。 ヒープ分析ツール・コンポーネントは、時間経過に応じた Java アプリケーションのヒープ分析およびオブジェクト作成プロファイリング (サイズおよび ID) を実行します。 このツールは、Java Watcher または Heap Analyzer と呼ばれることもあります。
    • [i5/OS] i5/OS インフォメーション・センターの "Tuning Garbage Collection for Java(TM) and WebSphere on iSeries" のトピックに含まれる Performance Explorer (PEX) の説明。 Performance Explorer (PEX) トレースを使用して、ガーベッジ・コレクターの CPU 使用量を判別することができます。
    • [Solaris] Solaris オペレーティング環境でのガーベッジ・コレクションについての詳細は、 パフォーマンス: 学習用リソース を参照してください。

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

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

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

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

    [AIX HP-UX Linux Solaris Windows] [z/OS] Java -X オプションを使用して、メモリー・オプションのリストを表示します。

    • [AIX HP-UX Linux Solaris Windows] [z/OS] -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 引数を使用してクラス・ガーベッジ・コレクションを 使用不可にすることで、アプリケーションでクラスをさらに簡単に再利用できます。 クラス・ガーベッジ・コレクションをオフにすると、 同じクラスを複数回ロードおよびアンロードするオーバーヘッドが除去されます。

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

      [AIX HP-UX Linux Solaris Windows] [z/OS] クラス・ガーベッジ・コレクションを使用不可にします。

      [i5/OS] クラス・ガーベッジ・コレクションを使用不可にしないでください。

      使用法: Xnoclassgc はクラス・ガーベッジ・コレクションを使用不可にします。
    Sun JVM ガーベッジ・コレクター。 [Solaris]

    Solaris プラットフォームでは、アプリケーション・サーバーは IBM JVM でなく Sun HotSpot JVM で稼働します。 Sun JVM のパフォーマンス最適化フィーチャーを利用するために、Sun JVM で正しいチューニング・パラメーターを使用することが重要です。

    Sun HotSpot JVM では、 世代ガーベッジ・コレクションによって、最適なパフォーマンスを実現します。 以下のコマンド行パラメーターは、ガーベッジ・コレクションの調整に便利です。

    • -XX:SurvivorRatio

      Java ヒープは、古い (長期間) オブジェクトのセクションと 若いオブジェクトのセクションに分割されます。 若いオブジェクトのセクションは、新規オブジェクトが割り振られるセクション (エデン) と、 使用中の新規オブジェクトが、古いオブジェクト (サバイバー・スペース) にプロモートされる前に、 最初のいくつかのガーベッジ・コレクションで存続しているセクションにさらに分割されます。 Survivor Ratio は、ヒープの若いオブジェクト・セクションでの、 サバイバー・スペースに対するエデンの比率です。 この設定を高くすると、アプリケーションでのオブジェクトの作成率を高くし、 オブジェクトの保持率を低くするよう JVM を最適化します。 WebSphere Application Server インスタンスは、他のアプリケーション・サーバーよりも中長期間のオブジェクトを生成するため、この設定はデフォルトより低くする必要があります。

      デフォルト: 32
      推奨: 16
      使用法: -XX:SurvivorRatio=16
    • -XX:PermSize

      永続世代に予約されたヒープのセクションは、JVM のすべての反射データを保持します。 このサイズは、動的に多くのクラスをロードおよびアンロードするアプリケーションのパフォーマンスを最適化するために増やす必要があります。 これを 128 MB に設定すると、ヒープのこの部分を増やす場合のオーバーヘッドが除去されます。

      推奨: 128 MB
      使用法: XX:PermSize=128m は PermSize を 128 メガバイトに設定します。
    • -Xmn

      この設定は、若い世代がヒープで消費することができるスペース量を制御します。 このパラメーターを適切に調整すると、ガーベッジ・コレクションのオーバーヘッドを削減でき、 サーバー応答時間とスループットが改善されます。 このデフォルト設定は通常は低すぎるため、多数の小さなガーベッジ・コレクションが発生します。 この設定値が高すぎると、JVM は主要な (フル) ガーベッジ・コレクションのみを実行することになります。 これらは通常、数秒かかり、サーバー全体のパフォーマンスに極めて有害な影響を及ぼします。 この状況を回避するには、この設定を全体のヒープ・サイズの半分以下に抑える必要があります。

      デフォルト: 2228224 バイト
      推奨: 全ヒープ・サイズの約 1/4
      使用法: -Xmn256m はサイズを 256 メガバイトに設定します。
    • -Xnoclassgc

      クラスのライブ・インスタンスが残されていない場合、デフォルトで、JVM はメモリーからクラスをアンロードしますが、 これはパフォーマンスを低下させることがあります。 クラス・ガーベッジ・コレクションをオフにすると、 同じクラスを複数回ロードおよびアンロードするオーバーヘッドが除去されます。

      クラスが必要なくなった場合、そのクラスがヒープに占めていたスペースは通常、新規オブジェクトの作成に使用されます。 ただし、アプリケーションがクラスの新規インスタンスの作成による要求を処理し、 そのアプリケーションの要求が不定期に入って来る場合、 通常のクラス・ガーベッジ・コレクションは、前の要求側の終了後に、このクラスが属していたヒープ・スペースを 解放することによって、このクラスをクリーンアップします。 その結果、次の要求が来たときはクラスを再インスタンス化する必要があります。 この状態では、このオプションを使用して、クラスのガーベッジ・コレクションを使用不可にすることができます。

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

    Sun JVM の調整に関する追加情報については、「Performance Documentation for the Java HotSpot VM」を参照してください。

    HP JVM ガーベッジ・コレクター。 [HP-UX]

    HP JVM では、 世代ガーベッジ・コレクションによって、最適なパフォーマンスを実現します。 以下のコマンド行パラメーターは、ガーベッジ・コレクションの調整に便利です。

    • -Xoptgc

      この設定は、アプリケーションで短期間のオブジェクトを 多く生成するよう JVM を最適化します。 このパラメーターが指定されないと、JVM は通常、主要な (フル) ガーベッジ・コレクションを行います。 フル・ガーベッジ・コレクションは、数秒かかり、サーバー・パフォーマンスを大幅に低下させることがあります。

      デフォルト: off
      推奨: on
      使用法: -Xoptgc は最適化されたガーベッジ・コレクションを使用可能にします。
    • -XX:SurvivorRatio

      Java ヒープは、古い (長期間) オブジェクトのセクションと 若いオブジェクトのセクションに分割されます。 若いオブジェクトのセクションは、新規オブジェクトが割り振られるセクション (エデン) と、 使用中の新規オブジェクトが、古いオブジェクト (サバイバー・スペース) にプロモートされる前に、 最初のいくつかのガーベッジ・コレクションで存続しているセクションにさらに分割されます。 Survivor Ratio は、ヒープの若いオブジェクト・セクションでの、 サバイバー・スペースに対するエデンの比率です。 この設定を高くすると、アプリケーションでのオブジェクトの作成率を高くし、 オブジェクトの保持率を低くするよう JVM を最適化します。 WebSphere Application Server インスタンスは、他のアプリケーション・サーバーよりも中長期間のオブジェクトを生成するため、この設定はデフォルトより低くする必要があります。

      デフォルト: 32
      推奨: 16
      使用法: -XX:SurvivorRatio=16
    • -XX:PermSize

      永続世代に予約されたヒープのセクションは、JVM のすべての反射データを保持します。 このサイズは、動的に多くのクラスをロードおよびアンロードするアプリケーションのパフォーマンスを最適化するために増やす必要があります。 値 128 メガバイトを指定すると、ヒープのこの部分を増やすオーバーヘッドを除去します。

      デフォルト: 0
      推奨: 128 メガバイト
      使用法: -XX:PermSize=128m は PermSize を 128 メガバイトに設定します。
    • -XX:+ForceMmapReserved

      このコマンドは遅延スワップ機能を使用不可にし、オペレーティング・システムが大きなメモリー・ページを 使用できるようにします。これにより、Java ヒープを構成するメモリーへのアクセスが最適化されます。 デフォルトで、Java ヒープでは遅延スワップ・スペースが割り振られます。 遅延スワップ機能を使用すると、メモリー・ページが必要に応じて割り振られるため、スワップ・スペースが節約されます。 ただし、遅延スワップ機能では強制的に 4 KB ページが使用されます。 このメモリー割り振りは、大きなヒープ・システムの多数のページわたってこのヒープを広げることができます。

      デフォルト: off
      推奨: on
      使用法: -XX:+ForceMmapReserved は遅延スワップ機能を使用不可にします。
    • -Xmn

      この設定は、若い世代がヒープで消費することができるスペース量を制御します。 このパラメーターを適切に調整すると、ガーベッジ・コレクションのオーバーヘッドを削減でき、 サーバー応答時間とスループットが改善されます。 このデフォルト設定は通常は低すぎるため、多数の小さなガーベッジ・コレクションが発生します。

      デフォルト: デフォルトなし
      推奨: 全ヒープ・サイズの約 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 
    • -Xnoclassgc

      クラスのライブ・インスタンスが残されていない場合、デフォルトで、JVM はメモリーからクラスをアンロードしますが、 これはパフォーマンスを低下させることがあります。 クラス・ガーベッジ・コレクションをオフにすると、 同じクラスを複数回ロードおよびアンロードするオーバーヘッドが除去されます。

      クラスが必要なくなった場合、そのクラスがヒープに占めていたスペースは通常、新規オブジェクトの作成に使用されます。 ただし、アプリケーションがクラスの新規インスタンスの作成による要求を処理し、 そのアプリケーションの要求が不定期に入って来る場合、 通常のクラス・ガーベッジ・コレクションは、前の要求側の終了後に、このクラスが属していたヒープ・スペースを 解放することによって、このクラスをクリーンアップします。 その結果、次の要求が来たときはクラスを再インスタンス化する必要があります。 この状態では、このオプションを使用して、クラスのガーベッジ・コレクションを使用不可にすることができます。

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

    [HP-UX] HP 仮想マシンの調整に関する追加情報については、「Java technology software HP-UX 11i」を参照してください。

  8. [HP-UX] HP JVM for HP-UX の調整 以下のオプションを設定して、 アプリケーションのパフォーマンスを改善します。
    -XX:SchedulerPriorityRange=SCHED_NOAGE 
    -XX:-ExtraPollBeforeRead
    -XX:+UseSpinning
    

    [HP-UX] HP 仮想マシンの調整に関する追加情報については、「Java technology software HP-UX 11i」を参照してください。

  9. [Solaris] Solaris の Sun HotSpot JVM に対するクライアント・モードまたはサーバー・モードの選択

    WebSphere Application Server が Solaris プラットフォームで使用する Java Virtual Machine は、クライアントとサーバーの 2 つのモードで動作します。 各モードにはそれぞれ利点があります。

    クライアント・モードは、使用環境が次の条件を満たす場合に選択することをお勧めします。
    • サーバーのリブートまたは異常終了のあとに短時間でリカバリーする必要がある場合。クライアント・モードを使用すると、仮想マシンを素早くウォームアップすることができるため、アプリケーション・サーバーは開始後に多数の要求を短時間で処理できます。
    • 物理 RAM に制限がある場合。クライアント・モードはサーバー・モードよりもメモリー使用量が少なくなります。 このメモリー節約機能は、ハードウェア制限によって JVM サイズ全体が小さい場合に重要になります。例えば、単一のハードウェアで複数の JVM が稼働している場合は、JVM サイズが小さくなることがあります。

    再始動頻度が少ないアプリケーション・サーバーのパフォーマンスを最大にするには、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 フラグを使用して、仮想マシンを強制的にいずれかのモードに設定することができます。

  10. [AIX HP-UX Linux Solaris Windows] [z/OS] キャッシュ内のクラス共有の使用可能化

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

    [Solaris] [HP-UX] 重要: 以下のプラットフォームでは、IBM J2RE 1.5.0 は、現在使用されていません。
    • [Solaris] Solaris
    • [HP-UX] HP-UX

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

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

    1. 管理コンソールで、「サーバー」 > 「アプリケーション・サーバー」 > 「server」をクリックします。
    2. [AIX HP-UX Linux Solaris Windows] 「サーバー・インフラストラクチャー」の下で、 「Java およびプロセス管理」>「プロセス定義」>「Java 仮想マシン」をクリックします。
    3. [z/OS] 「サーバー・インフラストラクチャー」の下で、「Java およびプロセス管理」>「プロセス定義」をクリックします。
    4. [z/OS] 制御」または「サーバント」のいずれかを選択してから、 「Java 仮想マシン」を選択します。
    5. 「汎用 JVM 引数フィールド」に、-Xshareclasses:none を入力します。
    6. OK」をクリックします。
    7. 変更をマスター構成に保管します。
    8. アプリケーション・サーバーを停止して再始動します。
    デフォルト: キャッシュでのクラス共用オプションは使用可能です。
    推奨: キャッシュでのクラス共用オプションを使用可能のままにしておきます。
    使用法: -Xshareclasses:none はキャッシュでのクラス共用オプションを使用不可にします。
  11. [Solaris] [HP-UX] メモリー使用量を最小化します。
    [Solaris] Sun Java 5.0 JVM のデフォルトのチューニング設定は、前の JVM バージョンより多くのメモリーを使用します。 この追加メモリーは、スループットを最大化するのに役立ちます。 ただし、通常、物理メモリーが非常に重要である JVM ホテリングなどの環境を実行している場合は、問題が生じる可能性があります。 Sun Java 5.0 JVM を調整して最小のメモリー消費を求める場合、汎用 JVM 引数に以下の調整パラメーターを追加することができます。
    -client -XX:MaxPermSize=256m -XX:-UseLargePages -XX:+UseSerialGC

    [Solaris] これらのパラメーターを設定することによって、スループットに影響を与え、わずかにサーバーの起動が遅くなる可能性があります。 かなり大容量のアプリケーションを実行している場合は、MaxPermSize 設定に、より大きな値を指定することができます。

    [HP-UX] HP Java 5 JVM のデフォルトのチューニング設定は、前の JVM バージョンより多くのメモリーを使用します。 この追加メモリーは、スループットを最大化するのに役立ちます。 ただし、通常、物理メモリーが非常に重要である JVM ホテリングなどの環境を実行している場合は、問題が生じる可能性があります。 Sun Java 5.0 JVM を調整して最小のメモリー消費を求める場合、汎用 JVM 引数に以下の調整パラメーターを追加することができます。
    -XX:-UseParallelGC –XX:-UseAdaptiveSizePolicy 
    これらのパラメーターを設定することによって、わずかにサーバーの起動が遅くなる可能性があります。
  12. 大規模なセル構成の構成更新プロセスを調整します。
    大規模なセル構成では、構成更新のパフォーマンスと整合性検査のどちらがより重要かを決定する必要があります。 構成の整合性検査がオンになっている場合は、構成変更の保管または多数のアプリケーションのデプロイに時間がかかることがあります。 必要となる時間に影響する要素は次のとおりです。
    • セル内に定義されたアプリケーション・サーバーまたはクラスターが多ければ多いほど、構成変更の保管にかかる時間が長くなります。
    • セル内にデプロイされたアプリケーションが多ければ多いほど、構成変更の保管にかかる時間が長くなります。
    構成変更にかかる時間に問題がある場合は、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 を使用不可にして、干渉が起こらないようにしてください。

[i5/OS] ご使用のアプリケーションの始動時または最初の操作時に応答速度が遅い場合は、Java ユーザークラス・ローダー・キャッシュを使用することができます。詳しくは、ユーザー・クラス・ローダーによってあらかじめロード済みのクラスのキャッシング を参照してください。




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

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

最終更新: Jan 21, 2008 4:10:06 PM EST
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.wsfep.multiplatform.doc/info/ae/ae/tprf_tunejvm_v61.html