虐待を受けた後、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 アルゴリズムを選択する唯一の方法は、実際に試してみて、どこで意味をなさないかを見つけることです。一般的なガイドラインは次のとおりです。