虐待を受けた後、JVMチューニングの原則に関連する知識と経験を共有する

[[399065]]

この記事ではいくつかの原則とアイデアを紹介するだけですが、皆さんのお役に立てれば幸いです。

まず原理を理解し、次に最適化します。

チューニングは一夜にして達成できるものではないことを覚えておくことが重要です。 1 つのパラメータを変更することでチューニングの目的が達成されると期待しないでください。また、1 つのパラメータを変更しただけでチューニングが完了したと想定しないでください。チューニングは、既存のリソースと達成すべき目標との間のトレードオフです。

クラスのロードから JVM 操作サイクル全体までの一般的なプロセスと構造は次のとおりです。

上の図からわかるように、JVM は次の部分に分けられます。

実行エンジン（GC、JIT コンパイラを含む）

クラスローディングサブシステム、この問題は通常開発プロセス中に発生します

JNI部分、この部分の問題は一般的にJVMの外部にあります

ランタイムデータ領域。 Javaはメモリをヒープメモリとスタックメモリの2つの大きなブロックに分割します。

まずは上記の内容をある程度理解した上で、全体の状況を把握することから始める必要があります。上の図を見ると、チューニング中に実行できるのは、ランタイム データ領域に対していくつかの操作を実行し、実行エンジンがガベージをリサイクルするために使用するガベージ コレクターを選択することだけです。

1. この記事のチューニングのアイデアは JVM1.8 のみを対象としています。まずJVM1.8のメモリモデルを見てみましょう

注意: JVM スレッドはシステム スペースを占有するため、JVM ヒープ メモリが大きいほど、システム自体のメモリが少なくなり、当然、生成できるスレッドの数も少なくなります。

2. JVMのチューニングでは、主にヒープメモリサイズの構成とガベージコレクションアルゴリズムの選択という2つの側面を考慮します。

 # ヒープメモリを設定する
-Xmx4g -Xms4g
 # GCアルゴリズムを指定する
-XX:+G1GC を使用 -XX:最大GC一時停止ミリ秒=50
 # GC並列スレッドの数を指定する
-XX:並列GCスレッド=4
 # GCログを印刷
-XX:+PrintGCDetails -XX:+PrintGCDateStamps
 # GCログファイルを指定する
-Xloggc:gc.log
 # メタ領域の最大値を指定する
-XX:最大メタスペースサイズ=2g
 # 単一スレッドスタックのサイズを設定する
-Xss1m
 # ヒープメモリオーバーフローを指定すると自動的にダンプする
-XX:+メモリ不足エラー時のヒープダンプ
-XX:HeapDumpPath=/usr/ローカル 

3. JVM - GCタイプの組み合わせと適用可能な場合

ガベージ コレクションは、Young 領域ガベージ コレクターと Old 領域ガベージ コレクターの 2 つの部分に分かれています。 2 つの部分を組み合わせて使用​​する必要があります。

新世代のコレクター: Serial、ParNew、Parallel Scavenge。

旧世代コレクター: Serial Old、Parallel Old、CMS。

シリアル: 新世代のコレクターは、最も早く、最も成熟したコレクターです。シングルスレッドかつ排他的です。 GC 中はワールドが停止し、アプリケーションが一時停止されます。

ParNew: 新世代のコレクターは、シリアル コレクターのマルチスレッド バージョンです。これは排他的であり、GC 中にワールドを停止し、アプリケーションを一時停止します。

Parallel Scavenge: 新世代のコレクター、ParNew に類似、専用、機能: スループット優先

CMS: (concurrent-mark-sweep)、旧世代のコレクター、非排他的、複数のスレッド、マークおよびクリア アルゴリズム、応答時間優先。欠点は、GC 後にメモリがクリーンアップされないため、メモリの断片化が発生することです。

Serial Old: これはSerialの旧世代バージョンであり、シングルスレッドコレクターであり、排他的である。

Parallel OldはParallel Scavengeコレクターの旧世代バージョンで、マルチスレッドコレクション、排他的

G1: 待望の新世代ガベージコレクター、予測可能な一時停止: これは、CMSに対するG1のもう1つの大きな利点であり、Parallel ScavengeとCMSコレクターの利点を組み合わせながら、それらの欠陥を排除し、非排他的である。

コレクターの品質は主に2つの指標、休止時間とスループットによって決まります。

GC選択の経験

全体として、G1 は JDK11 以前の HotSpot JVM で最も先進的な本番対応ガベージ コレクターです。重要なのは、HotSpot のエンジニアが G1 の継続的な改善に注力していることです。更新された JDK バージョンでは、さらに強力な機能と最適化が導入されます。

ご覧のとおり、G1 は CMS の代替として登場し、一時停止時間の予測可能性やヒープ メモリの断片化の解消など、CMS のさまざまな困難な問題を解決しました。単一業務のレイテンシに非常に敏感なシステムの場合、CPU リソースが制限されていない限り、特に最新バージョンの JVM では、G1 が HotSpot の最良の選択肢であると言えます。もちろん、このレイテンシ削減の最適化には代償が伴います。G1 では、追加の書き込みバリアとデーモン スレッドによりオーバーヘッドが高くなります。システムがスループット優先である場合、または CPU が継続的に 100% 占有されており、単一の GC の一時停止時間が問題にならない場合は、CMS の方が適しています。

つまり、G1 は、メモリが大きくレイテンシが低いシナリオに適しています。

適切な GC アルゴリズムを選択する唯一の方法は、実際に試してみて、どこで意味をなさないかを見つけることです。一般的なガイドラインは次のとおりです。

• システムがスループットを第一に考慮する場合、CPU リソースは最大限に活用され、業務が処理され、並列 GC が使用されます。
• システムが低レイテンシと限られた時間を考慮し、各 GC 時間が可能な限り短い場合は、CMS GC を使用します。
• システム メモリ ヒープが大きく、全体的な平均 GC 時間を制御できるようにするには、G1 GC を使用します。

メモリサイズに関する考慮事項:

• 一般的に、4G 以上は比較的大きいと考えられており、G1 を使用する方が費用対効果が高くなります。
• 一般的に、メモリ サイズが 16G-64G など 8G を超える場合は、G1 GC を使用することを強くお勧めします。

最後に、多くの開発者が見落としがちな質問について説明します。これは、大企業との面接でもよく聞かれる質問です。

JDK 8 のデフォルトの GC とは何ですか?

多くの人は CMS か G1 だと思っているかもしれませんが、実際はどちらでもありません。

答えは、JDK 8 並列 GC が JDK8 のデフォルトの GC 戦略であるということです。デフォルトは、Jdk 1.8.0_181-b13バージョンに基づくParallel Scavenge（新世代）とParallel Old（旧世代）です。

JDK9 以降のバージョンでは、G1 がデフォルトの GC 戦略になることに注意してください。同時に、ParNew + SerialOld の組み合わせはサポートされていません。

最後に、チューニング後も JVM 関連の問題が発生する場合は、「適切に監視し、問題を特定し、結果を確認し、要約する」という 16 語のモットーを思い出してください。