この章では、パフォーマンスを安定させるためにJVMをチューニングする方法について説明します。
JVMが適切にチューニングされていないと、最初は問題なく動作していても、徐々にパフォーマンスの低下や長いレイテンシが起こり始めたり、パフォーマンスが大幅に変動することがあります。
この章では、以下のトピックについて説明します。
パフォーマンスの変動を時間の経過に応じて測定および分析するには、長時間実行して、現在のパフォーマンスを継続して報告するテストが必要です。テスト・シナリオは、できるかぎり現実に即したシナリオにし、できるかぎり多くのユース・ケースを網羅する必要があります。
パフォーマンスの変動を確認したら、この変動がJVM内のイベント(ガベージ・コレクション、断片化、ロックの引き下げなど)に関連しているかどうかを確認するために、Oracle JRockit JVMの監視を開始することができます。Oracle JRockit Mission Controlのツールと、-
Xverbose
オプションの使用時に生成される冗長出力が、この変動の分析に役立ちます。
表8-1に、確認対象のイベントと、各イベントを検出および分析するためのツールの一覧を示します。
表8-1 JVMのイベント
イベント・タイプ | 確認する対象 | 分析用のツール |
---|---|---|
ヒープ・サイズの変更 |
ヒープの増加または減少 |
|
ナーサリ・サイズの変更 |
ナーサリ・サイズの増加または減少 |
|
ガベージ・コレクタ方式の変更 |
動的なガベージ・コレクション・モードによるガベージ・コレクション方式の変更 |
|
断片化の増加 |
ダーク・マターの量の増加 |
JRockitフライト・レコーダ |
完全な圧縮 |
すべてのヒープ・パーツの同時圧縮 |
|
実行時にヒープ・サイズが変更されると、パフォーマンスに変動が生じることがあります。ヒープ・サイズは、-Xverbose:memdbg
出力およびJRockit Mission Controlツールで監視できます。JRockitフライト・レコーダ記録では、ヒープ・サイズが記録中に変更されたかどうかもわかります。
時間の経過とともにパフォーマンスを均等化するには、初期ヒープ・サイズ(-Xms
)を最大ヒープ・サイズ(-Xmx
)と同じ値に設定する必要があります。
例:
java -Xms:1g -Xmx:1g myApplication
ヒープ・サイズのチューニングの詳細は、4.1.1項「ヒープ・サイズを設定する」を参照してください。
実行時にナーサリ・サイズが変更されると、パフォーマンスに変動が生じることがありますが、負荷が変化したときに高いパフォーマンスを維持するためにも役立ちます。ナーサリ・サイズは、-Xverbose:memdbg
出力およびJRockit Mission Controlツールで監視できます。フライト・レコーダ記録では、ナーサリ・サイズが記録中に変更されたかどうかもわかります。
アプリケーションでのパフォーマンスの変動がナーサリ・サイズの変更に関連していることがわかったら、-Xns
オプションを使用して静的なナーサリ・サイズを設定できます。
例:
java -Xns:100m myApplication
ナーサリ・サイズのチューニング方法の詳細は、4.1.2項「ナーサリおよび保持領域のサイズを設定する」を参照してください。
注意: ナーサリ・サイズの動的な設定のヒューリスティックをオーバーライドすると、実行中にライブ・データの量が変化するアプリケーションでパフォーマンスに負の影響を与えたり、パフォーマンスの変動が発生することがあります。 |
JRockit JVMのガベージ・コレクション・モードでは、実行時の情報に基づいてガベージ・コレクション方式が選択されます。アプリケーションの動作に変更があると、ガベージ・コレクション・モードが変更される場合があります。このような変更が頻繁に発生してパフォーマンスの変動が起こる場合は、別のガベージ・コレクション・モードを選択できます。ガベージ・コレクション・モードを変更するには、-Xgc:
mode
オプションを使用します。
例:
java -Xgc:genpar myApplication
詳細は、4.2.1項「ガベージ・コレクション・モードを選択する」を参照してください。
Oracle JRockit JVMはマーク・アンド・スイープ・ガベージ・コレクション・モデルを使用します(詳細は、『Oracle JRockit JDKの紹介』のマーク・アンド・スイープ・モデルに関する項を参照)。
このマーク・アンド・スイープ・ガベージ・コレクション・モデルを使用すると、ヒープの断片化が進行する場合があります。したがって、ヒープの空き領域の数は増えますが小さくなります。JVMでは、断片化を緩和するため、ガベージ・コレクションを行うたびにヒープの部分的な圧縮を行います。場合によっては、圧縮の量が十分ではないこともあります。このような場合には断片化が進行するため、ヒープが断片化して完全な圧縮が実行されるまで、ガベージ・コレクションがより頻繁に実行されるようになります。完全な圧縮が行われた後は、ガベージ・コレクションの頻度が下がりますが、断片化がまた進行するにつれて徐々に頻度が増します。
この動作によって、Javaアプリケーションのパフォーマンスは変動します。ガベージ・コレクションの頻度が増すにつれて、パフォーマンスは低下します。完全な圧縮の実行中は、ガベージ・コレクションの休止時間が長くなることがあり、これによってしばらくJavaアプリケーション全体が休止状態になります。この後で、パフォーマンスは再び高くなりますが、ガベージ・コレクションの頻度がまた増すにつれて、パフォーマンスは低下し始めます。
圧縮率およびガベージ・コレクションの頻度は、-Xverbose:memdbg
出力、管理コンソールおよびフライト・レコーダ記録で監視できます。フライト・レコーダ記録では、ヒープに存在するダーク・マター(重度の断片化)の量も示されます。完全な圧縮が行われるまで、ガベージ・コレクションが増え続ける場合は、圧縮率を上げる必要があります。圧縮のチューニングの詳細は、4.3項「圧縮のチューニング」を参照してください。
世代別ガベージ・コレクタを使用する方法でも、ヒープの断片化を緩和できます。詳細は、4.2項「ガベージ・コレクタの選択とチューニング」を参照してください。