[Sticky JVM] JVM チューニングとは何ですか?

[[403435]]

この記事はWeChatの公開アカウント「Mu Xiaonong」から転載したもので、著者はMu Xiaonongです。この記事を転載する場合は、穆小農の公式アカウントまでご連絡ください。

JVM のチューニングを学習するには、JVM のパラメータのいくつかを事前に知って、より効果的に使用できるようにする必要があります。

JVM共通コマンドラインパラメータ

JVM コマンドラインパラメータリファレンス: https://docs.oracle.com/javase/8/docs/technotes/tools/unix/java.html

1. パラメータリストを表示する

仮想マシンパラメータは、基本カテゴリと拡張カテゴリに分かれています。基本パラメータのリストを取得するには、コマンドラインに JAVA_HOME\bin\java と入力します。拡張パラメータリストを取得するには、コマンドラインに JAVA_HOME\bin\java-X と入力します。

2. 基本パラメータの説明:

-client、-server: 2 つの Java 仮想マシン起動モード。クライアントモードは起動が速くなりますが、パフォーマンスとメモリ管理は比較的劣ります。サーバーモードでは起動が遅くなりますが、実行パフォーマンスは向上します。 Windows ではクライアントモードが使用され、Linux ではサーバーモードが使用されます。
-classpath -cp: 仮想マシンがクラスを実行する場合、それをメモリに転送する必要があります。仮想マシンは、ブートストラップクラス、拡張クラス、ユーザークラスの順序でクラスを検索します。 Bootstrap 内のパスは、仮想マシンに付属する jar または zip ファイルです。仮想マシンは最初にこれらのパッケージファイルを検索します。仮想マシンが検索するパッケージ名を取得するには、System.getProperty("sun.boot.class.path") を使用します。拡張機能は、jre\lib\ext ディレクトリにある jar ファイルです。仮想マシンは、Bootstrap を検索した後、このディレクトリ内の jar ファイルを検索します。仮想マシンで使用される拡張機能の検索パスを取得するには、System.getProperty("java.ext.dirs") を使用します。ユーザークラスの検索順序は、現在のディレクトリ、環境変数 CLASSPATH、および -classpath です。
-classpath: 仮想マシンにディレクトリ名、jarファイル名、zipファイル名を検索するように指示します。
-verbose[:class|gc|jni]: 出力デバイスに仮想マシンの実行情報を表示します -verbose:class 仮想マシンによってロードされたクラスに関する情報を出力します -verbose:gc 仮想マシンでメモリがリサイクルされるときにデバイス情報を出力します。仮想マシンのメモリリサイクルを監視するために使用されます -verbose:jni 仮想マシンがネイティブメソッドを呼び出すときに設定表示情報を出力します。仮想マシンがネイティブメソッドを呼び出す状況を監視するために使用されます
-version: 利用可能な仮想マシンのバージョン情報を表示します
-showversion: バージョン情報とヘルプ情報を表示します

3. 拡張パラメータの説明:

-Xmixed: -client モードの仮想マシンを設定して、頻繁に使用されるメソッドに対して Just-In-Time コンパイルと実行を実行し、その他のメソッドに対しては解釈を使用します。このモードは仮想マシンのデフォルトモードです
-Xint: -client モードで実行されている仮想マシンを設定して、クラスのバイトコードを解釈形式で実行します。バイトコードをネイティブコードにコンパイルすると、パフォーマンスが低下する可能性があります。
-Xbootclasspath:path、-Xbootclasspath/a:path、-Xbootclasspath/p:path: 仮想マシンを変更して、システムランタイムパッケージ rt.jar をロードし、-Xbootclasspath で設定された検索パスからシステムランタイムクラスをロードします。自分でランタイムを作成できない限り、このパラメータは使用されません。 /a: デフォルトの検索パスの後に、パスに検索パスを追加します。 /p: デフォルトの検索パスの前に、パス内の検索パスを検索します。
-Xnoclassgc: クラスに対する仮想マシンのガベージコレクション機能をオフにします。これにより、OutOfMemoryError が発生する可能性があります。
-Xincgc: デフォルトではオフになっている増分ガベージコレクターを有効にします。インクリメンタルガベージコレクターは、不定期に発生する長いガベージコレクションによって発生する一時停止時間を短縮できますが、インクリメンタルガベージコレクターとアプリケーションは同時に実行されるため、アプリケーションの CPU 機能が一部占有されます。
-Xloggc:file: 仮想マシンの各ガベージコレクションの情報をログファイルに書き込みます。ファイル名はfileで指定します。ファイル形式はフラットファイルです。内容は-verbose:gcの出力と同じです。
-Xms20M: 仮想マシンの使用可能なメモリヒープ初期サイズを 20M に設定します。これは 1024 の整数倍であり、1MB より大きくする必要があります。より大きなメモリ番号を設定するには、K または M を単位として使用できます。初期ヒープサイズは2MBです。例: -Xms256M
-Xmx20M: 仮想マシンのメモリヒープの最大使用可能サイズを設定します。この値は 1024 の整数倍で、2 MB より大きい必要があります。より大きなメモリ番号を設定するには、単位として K または M を使用できます (例: -Xmx81920K、-Xmx80M)。アプリケーションが大量のメモリを要求すると、仮想マシンは java.lang.OutOfMemoryError をスローするため、-Xmx を使用して設定する必要があります。
-Xss128K: スレッドスタックのサイズを設定します。 -Xmx と同様に、K または M を使用してより大きな値を設定できます。 Java でスレッドオブジェクトを作成するときにスタックサイズを設定することもできます。
-Xoss128k: ローカルメソッドスタックのサイズを 128K に設定します。ただし、HotSpot は仮想マシンスタックとローカルメソッドスタックを区別しないため、このパラメーターは HotSpot では無効です。
-XX:PermSize=10M: JVMによって最初に割り当てられた永続世代の容量を示します。これはM単位である必要があります。
-XX:MaxPermSize=10M: JVM が割り当てることを許可する永続世代の最大容量を示します。 M単位である必要があります。ほとんどの場合、このパラメータのデフォルトは64Mです。
-XX:NewRatio=4: 若い世代と古い世代の比率を 1:4 に設定します。つまり、若い世代はヒープ全体の 1/5 を占めます。
-XX:SurvivorRatio=8: は、2 つの Survivor 領域と 1 つの Eden 領域のサイズ比を 2:8 に設定することを意味します。つまり、Survivor 領域は若い世代全体の 1/5 を占めます。このパラメータのデフォルト値は8です
-Xmn20M: 若い世代のサイズを20Mに設定することを示します
-XX:+HeapDumpOnOutOfMemoryError: メモリオーバーフロー例外が発生したときに仮想マシンが現在のヒープメモリダンプスナップショットをダンプできることを示します。
-XX:+UseG1GC: JVMがG1ガベージコレクターを使用することを示します
-XX:+PrintGCDetails: GCの詳細をコンソールに出力します
-XX:+PrintGC: はGC情報をコンソールに表示することを意味します
-XX:PretenureSizeThreshold=3145728 は、3145728 (3M) より大きいオブジェクトが古い世代に直接割り当てられることを意味します。ここで単位として使用できるのはバイトのみです。
-XX:MaxTenuringThreshold=1: オブジェクトの年齢が1より大きいことを示し、自動的に古い世代に入ります。

仮想マシンパラメータ分類

標準: - で始まり、すべてのホットスポットでサポートされます。非標準: -X で始まり、特定のバージョンの HotSpot が特定のコマンドをサポートします。不安定: -XX で始まり、次のバージョンではキャンセルされる可能性があります。

例: java -version、java -X

 java.util.List をインポートします。 
 
 java.util.LinkedList をインポートします。 
 
 
 
 
パブリッククラスHelloGC { 
 
公共 静的void main(String[] args) { 
 
システム。 .println( "HelloGC!" );を出力します。 
 
リスト list = new LinkedList(); 
 
のために（;;） { 
 
バイト[] b = 新しいバイト[1024*1024]; 
 
リストに追加(b); 
 
 } 
 
 } 
 
 }

概念を区別する: メモリリーク、メモリ不足
java -XX:+PrintCommandLineFlags HelloGC
java -Xmn10M -Xms40M -Xmx60M -XX:+PrintCommandLineFlags -XX:+PrintGC HelloGC
PrintGCDetails PrintGCTimeStamps PrintGCCauses
java -XX:+UseConcMarkSweepGC -XX:+PrintCommandLineFlags HelloGC
java -XX:+PrintFlagsInitial デフォルトパラメータ値
java -XX:+PrintFlagsFinal 最終パラメータ値
java -XX:+PrintFlagsFinal | grep xxx で対応するパラメータを検索します
java -XX:+PrintFlagsFinal -version |grep GC

チューニング前の基本概念

1. スループット: ユーザーコード時間 / (ユーザーコード実行時間 + ガベージコレクション時間)

2. 応答時間: STW (Stop The World) が短いほど、応答時間は短くなります。

いわゆるチューニングに関しては、まず、スループットなのか応答時間なのか、あるいは特定の応答時間を満たすにはどの程度のスループットが必要なのかなど、何を求めているのかを明確にする必要があります。一般的には、ビジネスの種類に応じて適切なチューニング方法を選択します。たとえば、Web サイトで応答時間を優先する必要がある場合は、JDK1.8 の場合は G1 を選択してください。データマイニングの場合は、スループットを使用する必要があります。

チューニングとは何か

チューニングに触れる前は、JVM チューニングは OOM 問題を解決するものだと理解していました。 OOM は JVM チューニングの一部にすぎません。

通常、JVM の計画と事前チューニングは、需要に応じて実行されます。
JVM オペレーティング環境を最適化する (遅い、スタック)
JVM動作中に発生するさまざまな問題（OOM）を解決する

まず、ビジネスシナリオからチューニングが始まります。ビジネスシナリオなしでの JVM チューニングは信頼できません。たとえば、実際のプロジェクトでは、多数のクラスや数千のコードが存在する場合があります。どのコードに問題があるかをどのように知るのでしょうか?コードの一部が頻繁にフル GC されることがわかっていても、しばらくすると OOM になる可能性があります。

チューニング手順:

ビジネスシナリオに精通し、ガベージコレクターを選択します (最適なガベージコレクターはなく、最も適したものだけがあります)

応答時間、一時停止時間 [CMS G1 ZGC] (ユーザーに応答する必要がある)

スループット = ユーザー時間 / (ユーザー時間 + GC 時間) [PS]

コレクターのコレクションを選択する
メモリ要件を計算します（メモリサイズを1.5G 16Gに設定）
CPUを選択: 高いほど良い
年齢を設定して年齢をアップグレードする
ログパラメータの設定

1.-Xloggc:/opt/xxx/logs/xxx-xxx-gc-%t.log -

XX:+GCログファイルのローテーションを使用 -XX:GCログファイルの数=5 -

XX:GCLogFileSize=20M -XX:+PrintGCDetails -

XX:+PrintGCDateStamps -XX:+PrintGCCause

2. または毎日ログファイルを生成する

実稼働環境では、ログファイルの後にはログ名が続き、システム時間に従って周期的に生成されます。ログは5本あり、それぞれサイズは20Mです。これの利点は、全体のサイズが 100M であるため、全体のファイルサイズを制御できることです。

ログの状況を観察する

チューニングケース

ケース1

1 日あたり最大 100 万件の注文を処理する垂直型電子商取引の場合、注文システムを処理するにはどのようなサーバー構成が必要ですか?

この質問は、多くの異なるサーバー構成がサポートできるため、あまり役に立ちません。

たとえば、注文が 100 万件ある場合、毎時間同時実行性はそれほど高くなりません。ピーク時間を調べ、100 万件の注文のうち 72 万件がピーク時間に生成されると仮定します。たとえば、1 時間あたり平均 36 万件の注文が生成されます。そのため、ピーク時間に応じてメモリサイズが選択されます。ほとんどの場合、ストレステストを実施することがあります。動作しない場合は、CPUとメモリを追加します。

ケース2

12306は春節期間中の大規模なチケットラッシュにどのように対応すべきでしょうか？注文情報は毎日固定され、キャッシュに投入できます。ビジネスロジックが異なれば、ビジネスデザインも異なります。 12306 は中国で最大の同時実行性を誇るフラッシュセール Web サイトのはずです。100 万の同時実行性を誇ると主張しており、これはビジネスロジックが 1 秒間に数百万回処理されることを意味します。 Taobao の最高同時アクセス数は年間 54 万件と推定されています。

この問題を解決すると、次のようになります。

CDN -> LVS -> NGINX -> ビジネスシステム -> マシンあたり 10,000 人の同時ユーザー

一般的な電子商取引の注文プロセスは、次のようになります。

注文 -> 注文する -> 注文システムが在庫を減らす -> ユーザーが支払うのを待つこのトランザクションが同期的に完了すると、TPS はそれを長期間サポートできなくなります。

ただし、12306 のモデルは、注文する -> 在庫を減らして非同期で注文する -> 支払いを待つというものです。非同期とは、注文後、1 つのスレッドが在庫を減らし、別のスレッドが注文情報を直接 kafka または redis にスローして OK を返すことを意味します。ご注文が正常に完了したら、お支払いをお待ちいただきます。お支払いが完了すると、後続の注文処理スレッドがデータを取得し、処理後に Hbase または MySQL に保存されます。一般的な大規模トラフィック処理方法の核となる考え方は、分割統治です。

JVMの最適化

たとえば、500,000 PV のデータ Web サイト (ディスクからメモリにドキュメントを抽出) があるとします。元のサーバーは 32 ビットで、ヒープサイズは 1.5G です。ユーザーからウェブサイトが遅いという報告があります。 16G ヒープメモリを搭載した 64 ビットサーバーにアップグレードしても、Web サイトが停止したままになっているという報告がユーザーからあり、状況は以前よりもさらに悪化しています。その理由は何でしょうか?一般的に、多くのユーザーがデータを閲覧すると、大量のデータがメモリにロードされ、メモリ不足、GC の頻繁化、STW 時間の長引くことになり、応答時間が遅くなります。それで私たちは何をすべきでしょうか? PS-> PN+CMS または G1 を使用します。

もう 1 つの問題は、システム CPU が 100% になることが多いことです。これを最適化するにはどうすればよいでしょうか?

まず、CPU が 100% の場合、システムリソースを占有しているスレッドが存在すると考えられます。

どのプロセスのCPU使用率が高いか調べる（topコマンド）

このプロセス内のどのスレッドの CPU が高いか (上位 -Hp)

スレッドのスタックをエクスポートする

どの方法（スタック稼ぎ）がより時間がかかるか調べる

ワーカースレッドの割合が高い |ガベージコレクションスレッドの割合が高い

要約する

今日は基本的な操作についてのみ説明しました。具体的にはどのように行うのでしょうか?この部分については次の部分で説明します。今日は主に、よく使用されるいくつかのパラメータを理解し、それらの使用方法といくつかの前提知識を説明します。以下ではこれらの問題について実践的な説明をします。興味のある友人は、3つのボタンを一度にクリックすることを忘れないでください。皆様ありがとうございました。

<<: JVM パフォーマンスの最適化は難しいと聞きました。今日試してみました！

>>: 面接官は私に尋ねました。「分散トランザクションとは何ですか?」