Sun が開発し、HP が移植した HotSpot Java™ 仮想マシン (JVM) のアーキテクチャーは、IBM が開発した Software Development Kit (SDK) とは異なって発展してきています。その内部構造は、若い (または古い) 世代領域と永続領域に対して、第一に世代別ガーベッジ・コレクションをサポートするほか、必要に応じて他のガーベッジ・コレクション・モードもサポートするために設計されています。
始める前に
注: このトピックでは、
1 つ以上のアプリケーション・サーバー・ログ・ファイルを参照します。推奨される代替案として、分散システムや IBM® i システムの SystemOut.log、SystemErr.log、trace.log、activity.log ファイルではなく、High Performance Extensible Logging (HPEL) ログおよびトレース・インフラストラクチャーを使用するようにサーバーを構成できます。また HPEL は、ネイティブ z/OS® ロギング機能と連携させて使用することができます。HPEL を使用する場合、LogViewer コマンド・ライン・ツールを
サーバー・プロファイルの bin ディレクトリーから使用して、すべてのログ・ファイルにアクセスし、
情報をトレースできます。HPEL の使用について詳しくは、HPEL を使用してのアプリケーションの
トラブルシューティングに関する情報を参照してください。
このタスクについて
Sun HotSpot JVM の調整は、JVM 構成が作成され、データが (主に verbosegc データから) 収集された後に分析され、構成の改訂があればそれが次のサイクルに適用される、という 1 つの反復プロセスです。
ご使用の Sun HotSpot JVM を調整する必要がある場合は、以下のステップのいずれか (複数の場合あり) を実行します。
手順
- 十分な Java ヒープ・メモリーを用意します。
Java ヒープ・メモリーは、予約済みの一連の連続アドレスです。Java ヒープ・メモリーのサイズは、Java ヒープが構成される最大サイズです。これらのアドレスは、他のネイティブ・メモリー要求またはシステム・メモリー要求には使用できず、JVM によってのみ保守および管理されます。これは、Java ヒープが、その JVM の存続する間、Java オブジェクト・ストレージに使用されるからです。
JVM が初期化される時点で、Java ヒープのセキュア・リソースが JVM 構成設定に従って獲得されます。使用可能なメモリーが十分ではない場合、JVM の初期化は失敗します。
Java ヒープに構成されたメモリーが十分でない場合、通常はまず、大きなガーベッジ・コレクション・アクティビティーが発生しますが、最終的にシステムに障害が起こって OutOfMemory レポートが出されます。したがって、この間は Java 処理はほとんど行われません。
ご使用のプロセスの他のコンポーネントのネイティブ・メモリーの所要量についは十分に考慮し、スレッドの実行、入出力用データの保管、およびアライメントやページ・サイズの要件などを満たすことができるようにする必要があります。
Sun HotSpot Java ヒープは、最大 Java ヒープ・サイズの指定時に考慮する必要のある、物理的に独立した 2 つの部分で構成されています。
- 永続領域。これは、さらに eden スペース、survivor スペース、tenured 領域に細分化される若い世代と古い世代の領域の組み合わせです。
- このシステムの Java コンポーネント用提供メモリー。
-XX:MaxPermSize= および -Xmx (最大 Java ヒープ・サイズ) パラメーターはそれぞれ、永続領域の最大サイズとメイン・ヒープの最大サイズを構成します。永続領域の最大サイズでは、クラス・コードと関連データが古い世代領域の一部として論理的に示されますが、物理的には別々に保持されます。また、メイン・ヒープの最大サイズでは、Java オブジェクトとそのデータが若い世代または古い世代領域のいずれかに保管されます。永続領域とメイン・ヒープを合わせて、全体の Java ヒープを構成します。これらのいずれかの領域での割り振り失敗は、すべてのアプリケーション・コード、またはすべてのアプリケーション・データ (いずれも終端条件) を収容できないことを表し、そのため、使用可能なストレージを使い尽くして、OutOfMemory エラーを引き起こす可能性があります。
以下の調整パラメーターを参考にしてください。
- -XX:MaxPermSize (永続領域)
- -Xmx (最大 Java ヒープ・サイズ)
- システムのソフトウェア・コンポーネントに導入されている可能性のある不要な、またはタイミングが誤っている主要ガーベッジ・コレクション・サイクルを除去するには、ガーベッジ・コレクションを明示的に使用不可にします。
調整パラメーター -XX:+DisableExplicitGC を確認します。
トラブルの回避 (Avoid trouble): デフォルトでは、特定のクラスの使用可能なライブ・インスタンスが存在しない場合、JVM は常にメモリーからそのクラスをアンロードします。
-Xnoclassgc 引数を使用すると、クラス・ガーベッジ・コレクションを使用不可にできます。ただし、クラス・ガーベッジ・コレクションのパフォーマンスへの影響は通常ごくわずかです。Java Platform, Enterprise Edition (Java EE) ベースのシステムではアプリケーションのクラス・ローダーが頻繁に使用されるため、クラス・ガーベッジ・コレクションをオフにすると、事実上クラス・データのメモリー・リークが発生し、JVM でメモリー不足による例外がスローされる場合があります。
-Xnoclassgc 引数を使用する場合、アプリケーションを再デプロイする必要があるたびに、必ずアプリケーション・サーバーを再始動して、前バージョンのアプリケーションのクラスおよび静的データを消去する必要があります。
gotcha
-Xnoclassgc 引数を使用して、アプリケーションを再デプロイする必要がある場合は、必ずアプリケーション・サーバーを再始動し、前バージョンのアプリケーションからクラスおよび静的データをクリアする必要があります。
- ガーベッジ・コレクション・アクションを最適化するように領域サイズを調整します。
ガーベッジ・コレクションの調整の試行は、ガーベッジ・コレクターの振る舞いに基づいて決める必要があります。
ご使用のアプリケーションの操作上のニーズを満たすには、正しいガーベッジ・コレクション・モードを識別する必要があります。
また、パフォーマンス要件を満たしているかどうか、アプリケーションの要求を常に満たすのに十分なメモリー・リソースを効率的にリサイクルしているかどうかも確認する必要があります。
ガーベッジ・コレクション・パラメーター設定に対して行うすべての変更では、十分に異なる結果をもたらし、HotSpot Java ヒープのさまざまな領域を利用することで得られる利点を示す必要があります。
反復調整プロセスは十分に繰り返す必要があるため、通常、無分別に選択すると、調整プロセスを長引かせることになります。
以降のセクションでは、並列スループットまたは並行低停止時間の 2 つの基本選択肢と、さらに調整を行うための関連オプションについて説明します。
どちらのモードも高いパフォーマンスを提供する可能性がありますが、重要なパフォーマンス要因は、最適化された振る舞いがそれぞれのモードごとに異なるということです。
主要な調整アクティビティーは、リソース使用率の制御に関係します。これによって、アプリケーションの割り振りアクティビティーが提供され、しかも、必要に応じてストレージがリサイクルされるような効率的なガーベッジ・コレクションの調整が行われるようになります。
これらの調整の検討は必然的に、使用するガーベッジ・コレクション・モードによって異なります。
ここでは 2 つのタイプのガーベッジ・コレクションを検討します。
- 若い世代に対してコレクションの並列スカベンジ・コピーを実行するスループット・コレクター。
このタイプのガーベッジ・コレクションは、マルチプロセッサー・サーバー・クラス・マシンにおけるデフォルト・タイプです。
- 並行低停止時間コレクター。
こうしたコレクターによる調整の目的は、ご使用のアプリケーション・システムの割り振りパターンおよびオブジェクトの存続時間に対して、最も適した振る舞いを提供し、コレクション・アクションの効率を最大化することです。
- オプション 1: 組み込み調整を有効にして、デフォルトのスループット/並列スカベンジ・コレクターを使用。
バージョン 5 以降の Sun HotSPot JVM では、サーバーが稼働しているオペレーティング・システムの一部の検出が可能になっており、また、JVM はマルチプロセッサーの有無や物理メモリーのサイズに応じて、適切な世代別ガーベッジ・コレクション・モード (並列または直列のいずれか) のセットアップを試みます。
製品が実動モードおよび実動前モードで稼働するハードウェアすべてが、サーバー・クラス・マシンと見なされるための要件を満たしている必要があります。
ただし、ある種の開発ハードウェアはこの基準を満たさない場合があります。
スループット・ガーベッジ・コレクターの振る舞いは、調整が自動で行われるか否かにかかわらず同じままであり、Java アプリケーション・システムの実行において重要な一時停止を何度か引き起こします。この一時停止は、使用されるヒープ・サイズに比例して発生するもので、Java アプリケーション・システムが世代別ガーベッジ・コレクションの利点を最大化しようとする際に発生します。ただし、これらの自動アルゴリズムは、ワークロードが十分にそのアクションに見合っているかどうか、あるいは、システムには別のガーベッジ・コレクション・ストラテジーが必要なのではないか、またはシステムにより適しているのは別のガーベッジ・コレクション・ストラテジーではないか、などを自動的に判別することはできません。
以下の調整パラメーターを参考にしてください。
- -XX:+UseParallelGC
- -XX:+UseAdaptiveSizePolicy
- -XX:+AggressiveHeap
- オプション 2: デフォルトのスループット/並列スカベンジ・コレクターを使用するが、調整は手動で行う。
-XX:+UseAdaptiveSizePolicy パラメーターを使用して設定される組み込みアルゴリズムを使う方法の欠点としては、-XX:SurvivorRatio パラメーターなどの他のパラメーターを組み込みアルゴリズムと組み合わせて構成しても、可能にできる操作が限られている点があげられます。
組み込みアルゴリズムを使用する場合は、実行中に使用されるリソース割り振りの決定に対するある種の制御を手放します。
組み込みアルゴリズムを使用した結果に満足できない場合は、アルゴリズムのアクションを試行し、調整するよりも、JVM リソースを手動で構成する方が簡単です。
JVM リソースの手動による構成には、アルゴリズムのアクションの調整に使用する場合の半分の数のオプションが使用されます。
以下の調整パラメーターを参考にしてください。
- -XX:NewRatio=2 これは、VM モード用に構成するサーバーのデフォルトです。
- -XX:MaxNewSize= および -XX:NewSize=
- -XX:SurvivorRatio=
- -XX:+PrintTenuringDistribution
- -XX:TargetSurvivorRatio=
- オプション 3: 並行低停止時間 mark-sweep コレクター
このコレクターは、Hotspot アーキテクチャーを支える、世代別ガーベッジ・コレクションの発展から完全に逸脱したものであり、アプリケーション・スレッド処理が、専用の低優先順位の、バックグラウンド・ガーベッジ・コレクション・スレッドとオーバーラップすることを余儀なくします。
ご使用のアプリケーション・データに、デフォルト・スループット・コレクターの振る舞いとの互換性がない場合、特に侵入的一時停止を許容しないアプリケーション・システムでは、並行 mark-sweep (CMS) コレクターが実行可能なストラテジーになる可能性があります。
このコレクターは、寿命の長いデータの大きなセット (大きな tenured 世代とも呼ばれる) を持つ、64 ビット JVM または 64 ビット・アプリケーションで使用される、非常に大きなヒープで特に役立ちます。これによって、バックグラウンド・スレッドで全ヒープのすべてのページを走査しなければならない場合も主として若い世代のページを保持することで、比較的適切なキャッシュ使用率が維持されます。
並行 mark-sweep コレクターを第 1 のハウスキーピング・エージェントとして使用するには、ご使用の JVM 構成に、他のガーベッジ・コレクション・モードの代わりに次のオプションを追加します。
以下の調整パラメーターを参考にしてください。
- -XX:+UseConcMarkSweepGC
- -XX:CMSInitiatingOccupancyFraction=75
- -XX:SurvivorRatio=6
- -XX:MaxTenuringThreshold=8
- -XX:NewSize=128m
CMS による調整の難しさの中に、CMS サイクルの異常終了を引き起こすワースト・ケースのガーベッジ・コレクション時の最後に数秒かかる場合があることが挙げられます。これは、長時間の一時停止を厳密に回避するために CMS を使用するシステムにとって、特に大きな代償となります。
このため、サービス・レベル・アグリーメントで CMS の使用を指示する場合があります。これは、平均一時停止時間 (中央値) が非常に短く、調整で CMS サイクルが異常終了しないよう細心の注意を払う必要があるからです。
CMS が成功するのは、予想トリガーで次のことが保障される場合のみです。つまり、フリー・リソースが要求される前に、確実に十分なフリー・リソースが使用可能になっているように、CMS サイクルが常に早く開始することが保障される場合のみです。
tenured 世代がいっぱいになる前に CMS コレクターが終了できない場合は、アプリケーション・スレッドを一時停止することによりコレクションを完了します (これを、フル・コレクションといいます)。
フル・コレクションの発生は、CMS コレクターをご使用のアプリケーションにより適したものにするために、さらに調整が必要であることを表しています。
最終的に CMS を使用すると、圧縮フェーズのある他のガーベッジ・コレクション・モードとは異なり、HotSpot で発生するフラグメント化のリスクが理論的に高まります。
ただし、コレクションがヒープの正常な比率を回復するので、これが問題になることはほとんどありません。
CMS が失敗した場合、あるいはコレクションが異常終了した場合は、代わりの圧縮ガーベッジ・コレクションがトリガーされます。
他のどのタイプのガーベッジ・コレクションでも、必然的に、通常の CMS コレクションと比べて重大な侵入的一時停止が発生します。
トラブルの回避 (Avoid trouble): スループット・コレクターの場合と同様、明示的に CMS を制御するために使用できるオプションはこのほかにも数多く存在します。ただし、ここに挙げたオプションは、HotSpot JVM の調整を行う際に使用の検討が必要となる、中心的なオプションです。
gotcha
次のタスク
通常は verbosegc を使用してデータの収集と分析を行い、構成を評価します。JVM のパフォーマンスに満足するまで、調整を変更しながらデータの収集と分析を続けてください。