JVM の主要なシステムパラメータの紹介と詳細な構成

[[331547]]

序文

-XX:+PrintFlagsFinalはパラメータ値を出力します

オンラインで最適化可能なパラメータを見つけたら、まずそれを印刷してください。デフォルトで有効になっている可能性があります。次に別のものを探すと、デフォルトで有効になっている可能性があります...

一部のパラメータ値は JDK7 と JDK8 の間で異なり、JDK7 の異なるマイナー バージョン間でも異なるため、インターネット上の記事は信頼しないでください。すべては、実稼働環境で同じバージョンの JDK によって印刷された値に基づく必要があります。

多くの場合、パラメータを確認するには次のようなステートメントを使用します。面倒な場合は、代わりに -version を使用してください。一部のパラメータは設定後に他のパラメータに影響を与えるため、それらも含める必要があります。

 java -XX:+UseConcMarkSweepGC -XX:+PrintFlagsFinal -バージョン| grep GCThreads

各バージョンにおけるデフォルト値については、傾向に従うことをお勧めします。そのバージョンで JDK がデフォルトでオンまたはオフになっているのには必ず理由があります。安全第一。インターネット上の記事（今読んでいる記事も含む）で推奨されているからといって、十分な理由がない限り設定しないでください。

1. パフォーマンス

1.1 推奨されるパフォーマンスパラメータ

1. バイアスロックを解除: -XX:-UseBiasedLocking

JDK1.6 以降では、バイアス ロックがデフォルトでオンになっており、ロックにアクセスする最初のスレッドにロックを割り当て、同期ブロック上の同期プリミティブをキャンセルしようとします。常に 1 つのスレッドのみがアクセスしている場合は、同期操作が正常にスキップされ、パフォーマンスが向上します。

ただし、2 番目のスレッドがこのロックにアクセスすると、JVM はバイアス ロックを取り消して以前の状態を復元します。セーフポイントログを開くと、GC Stop The World の作業と同じような RevokeBiasd レコードが多数表示されます。ほんの短い一時停止ですが、マルチスレッドの同時実行アプリケーションの場合、これをキャンセルするとパフォーマンスが向上するため、Cassandra はこれをキャンセルします。

2. 整数キャッシュを増やす: -XX:AutoBoxCacheMax=20000

ステートメント Integer i=3; int を自動的に Integer にボックス化します。デフォルトでは、JDK は -128 から +127 までの Integer オブジェクトと Long オブジェクトのみをキャッシュします。数値が範囲外の場合は、新しい Integer オブジェクトを直ちに構築する必要があります。 20,000 に設定すると、アプリケーションの QPS が 4% 増加しました。なぜ20,000なのですか？これは -XX:+AggressiveOpts の値だからです。詳細については、「Java 整数 (-128~127) 値の == および equals 比較に関する考察」を参照してください。

3. 起動時にメモリページにアクセスしてゼロにする: -XX:+AlwaysPreTouch

起動時には、パラメータで指定されたすべてのメモリが使用されるため、起動が少し遅くなる可能性がありますが、その後のアクセスはスムーズになります。たとえば、ページは連続的に割り当てられ、ページは古い世代に昇格されるまでアクセスされず、GC 一時停止時間が長くなります。 ElasticSearch と Cassandra の両方で有効になっています。

4. SecureRandom 生成の高速化: -Djava.security.egd=file:/dev/./urandom

この民間療法の理由は、Tomcat の SecureRandom が SHA1PRNG アルゴリズムを明示的に使用すると、初期要素がデフォルトで /dev/random から読み取られ、輻輳が発生するためです。ボーナスとして、SecureRandom のデフォルトのアルゴリズムも、より適切な SHA1 に変更されました。詳細は「SecureRandomの民間療法と実際の効果」をご覧ください

1.2 オプションのパフォーマンスパラメータ

1. -XX:+PerfDisableSharedMem

高 IO 時に JVM の一時停止が発生するまで、私が注目したことのなかった Cassandra のパラメータ。 JVM は、統計データを /tmp/hperf ディレクトリに静かに書き込むことがよくあることが判明しました。 PageCache がディスクをフラッシュし、ファイルがブロックされた場合、Stop the World のセーフ ポイントを終了できません。

JVM による統計データの書き込みを無効にすると、jps と jstat が使用できなくなり、JMX のみが使用できるようになります。ただし、JMX は、新世代と旧世代の使用率を取得する場合、jstat ほど便利ではありません。 VJTools の vjmxcli がこれを補います。詳細については、「4 か月のバグ: JVM 統計によりガベージ コレクションが一時停止する」を参照してください。

2. -XX:-UseCounterDecay

JIT 呼び出しカウンターの減少を無効にします。デフォルトでは、GC が実行されるたびに呼び出しカウンターが半分になるため、一部のメソッドはウォーム状態のままになり、C2 コンパイルをトリガーする 10,000 回のしきい値に到達しません。

3. -XX:-階層化コンパイル

マルチレイヤーコンパイルは、JDK8 以降ではデフォルトで有効になっている比較的誇らしい機能です。まず、C1 で静的コンパイルを実行し、十分なサンプリングを行った後に C2 コンパイルを実行します。

ただし、実際のテストでは、パフォーマンスが 2% わずかに低下することが示されています。これは、C1 がコンパイルされた後、一部のメソッドが C2 によってコンパイルされなくなったためである可能性があります。また、アプリケーションの起動時に、コンパイルがビジー状態であるために、サービス タイムアウトが発生することも多々あります。したがって、これを無効にしますが、一部のウォーム メソッドが永久に解釈および実行されるのを回避するために、前の -XX:-UseCounterDecay をオンにすることを忘れないでください。

1.3 推奨されないパフォーマンスパラメータ

1. -XX:+アグレッシブオプト

デフォルトでは有効になっていない最適化パラメータのセット。-XX:AutoBoxCacheMax はその 1 つです。ただし、前述したように、重要なシステムではこれを有効にすることはお勧めしません。 -XX:+AggressiveOpts と -XX:-AggressiveOpts を比較すると、これまで 3 つのパラメータのみが変更されていますが、将来のバージョンの JDK でより積極的な構成が暗黙的に変更されるのを避けるために、これを有効にしない方がよいでしょう。

2. 一定数の関数呼び出し後にコンパイルを開始するしきい値や、インライン関数のサイズのしきい値など、JIT コンパイルに関連するパラメータを変更しないでください。

3. -サーバー。 64 ビット マルチコア Linux では -client に設定できないため、記述しても無駄です。

2. メモリとGC

2.1 GC戦略

安定性のために、8G 未満のヒープには CMS を使用することをお勧めします。 G1 は現在デフォルトですが、小さなヒープでのパフォーマンスは CMS より優れていません。 JDK11 の ZGC は、依然として期待する価値があります。

1. 基本的なCMSの書き方

-XX:+ConcMarkSweepGC を使用 -XX:CMSInitiatingOccupancyFraction=75 -XX:+CMSInitiatingOccupancyOnly を使用

監視システムは JMX を通じてメモリが 90% に達するのを監視するため、75% で実行を開始するように設定します。早期に開始すると、Full GC などの予期しない状況も軽減されます (概念を繰り返しますが、このアクティブ CMS GC は、古い世代、永続世代、およびオフヒープ メモリがメモリをまったく割り当てられない場合に JVM が強制する Full GC とは異なります)。この設定を有効にするには、以下も設定する必要があります。

CMSInitiatingOccupancyOnly を使用します。そうでない場合、75% は最初に参照値としてのみ使用され、後で JVM によって計算されます。

2. -XX:MaxTenuringThreshold=2

これは、変更効果が最も顕著なパラメータです。オブジェクトが Old 世代に昇格する前に Survivor スペースで存続できる Young GC の最大数。 JDK8 の CMS のデフォルト値は 6 ですが、G1 などの他の場合は 15 です。

Young GC はアプリケーションの一時停止の最大の原因であり、Young GC 後に存続するオブジェクトの数は一時停止期間に直接影響します。したがって、Young GC の実行頻度とアプリケーション内のほとんどの一時オブジェクトの最大ライフ サイクルがわかっている場合は、それを短く設定して、一時オブジェクトではない新しい世代のオブジェクトを古い世代にすばやく昇格させ、そこに留まらないようにすることができます。

-XX:+PrintTenuringDistribution を使用して、後続の世代のサイズが常に同じである場合、特定の年齢以降のオブジェクトは常に古い世代に昇格できることが証明されることを確認します。この場合、プロモーションしきい値をより小さい値に設定できます。たとえば、JMeter では 2 で十分です。

3. -XX:+

ExplicitGCInvokesConcurrent は追加しないが、-XX:+DisableExplicitGC は追加しない

プロセス全体を一時停止するのではなく、フル GC 中に CMS アルゴリズムを使用します。これは必須です。

しかし、R が述べたように、システム GC は保護メカニズムです (オフヒープ メモリがいっぱいになったときにヒープ内の参照オブジェクトをクリーンアップするなど)。 system.gc() を無効にすることは必ずしも良いことではありません。特に悪いクラスライブラリを使用していない限り、誰かが調整する理由があるはずなので、この共通パラメータは追加しないでください。

4. -XX:+ParallelRefProcEnabled および -XX:+

CMSParallelInitialMark 有効

WeakReference などの Reference オブジェクトの並列処理は、デフォルトでは false になっています。 GC ログに長い参照処理時間を示すログがない限り、効果はあまり明白ではありません。ただし、JVM を常に可能な限り並列化したいので、それを設定します。同様に、-XX:+がある。

CMSParallelInitialMarkEnabled は JDK8 ではデフォルトで有効になっていますが、マイナー バージョンが低い JDK7 でもサポートされていません。

5. ParGCCardsPerStrideChunk

Linkined のブラックテクノロジー、2016 バージョンではオンにすることは推奨されていません。その後、いくつかのシナリオでは実際に YGC 時間を短縮できることが判明しました。詳細については、「彼らの言うことは本当か？」を参照してください。簡単に言えば、YGC 中に古い世代をスキャンする時間に影響します。デフォルト値の 256 は小さすぎますが、32K は適切ではない可能性があります。自分で実験してみる必要があります。

-XX:+UnlockDiagnosticVMOptions -XX:ParGCCardsPerStrideChunk=1024

2.2 オプションのGCパラメータ

1. 同時収集スレッドの数

ParallelGCThreads＝8+(プロセッサ - 8) (5/8);集中GCスレッド = (並列GCスレッド + 3)/4

たとえば、デュアル CPU、6 コア、ハイパースレッディングは 24 個のプロセッサを意味します。プロセッサ数が 8 未満の場合、ParallelGCThreads はプロセッサ数に基づいて計算されます。プロセッサの数が 8 を超える場合、上記の式が使用されます: YGC スレッドの数 = 18、CMS GC スレッドの数 = 5。

CMS GC スレッド数の計算式はあまりにも奇妙であるため、単に YGC スレッド数の 1/2 に変更することを提案する人もいます。

ログ収集用の logstash など、一時停止時間を気にしないバックグラウンド補助プログラムの場合は、GC 中に突然 CPU コアを過剰に占有してメイン アプリケーションに影響を与えないように、一時停止時間を 2 に減らすことをお勧めします。

多数のサイドカーを実行するアプリケーションなど、サーバーを独占しない他のアプリケーションの場合も、YGC スレッドの数を減らすことをお勧めします。

実際のケースでは、デフォルトで 18 個の YGC スレッドを備えた 24 コアのサーバーです。近くでビジー状態の Service Mesh Proxy が実行されているため、これらの 18 個のスレッドは CPU を 100% 取得できず、GC が不当に遅くなります。スレッド数を 12 に減らすと、実際には速度が向上します。そのため、CPU コアの数に合わせて YGC スレッドの数を貪欲に設定すると、状況が悪化することになります。

2. -XX:-CMSClassUnloadingEnabled

CMS では、永続世代の期限切れのクラスは、Full GC を待たずにクリーンアップされます。デフォルトでは JDK7 は閉じられており、JDK8 は開かれています。たとえば、Groovy などの動的言語スクリプトを実行して多数の一時クラスを生成するかどうかなど、状況によって異なります。 CMS GC の一時停止時間が大幅に長くなる場合があります。したがって、新しいクラスが頻繁にロードされない場合は、このパラメータを明示的にオフにすることをお勧めします。

3. -XX:+CMSScavengeBeforeRemark

デフォルト設定はオフです。 CMS リマークの前に、新しい世代をクリアするためにマイナー GC が実行されます。これにより、旧世代のオブジェクトによって参照される新世代のオブジェクトの数が減り、世界全体を停止する CMS リマーク フェーズが短くなります。ただし、これをオンにすると、YGC の後に CMS GC が続くため、合計一時停止時間が長くなります。

別の実際のケースでは、CMS GC 時間は新しい世代の使用状況に比例します。新しい世代が小さい場合は、すぐに完了します。新しい世代がほぼいっぱいになると、CMS GC 一時停止時間が 2 秒を超えます。現時点では、これをオンにする方がまだ費用対効果が高いです。

2.3 推奨されないGCパラメータ

1. -XX:+ParNewGCを使用する

CMS を使用する場合、新しい世代のコレクションではデフォルトで CMS が使用されるため、自分で設定する必要はありません。

2.-XX:CMSFullGCsBeforeCompaction

デフォルト値は 0 です。これは、Full GC が実行されるたびに古い世代がデフラグされ、圧縮されることを意味します。フル GC は、古い世代が 75% になったときにトリガーされる CMS GC とは異なります。これは、古い世代が 100% に達し、オフヒープ メモリがいっぱいで、古い世代のフラグメントが大きすぎて、新しく昇格された大きなオブジェクトにスペースを割り当てることができない場合にのみ発生します。したがって、毎回デフラグするように設定するのが適切です。詳細については、この投稿の R の説明を参照してください。

3.-XX:+GCLocker が同時呼び出しを行う

私たちが犯した間違いは、「Concurrent」という単語を含むすべてのパラメータが適切なパラメータであるとは限らないということでした。追加後、JNI GCLocker に遭遇したときに、YGC を補正するだけで済みましたが、YGC + CMS GC を実行する必要があります。

2.4 メモリサイズの設定

実際、明示的に設定された -Xmx ヒープ メモリに加えて、JVM にはメモリを消費する他の場所 (オフヒープ メモリ、スレッド スタック、永続世代、バイナリ コード キャッシュ) も多数あり、容量計画中に注意を払う必要があります。

通常、サーバーには重要なビジネス システム用の十分なメモリがあるため、少し緩めに設定してもかまいません。

1. -Xmx、-Xms、ヒープメモリサイズ、2〜4Gが許容されます。

2. -Xmn または -XX:NewSize または -XX:NewRatio

デフォルトでは、JDK の新世代はヒープ サイズの 1/3 を占有します。個人的には、新しい世代を増やすことで GC の頻度を減らすことができるため、半分に分割することを好みます。古い世代に長期オブジェクトがあまりない場合、通常 2/3 は多すぎます。 -Xmn を使用して値を直接割り当てることもできます (これは -XX:NewSize と -XX:MaxNewSize の省略形です)。また、NewRatio を 1 に設定してサイズを半分に分割することもできます。

3. -XX: PermSize=128m -XX:MaxPermSize=512m (JDK7) -XX:MetaspaceSize=128m -XX:MaxMetaspaceSize=512m (JDK8)

現在のアプリケーションには、Hibernate/Spring やその他のノイズの多いアプリケーションが含まれており、AOP 以降のクラスも多数あります。最初は初期値を 64M から 128M に設定し (そうしないと、最初の自動拡張で JVM が約 3 秒間停止します)、保険のために最大値を大きく設定することができます。

JDK8 の不滅世代は、マシンのメモリをほぼすべて使い果たす可能性があります。同様に保護用の初期値として 128M、最大値として 512M が設定されています。

2.5 その他のメモリサイズ設定

1. -Xss

ヒープに加えて、スレッドはスタック メモリを占有します。これは、スレッドごとにデフォルトで 1M になります (以前は 256K)。メソッド呼び出しパラメータ、ローカル変数、スカラー置換後のローカル変数などを格納するためのスタック。Cassandra など、メモリを節約してより多くのスレッドを開くために、これを 256k に戻す人もいますが、エラーが発生した後、特に深い JSON 解析などの再帰呼び出しがある場合に、これを大きく設定する人もいます。

2. -XX:生存率

新しい世代の各 Survivor ゾーンのデフォルト サイズは 8 で、これは新しい世代の 1/(SurvivorRatio+2) の 1/10 です。新しい世代のためにスペースを節約するためにサイズを小さく設定することを好む人もいますが、サイズが小さすぎて Survivor ゾーンが一時オブジェクトを収容できず、強制的に古い世代に昇格されることを回避するために、GC ログから実際の状況を確認できます。

3. -XX:最大ダイレクトメモリサイズ

オフヒープ メモリの最大値は、デフォルトで、ヒープ領域の合計メモリから Survivor 領域のサイズを引いた値になります。詳細については、「Netty オフヒープ メモリ リテラシー」を参照してください。それほど多く使用しないことが確実な場合は、特にコンテナ内でメモリ使用量をより明確に見積もるために、積極的に小さい値に設定することもできます。

4. -XX:予約コードキャッシュサイズ

JIT コンパイル後のバイナリ コードの保存領域がいっぱいになるとコンパイルが停止し、パフォーマンスに大きな影響を与えます。 JDK7 では、デフォルトで 48M のマルチレイヤー コンパイルが有効になっていません。 JDK8 では、デフォルトで 240M のマルチレイヤー コンパイルが有効になっています。 JMX で CodeCache の使用状況を確認したり、VJTools で vjtop を使用したりできます。 JDK7 でのデフォルトの 48M は、それほどケチになるのではなく、もっと大きく設定できます。

3. 監視

JVM によって出力されるさまざまなログは、パスが指定されていない場合、通常、アプリケーションが実行されているディレクトリと同じディレクトリに生成されます。起動スクリプトが異なる場所で実行されることを避けるために、ログ パスは通常、固定の場所に設定されます。

3.1 推奨される監視構成

1. -XX:+PrintCommandLineFlags

運用および保守担当者は、起動パラメータに一時的な変更を加え、将来の参照用に各起動のパラメータを stdout に出力する場合があります。出力されるのは、コマンド ラインで設定されたパラメーターと、これらのパラメーターによって暗黙的に影響を受けるパラメーターです。たとえば、CMS をオンにすると、-XX:+UseParNewGC も自動的にオンになります。

2. -XX:-OmitStackTraceInFastThrow

例外に対して StackTrace を設定するのはコストのかかる操作であるため、アプリケーションが同じ例外を同じ場所で N 回 (20,000 回?) スローすると、JVM は NPE、配列の範囲外などの特定の例外を最適化し、例外スタックを保持しなくなります。この時点で、ログに Nul Point Exception が表示されることがありますが、以前に完全なスタックを出力したログはスクロールされてしまい、NPE がどこで発生したのか分からず、困惑することになります。したがって、これを無効にし、ElasticSearch も無効にします。

3.2 クラッシュファイル

1. -XX:エラーファイル

JVM がクラッシュすると、ホットスポットは JVM ステータス情報の詳細を提供するエラー ファイルを生成します。前述のように、ファイルをあらゆる場所で探す必要がないように、固定ディレクトリに出力します。ファイル名の%pはアプリケーションのPIDに自動的に置き換えられます。

-XX:エラーファイル=${LOGDIR}/hs_err_%p.log

2. コアダンプ

もちろん、より良い方法はコアダンプを生成することです。 CoreDump からは、ヒープ ダンプ、スレッド ダンプ、クラッシュの場所をエクスポートできるため、非常に便利です。

起動スクリプトに ulimit -c unlimited またはその他の設定を追加します。ルート権限がある場合は、出力ディレクトリを設定することをお勧めします。

echo "/{MYLOGDIR}/coredump.%p" > /proc/sys/kernel/core_pattern

何？ coredump が何に役立つか分かりませんか?あなたは JVM セグメント エラーに遭遇したことがない幸運な人のようです。

3. -XX:+

HeapDumpOnOutOfMemoryError (オプション)

メモリ不足になり、JVM が停止しそうになると、指定されたファイルにヒープ ダンプが出力されます。そうしないと、開発者はエラーを再現する方法がわからないことがよくあります。

パスはディレクトリのみを指し、JVM はファイル名を java_pid${pid}.hprof という一意の名前に維持します。ファイルをポイントしたときにそのファイルがすでに存在する場合、そのファイルに書き込むことはできないからです。

-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=${LOGDIR}/

ただし、コンテナ環境では、4G の HeapDump を出力すると、通常のハードディスクでディスク IO が 20 秒以上いっぱいになり、これも完全に悪影響を及ぼし、同じホスト上の他のすべてのコンテナに影響を及ぼします。

3.3 GCログ

JDK9 は全く異なるため、ここでは JDK7/8 用の設定を記述します。

1. 基本構成

-Xloggc:/dev/shm/gc-myapp.log -XX:+PrintGCDateStamps -XX:+PrintGCDetails

GC ログを書き込むとパフォーマンスに影響が出るのではないかと心配する人もいますが、テストしてみると、実際には影響はありません。 GC の問題は Java で最も一般的な問題ですが、ログなしではどうすればよいのでしょうか?

その後、IO が高い状況で、オペレーティング システムが GC 中に pageCache をディスクにフラッシュしている場合、GC ログ ファイルがロックされ、GC が終了しなくなる可能性があることを発見しました。そのため、このような一時停止を回避するために、メモリ内ファイルシステム /dev/shm を指定します。詳細については、「バックグラウンド IO トラフィックによって発生する大規模な JVM GC 一時停止の排除」を参照してください。

タイムスタンプの代わりに人間が判読できる日付を印刷するには、PrintGCTimeStamps ではなく PrintGCDateStamps を使用します。

2. -XX:+PrintGCアプリケーション停止時間

これは非常に重要なパラメータです。その名前は良くありません。明確で完全な GC 一時停止時間を印刷することに加えて、バイアス ロックのキャンセル、エージェントによるクラスの再定義、コードの最適化解除など、その他の JVM 一時停止時間も印刷できます。これは、以前は予想されていなかった問題を見つけるのに役立ちます。追加することをお勧めします。実際に不明な一時停止が見つかった場合は、セーフ ポイント ログを印刷して原因を特定する必要があります。

3. -XX:+PrintGCCause

AllocationFailure などの GC の原因の出力は、JDK8 ではデフォルトで有効になっていますが、JDK7 では明示的に有効にする必要があります。

4. -XX:+印刷プロモーション失敗

これをオンにすると、新しい世代のオブジェクトが古い世代に昇格できず、Full GC がトリガーされたときに、新しい世代のオブジェクトの大きさがわかります。

5. GCログのローリングとバックアップ

デフォルトでは、GC ログは再起動後にクリアされます。長時間実行されるアプリケーションによってファイルが非常に大きくなることを心配する人もいますが、パラメータ「-XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=10 -XX:GCLogFileSize=1M」を使用すると、ログをローテーションできます。しかし、再起動後のファイル名がわかりにくくて面倒です。 GC ログがどれだけ大きくても、使用できません。そのため、ローリングを追加せず、起動スクリプトで古いログを自分でバックアップしました。

3.4 セーフポイントログ

GC ログに GC 以外の JVM 一時停止時間が含まれている場合は、詳細を取得するためにセーフ ポイント ログを印刷する必要があります。詳細については、「JVM の Stop The World、Safe Point、Dark Underworld」を参照してください。

 -XX:+PrintSafepointStatistics -XX:PrintSafepointStatisticsCount=1 -XX:+UnlockDiagnosticVMOptions -XX:-DisplayVMOutput -XX:+LogVMOutput -XX:LogFile=/dev/shm/vm-myapp.log

3.5 の

-Dcom.sun.management.jmxremote.port=7001 -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.authenticate= false -Dcom.sun.management.jmxremote.ssl= false -Djava.rmi.server.hostname=127.0.0.1

上記の設定では、Zabbix などのローカル監視ソフトウェアが JMX 経由で JVM を監視することのみが許可され、リモート アクセスは許可されません。

アプリケーションが上記のパラメータを追加するのを忘れ、パラメータを変更してサービスを再起動したくない場合は、VJTools の vjmxcli を使用して問題を解決できます。 PID を介してターゲット JVM に直接接続し、JMX を開くことができます。

4. まとめ

読んでいただきありがとうございます。上記のすべての内容は、実際には VJTools の jvm-options.sh にあります。