JVMパフォーマンスチューニングを合理的に計画する方法

JVM のパフォーマンス チューニングには多くの側面でのトレードオフが伴い、小さな変更が全体に影響することが多いため、あらゆる側面の影響を総合的に考慮する必要があります。しかし、いくつかの基本的な理論と原則もあります。これらの理論を理解し、これらの原則に従うことで、パフォーマンス チューニングのタスクが容易になります。この記事で紹介した内容をより深く理解するため。以下の内容を理解し、従う必要があります。

1. JVMガベージコレクターを理解する

2. JVMパフォーマンス監視の一般的なツールを理解する

3. GCログを読める

4. チューニングのためにチューニングをしないように注意してください。 JVM チューニングでは、すべてのパフォーマンスの問題を解決できるわけではありません。

これらを理解していない場合は、この記事を読むことはお勧めしません。

[[257523]]

この記事は JVM パフォーマンス チューニングに基づいており、さまざまな JVM パラメータを組み合わせてアプリケーションをチューニングします。主な内容は以下の通りです。

1. JVMチューニングの一般的なプロセス

2. JVMをチューニングする際に注意すべきいくつかのパフォーマンス指標

3. JVMチューニングで習得すべきいくつかの原則

4. チューニング戦略と例

1. パフォーマンスチューニングのレベル

システムのパフォーマンスを向上させるには、システムのあらゆる側面とレベルを最適化する必要があります。以下は最適化する必要があるいくつかのレベルです。

上記から、JVM のチューニングに加えて、対処する必要がある他のいくつかのレベルがあることがわかります。したがって、システム チューニングは JVM チューニングに限定されず、システム パフォーマンスを向上させるために全体的なシステム チューニングが必要になります。この記事では JVM のチューニングについてのみ説明し、他の側面については後で紹介します。

JVM チューニングを実行する前に、プロジェクトのアーキテクチャ チューニングとコード チューニングが実行されているか、現在のプロジェクトに対して最新のものであることを前提としています。これら 2 つは JVM チューニングの基礎であり、アーキテクチャ チューニングがシステムに最も大きな影響を与えます。システム アーキテクチャに欠陥があったり、コード レベルの最適化が尽きないアプリケーションでは、JVM チューニングによって質的な飛躍が達成されるとは期待できません。それは不可能だ。

さらに、チューニングを行う前に、パフォーマンス最適化の目標を明確に設定し、パフォーマンスのボトルネックを見つける必要があります。その後、ボトルネックを最適化するには、アプリケーションに対してストレス テストとベンチマーク テストを実行し、さまざまな監視および統計ツールを使用して、調整されたアプリケーションが関連する目標を達成したかどうかを確認する必要があります。

2. JVMのチューニングプロセス

チューニングの最終的な目標は、アプリケーションが最小限のハードウェア消費でより高いスループットを実現できるようにすることです。 JVM チューニングも例外ではありません。 JVM チューニングは主にガベージ コレクターの収集パフォーマンスを最適化し、仮想マシン上で実行されるアプリケーションが使用するメモリとレイテンシを削減して、スループットを向上させることを可能にします。もちろん、ここでは最小限が最善の選択であり、少ないほど良いというわけではありません。

1. パフォーマンスの定義

パフォーマンスのボトルネックを見つけて評価するには、まずパフォーマンスの定義を知る必要があります。 JVM チューニングでは、評価の基礎として次の 3 つの定義属性を知る必要があります。

• スループット: 重要な指標の 1 つで、ガベージ コレクションによって発生する一時停止時間やメモリ消費を考慮せずに、ガベージ コレクターがアプリケーションで達成できる最大のパフォーマンス指標を指します。
• レイテンシ: そのメトリックは、アプリケーションの実行時にジッターを回避するために、ガベージ コレクションによって発生する一時停止時間を短縮するか、ガベージ コレクションによって発生する一時停止を完全に排除することです。
• メモリ使用量: ガベージ コレクターがスムーズに実行するために必要なメモリの量。

これら 3 つの属性のうち、いずれかのパフォーマンスを向上させるには、ほとんどの場合、他の 1 つまたは 2 つの属性のパフォーマンスを犠牲にする必要があります。また、両方を実現することはできません。特定の属性または 2 つの属性のパフォーマンスはアプリケーションにとってより重要であり、アプリケーションのビジネス ニーズに基づいて決定する必要があります。

2. パフォーマンスチューニングの原則

チューニング プロセス中は、ガベージ コレクションのチューニングをより簡単に完了し、アプリケーションのパフォーマンス要件を満たすために、次の 3 つの原則を念頭に置く必要があります。

1. マイナー GC 収集の原則: 各マイナー GC は、可能な限り多くのガベージ オブジェクトを収集する必要があります。アプリケーションでの Full GC の頻度を減らします。

2. GC メモリ最適化の原則: スループットとレイテンシの問題に対処する場合、ガベージ プロセッサが使用できるメモリが大きいほど、ガベージ コレクションの効果が向上し、アプリケーションがよりスムーズになります。

3. GC チューニングの 3 択 2 原則: パフォーマンス属性、スループット、レイテンシ、メモリ使用量のうち、チューニング対象として選択できるのは 3 つすべてではなく、2 つだけです。

3. パフォーマンスチューニングプロセス

上記は、アプリケーションの JVM チューニングの基本的なプロセスです。 JVM チューニングは、パフォーマンス テストの結果に基づいて構成を継続的に最適化する反復的なプロセスであることがわかります。各システム要件指標が満たされるまで、前の各ステップは複数回繰り返される場合があります。場合によっては、特定の指標を達成するために、以前のパラメータを複数回調整し、その後、以前のすべての手順を再度テストする必要があります。

さらに、チューニングは通常、プログラムのメモリ使用量要件を満たすことから始まり、次に時間遅延要件、最後にスループット要件を満たします。これらの手順に基づいて継続的な最適化を実行する必要があります。各ステップは次のステップの基礎となるものであり、元に戻すことはできません。以下に各ステップの詳細な例を示します。

JVM の動作モードに関しては、JDK1.6 以降で公式に推奨されているモードでもあるサーバー モードを直接選択します。

ガベージ コレクターに関しては、jdk1.6-1.8 のデフォルトの並列コレクター (新世代の場合は parallelGC、旧世代の場合は parallelOldGC) を直接採用しました。

3. メモリ使用量を決定する

メモリ使用量を決定する前に、次の 2 つの点を知っておく必要があります。

• アプリケーションランタイム
• JVM メモリ割り当て

1. 運用フェーズ

アプリケーションの実行フェーズは、次の 3 つのフェーズに分けられます。

1. 初期化フェーズ: JVM はアプリケーションをロードし、アプリケーションのメイン モジュールとデータを初期化します。

2. 安定段階: この時点では、アプリケーションはほとんどの時間実行されます。ストレステスト後、さまざまなパフォーマンスパラメータが安定しています。コア関数が実行され、JIT コンパイルによって予熱されています。

3. 概要フェーズ: プロジェクトの概要フェーズでは、いくつかのベンチマーク テストが実施され、対応するポリシー レポートが生成されます。この段階は無視できます。

メモリ使用量とアクティブ データのサイズを決定するには、プロジェクトの開始時ではなく、プログラムの安定した段階で行う必要があります。それを判断するには、まず次の JVM メモリ割り当てを見てみましょう。

2. JVM メモリ割り当てとパラメータ

JVM ヒープ内のメイン スペースは、上記の新しい世代、古い世代、および *** 世代で構成されます。ヒープ全体のサイズ = 新しい世代のサイズ + 古い世代のサイズ + *** 世代のサイズ。具体的なオブジェクトの昇格方法についてはここでは詳しく紹介しません。ヒープ サイズを指定するための JVM コマンド パラメータをいくつか見てみましょう。以下のパラメータを指定しない場合、仮想マシンは適切な値を自動的に選択し、システムのオーバーヘッドに基づいて自動的に調整します。

設定する際、*** 世代のサイズ調整には FullGC の実装が必要となるため、パフォーマンスのオーバーヘッドが懸念される場合は、*** 世代の初期値を *** 値と同じ値に設定するようにしてください。

3. アクティブデータのサイズを計算する

アクティブ データ サイズを計算するには、次の手順に従う必要があります。

前述したように、アクティブ データは、アプリケーションの安定フェーズ中に Java ヒープ内でオブジェクトが占有するスペースの長期的な存続とサイズを観察することに基づく必要があります。

アクティブ データを計算するときは、次の条件を確保する必要があります。

1. テスト中、起動パラメータは jvm のデフォルトパラメータを使用し、手動で設定されません。

2. フル GC が発生したときにアプリケーションが安定したフェーズにあることを確認します。

デフォルトの jvm パラメータを使用してアプリケーションを起動する目的は、安定フェーズでアプリケーションに必要なメモリ使用量を観察することです。

安定期とは何ですか?

アプリケーションと本番環境のピーク状態と同様の負荷を見つけるのに十分な圧力を生成する必要があります。ピークに達した後は安定した状態を維持し、安定期とみなされます。したがって、安定段階に到達するためには、ストレステストが不可欠です。この記事では、ストレス テストの適用方法については詳しく説明しません。後ほど特別に紹介します。

アプリケーションが安定段階にあると判断した場合は、アプリケーションの GC ログ、特に Full GC ログに注意してください。

GC ログの指示: -XX:+PrintGCTimeStamps -XX:+PrintGCDetails -Xloggc:

GC ログは、チューニングに必要な情報を収集する最適な方法です。実稼働環境でも、GC ログを有効にして問題を特定できます。 GC ログを有効にしてもパフォーマンスにはほとんど影響はありませんが、豊富なデータが提供されます。

FullGC ログが存在する必要があります。そうでない場合は、監視ツールを使用して 1 回強制的に呼び出しを行うか、次のコマンドを使用して呼び出しをトリガーすることができます。

 jmap -histo:ライブPID

安定フェーズ中に FullGC がトリガーされると、通常は次の情報が取得されます。

上記の GC ログから、fullGC が発生したときのアプリケーション全体のヒープ使用量と GC 時間を大まかに分析できます。もちろん、より正確さを期すためには、複数回収集して平均値を得る必要があります。あるいは、最長の FullGC を使用して推定することもできます。

上図では、fullGC 後、旧世代のスペースは 93168kb (約 93MB) を占めており、これを旧世代のスペースのアクティブ データとして定義します。

その他のヒープ領域の割り当ては、次の規則に基づいています。

上記のルールと上図の FullGC 情報に基づいて、アプリケーション ヒープ領域を次のように計画できます。

Java ヒープ領域: 373Mb (= 旧世代領域 93168kb*4)

新世代のスペース: 140Mb (= 旧世代のスペース 93168kb*1.5)

*** 生成スペース: 5Mb (=*** 生成スペース 3135kb*1.5)

旧世代のスペース: 233Mb = ヒープスペース - 新世代のスペース = 373Mb - 140Mb

対応するアプリケーションの起動パラメータは次のようになります。

java -Xms373m -Xmx373m -Xmn140m -XX:PermSize=5m -XX:MaxPermSize=5m

4. レイテンシーの調整

アプリケーションのアクティブ データ サイズを決定した後、レイテンシ チューニングを実行する必要があります。現在のヒープ メモリ サイズのレイテンシ要件はアプリケーションのニーズを満たすことができないため、アプリケーションの状況に基づいてデバッグを実行する必要があります。

このステップでは、ヒープ サイズ構成を再度最適化し、GC の期間と頻度を評価し、別のガベージ コレクターに切り替える必要があるかどうかを判断します。

1. システム遅延要件

チューニングする前に、システムのレイテンシ要件と対応するレイテンシ調整可能なインジケーターを把握しておく必要があります。

アプリケーションの許容可能な平均ダウンタイム: この時間は、測定されたマイナー GC 期間と比較されます。

許容可能なマイナー GC 頻度: マイナー GC の頻度が許容値と比較されます。

許容可能な最大一時停止時間: 最大一時停止時間は、最悪の場合の FullGC の継続時間と比較されます。

*** 一時停止の許容頻度: 基本的には FullGC の頻度です。

上記のうち、平均ダウンタイムと最大ダウンタイムはユーザーエクスペリエンスにとって最も重要であり、より注意を払う必要があります。

上記の要件に基づいて、次のデータを収集する必要があります。

MinorGC の期間。

MinorGC の数をカウントします。

FullGC の最悪な期間。

最悪の場合の FullGC の頻度。

2. 新世代のサイズを最適化する

たとえば、上記の gc ログでは、マイナー GC の平均実行時間は 0.069 秒であり、マイナー GC の頻度は 0.389 秒ごとに 1 回であることがわかります。

システムの平均停滞時間を 50 ミリ秒に設定した場合、現在の 69 ミリ秒は明らかに長すぎるため、調整する必要があります。

新しい世代のスペースが大きいほど、マイナー GC の GC 時間が長くなり、頻度が低くなることがわかっています。

期間を短縮したい場合は、サイズを縮小する必要があります。

頻度を減らしたい場合は、スペースのサイズを増やす必要があります。

新しい世代のサイズの変更による他の領域への影響を最小限に抑えます。新しい世代のスペースのサイズを変更するときは、古い世代のスペースのサイズを維持するようにしてください。

たとえば、新しい世代のスペースのサイズが 10% 削減された場合、古い世代と永続世代のサイズは変更されません。最初の最適化後のパラメータは次のとおりです。

java -Xms359m -Xmx359m -Xmn126m -XX:PermSize=5m -XX:MaxPermSize=5m 新しい世代のサイズが 140m から 126 に変更され、ヒープ サイズもそれに応じて変更されます。この時点では、古い世代は変わりません。

3. 古い世代のサイズを最適化する

前の手順と同様に、最適化の前に GC ログ データも収集する必要があります。今回は、FullGC の期間と頻度について検討します。

上の図では、

FullGC の平均頻度 = 5.8 秒 FullGC の平均所要時間 = 0.14 秒 (上記はテスト用であり、実際のプロジェクトの fullGC はそれほど速くありません)

FullGC ログがない場合、それを評価する方法はありますか?

オブジェクトの昇格率で計算できます。

オブジェクトの昇格率

たとえば、上記の起動パラメータでは、古い世代のサイズ = 233Mb です。

旧世代の 233 MB の空き領域を埋めるのにかかる時間は、新世代から旧世代への昇格率によって異なります。

古い世代の占有率の増加 = 各マイナーGC後のJavaヒープ占有率からマイナーGC後の新しい世代のスペース占有率を引いた値

オブジェクト昇格率 = 平均値（各時点で占有される旧世代領域の量）を旧世代領域で割った値

オブジェクトの昇格率を使用すると、古い世代のスペースを埋めるのに必要なマイナー GC の数を計算し、フル GC のおおよその時間を計算できます。

例えば：

上の写真では:

最初のマイナー GC 後、旧世代のスペース: 13740kb - 13732kb = 8kb2 番目のマイナー GC 後、旧世代のスペース: 22394kb - 17905kb = 4489kb3 番目のマイナー GC 後、旧世代のスペース: 34739kb - 17917kb = 16822kb4 番目のマイナー GC 後、旧世代のスペース: 48143kb - 17913kb = 30230kb5 番目のマイナー GC 後、旧世代のスペース: 62112kb - 17917kb = 44195kb

旧世代の各マイナーGCの改善率

4481kb 2番目と1番目のマイナーGCの間 12333kb 3番目と2番目のマイナーGCの間 13408kb 4番目と3番目のマイナーGCの間 13965kb 5番目と4番目のマイナーGCの間

次のように計算できます:

各マイナーGCの平均改善は12211kb、つまり約12Mbです。上図では、平均マイナーGC頻度は213ms/時間改善率 = 12211kb/213ms = 57kb/msです。旧世代のスペースは 233 MB で、これを埋めるのに約 233*1024/57=4185 ミリ秒、つまり約 4.185 秒かかります。

上記の 2 つの方法を使用して、FullGC の予想される最悪の頻度持続時間を推定できます。 FullGC の頻度は、古い世代のサイズを調整することで調整できます。もちろん、FullGC の期間が長すぎて、アプリケーションの最悪のレイテンシ要件を満たすことができない場合は、ガベージ コレクターを切り替える必要があります。具体的な切り替え方法については、次の記事で説明します。例えば、CMS に切り替える場合、CMS のチューニング方法は若干異なります。

5. スループットのチューニング

上記の長いチューニング プロセスを経て、ようやくチューニングの最後のステップ、つまり上記の結果のスループットをテストし、微調整を行う段階に到達しました。

スループットのチューニングは、主にアプリケーションのスループット要件に基づいて行われます。アプリケーションには、アプリケーション全体の要件とテストから導き出された包括的なスループット インジケーターが必要です。アプリケーションのスループットが予想されるスループット目標に達するかそれを超えると、チューニング プロセス全体が正常に完了します。

チューニング後にアプリケーションのスループット目標を達成できない場合は、スループット要件を確認し、現在のスループットと目標のギャップが大きいかどうかを評価する必要があります。 20% 程度であれば、パラメータを変更し、メモリを増やして、最初から再度デバッグすることができます。大きい場合は、アプリケーション レベル全体を考慮して、設計とターゲットが一貫しているかどうかを確認し、スループット ターゲットを再評価する必要があります。

ガベージ コレクターの場合、スループットを向上させるためのパフォーマンス チューニングの目標は、FullGC または Stop-The-World 圧縮ガベージ コレクション (CMS) を回避するか、ほとんど発生しないようにすることです。これは、どちらの方法でもアプリケーションのスループットが低下するためです。オブジェクトが古い世代に急速に昇格されるのを避けるために、MinorGC フェーズでより多くのオブジェクトをリサイクルするようにしてください。

六、***

Plumbrが実施した特定のゴミ収集業者の利用状況に関する調査によると、研究データは84,936件が使用されました。ガベージ コレクターが明示的に指定された 13% のケースでは、同時実行コレクター (CMS) が最も多く使用されました。しかし、ほとんどの場合、*** ガベージ コレクターは選択されませんでした。この割合は約87%です。

JVM のチューニングは体系的かつ複雑なタスクです。現在、JVM での自動調整はかなりうまく行われています。いくつかの基本的な初期パラメータにより、一般的なアプリケーションが比較的安定して実行されることが保証されます。チームによっては、プログラムのパフォーマンスがそれほど重要でない場合があり、デフォルトのガベージ コレクターで十分な場合があります。チューニングは自分の状況に基づいて行う必要があります。

著者: wier_ali