性能試験と廃棄物処理業者JVMのチューニングの人気

GCの基礎知識

1.何がゴミであります

C言語のアプリケーションメモリ：malloc関数無料

C ++：新しい削除

C / C ++、手動で再要求メモリ

Javaの：新しいですか？

自動メモリの再利用、メモリのシンプルなプログラミング、システムがエラーを起こしやすいではありません、手動解除、簡単な質問の二つのタイプ：

1. 回復を忘れ
2. リサイクル何回も

オブジェクトまたはオブジェクトの複数への参照なし（循環参照）

ゴミを見つける方法2

1. 参照カウント（ReferenceCount）
2. アルゴリズムアップルート（RootSearching）

3.一般的なガベージコレクションアルゴリズム

1. クリアマーク（マークスイープ） - 不連続位置フラグメンテーション効率が低い（2つのパス）であります
2. コピーアルゴリズム（コピー） - 残骸の自由、スペースの無駄
3. 圧縮マーク（マークコンパクト） - （ポインタを調整する必要が二回スキャン）ないフラグメンテーション、低効率

（世代別ガベージコレクションアルゴリズムのための）4.JVM世代メモリモデル

1. ガベージコレクタ使用のモデル部分

GCのほかイプシロンZGCシェナンドー論理モデルの世代です

G1は、物理的な置換に関係なく、論理世代であります

世代さらに唯一の論理的、および物理的な世代

1. 永久年の+ +新世代旧世代（1.7）パーマ世代/メタデータ領域（1.8）メタスペース

   1. メタデータ生成永久 - クラス
   2. 生成永久が制限なしに、設けられていなくてもよい、メタデータを提供することができる、サイズの制限を指定しなければならない（物理メモリによって制限されます）
   3. 文字列定数1.7 - 永久世代の1.8 - ヒープ
   4. MethodArea論理的な概念 - パーマネント、メタデータの生成

2. 新世代=エデン+ 2番目の領域suvivor

   1. YGC回復した後、オブジェクトのほとんどは、S0に生きて回収されます
   2. 再びYGC、生きているオブジェクトエデン+ S0 - > S1
   3. YGC再び、エデン+ S1 - > S0
   4. 旧十分 - >歳（15 CMS 6）
   5. >歳 - エリアフィットよ

3. 歳

   1. Diehards
   2. 歳とFGCフルGCのフル

4. GCチューニング（ジェネレーション）

   1. FGCを最小化
   2. MinorGC = CVL
   3. MajorGC = FGC

5. 図のオブジェクト割り当てプロセス。 

6. 年齢は重要なダイナミック:(）https://www.jianshu.com/p/989d3b06a49dではありません

7. :(割り当て保証はYGC時の生存空間領域は、古い年のリファレンスに十分なスペースを保証ダイレクトアクセスではありません）重要ではありませんします。https：//cloud.tencent.com/developer/article/1082730

5.一般的なガベージコレクタ

1. JDK、PN生まれ、会うCMSのために、効率を改善するためのシリアル・フォロー、PSの誕生生まれCMSバージョン1.4が後半に導入された、CMSは、GCのランドマークとなって、今どんな、それは同時回復プロセスを開きますが、問題はより多くのCMSですCMSは、彼らがSTWを立つことができないため、デフォルトのJDKのバージョン同時ガベージコレクションであります
2. シリアル若い世代シリアル・リカバリ
3. パラレル・リカバリのPS若い世代
4. ParNew CMSの同時回復を持つ若い世代
5. SerialOld
6. ParallelOld
7. CMS多くの問題（200ミリ秒）STW時間の短縮、同時、ガベージコレクションと同時に実行しているアプリケーション歳ConcurrentMarkSweepは、今、それはMarkSweepであるため、CMSは手動でしか指定することができ、CMSのデフォルトのバージョンではありません確かに断片化されています数時間（> PN + CMS + SerialOldを - ガベージコレクタを変更するためにメモリを追加> - PS + POを：問題は、破片はときに、古いCMSの割り当てオブジェクト割り当て古いSerialOld年使用してより少ないが想像回収し、一定のレベルに達します - STW日）メモリ、Gの回収数十スレッド - > G1 + FGC数十G - サーバZGCアルゴリズムで> Tメモリ：三色のマーカー+増分更新を
8. G1（10ms）のアルゴリズム：スリーカラーマーカー+ SATB
9. ZGC（1msの）PK C ++算法：ColoredPointers + LoadBarrier
10. シェナンドー算法：ColoredPointers + WriteBarrier
11. Eplison
12. PSとPNはまた、読書を区別：▪ https://docs.oracle.com/en/java/javase/13/gctuning/ergonomics.html#GUID-3D0BB91E-9BFF-4EBB-B523-14493A860E73
13. ガベージコレクタのメモリサイズとの関係
    1. シリアル数十メガバイトの
    2. メガバイトのPSの数百 - いくつかのG
    3. CMS - 20G
    4. G1 - Gの数百
    5. ZGC - 4T - 16T（JDK13）

1.8デフォルトのガベージコレクション：PS + ParallelOld

設定パラメータの一般的なガベージコレクタの組み合わせ：（1.8）

• -XX：+ UseSerialGC =シリアル新（DefNew）+シリアル旧
  • 小さなプログラム。デフォルトでは、このオプションは、ホットスポットが自動的に計算コレクター構成およびJDKのバージョンに応じて選択されていません
• -XX：+ UseParNewGC = ParNew + SerialOld
  • この組み合わせはほとんど使用されません（一部のバージョンでは廃止）
  • https://stackoverflow.com/questions/34962257/why-remove-support-for-parnewserialold-anddefnewcms-in-the-future
• -XX：+ UseConc （urrent） MarkSweepGC = ParNew + CMS +シリアル旧
• -XX：+ UseParallelGC =パラレル清掃を+パラレル旧（1.8默认）【PS + SerialOld】
• -XX：+ UseParallelOldGC =パラレル清掃を+パラレル古いです
• -XX：+ UseG1GC = G1

• LinuxはGCメソッドのデフォルトのビューでは見つかりませんでした、と窓がUseParallelGCを印刷します

  • Javaの+ XX：+ PrintCommandLineFlags -version
  • GCログで区別するために、

• 最終的にはどのようなLinuxのバージョン1.8のデフォルトのガベージコレクタのですか？

  • 1.8.0_181デフォルト（参照することはできません）コピーMarkCompact
  • 1.8.0_222デフォルトPS + PO

JVMは、共通のJVMコマンドラインパラメータを理解するための最初のステップをチューニング

• VMコマンドライン引数を参照します。https：//docs.oracle.com/javase/8/docs/technotes/tools/unix/java.html

• HotSpotの分類パラメータ

標準： - 初めに、すべてのHotSpotのサポート

非標準：-Xの始まりは、ホットスポットの特定のバージョンは、特定のコマンドをサポートしています

不安定：-XX、次のバージョンをキャンセルすることができる始まります

1. 概念を区別する：メモリのメモリリークメモリリーク、メモリオーバーフローアウト
2. Javaの-XX：+ PrintCommandLineFlags HelloGC
3. Javaの-Xmn10M -Xms40M -Xmx60M -XX：+ PrintCommandLineFlags -XX：+ PrintGC HelloGC PrintGCDetails PrintGCTimeStamps PrintGCCauses
4. Javaの-XX：+ UseConcMarkSweepGCを-XX：+ PrintCommandLineFlags HelloGC
5. Javaの-XX：+ PrintFlagsInitialデフォルトパラメータ値
6. Javaの-XX：+ PrintFlagsFinal最終パラメータ値
7. Javaの-XX：+ PrintFlagsFinal | grepをxxxに対応するパラメータを見つけます
8. Javaの-XX：+ PrintFlagsFinal -version | grepを 

基本的な概念をチューニングする前に：

1. スループット：時間ユーザーコード/（ユーザーコードの実行時間ガベージコレクションの時間+）
2. 応答時間：STW短く、より優れた応答時間

いわゆるチューニング、最初の何の追求を決定？優先順位のスループット、または応答時間優先？また、一定の応答時間を満たす場合には、多くの特定を達成するために必要な...

問題：

科学的なコンピューティング・スループット。データマイニング、thrput。一般的なスループットの優先順位：（PS + PO）

応答時間：ウェブGUI API（1.8 G1）

チューニングとは何ですか？

1. オンデマンドでJVM計画と行動事前チューニング
2. 最適な操作JVMランタイム環境（遅い、カトン）
3. 問題を解決するためのJVMプロセスが動作して発生した（OOM）

チューニング、計画から開始します

• チューニング、ビジネスシーンから始まる、チューニング、いじめの無いビジネスシーン

• いいえ監視ん（ストレステスト、結果を見ることができる）、ではないチューニング

• ステップ：

  1. ビジネスシーン（ない最高のガベージコレクタ、唯一の最適なガベージコレクタ）に泊まりました
     1. 応答時間、休止時間[CMS G1 ZGC]（ユーザに応答して必要に応じて）
     2. スループットは、ユーザの時間/（ユーザ時間時間+ GC）[PS]を=
  2. 組み合わせの回復を選択
  3. メモリ要件を計算する（経験1.5G 16G）
  4. 選択されたCPU（高い良いです）
  5. セットのサイズ、年齢、アップグレード
  6. ログのパラメータを設定します
     1. -Xloggc：/opt/xxx/logs/xxx-xxx-gc-%t.log -XX：+ UseGCLogFileRotation -XX：NumberOfGCLogFiles = 5 -XX：GCLogFileSize = 20M -XX：+ PrintGCDetails -XX：+ PrintGCDateStamps -XX： + PrintGCCause
     2. または毎日ログファイルを生成
  7. ログケースを守って

環境を改善

1. オリジンサーバ32、1.5Gのヒープ、ユーザーからのフィードバック（ディスクからメモリに抽出文書）50万PV情報のウェブサイトがあり、サイトでは、同社がアップグレードすることを決定しましたので、新しいサーバは、16Gヒープメモリ64で、比較的遅いですユーザーからのフィードバックのカトン結果は非常に深刻な、あまり効率的に以前よりあります
   1. なぜ元のサイトが遅い？多くのユーザーは、STW長く、メモリ不足、メモリに、遅い応答時間を頻繁にGCをデータロードの多くを、データを閲覧します
   2. なぜもっとカトン？より大きなメモリ、より長い時間FGC
   3. することになって？PS - > PN + CMS、またはG1
2. システムCPUのチューニング方法を常に100％？（インタビューHF）CPU100％は、システムリソースにスレッドが存在しなければなりません、
   1. 見つけるプロセスのCPU高（上）
   2. これは高CPUプロセススレッド（トップ-HP）
   3. スレッドのスタックの輸出（jstack）
   4. （jstack）時間を経過した方法（スタックフレーム）調べます
   5. ワーカースレッドの割合が高い|ガベージコレクションスレッドの割合が高いです
システムメモリは、どのように問題を見つけるために、舞い上がりますか？
1. 輸出ヒープメモリ（jmapの/ jvisualvmツール）
2. 私たちは、分析のためのファイルにJVM監視ツールについての記事を使用します
3. JVMを監視する方法
   1. 私たちは、モニターにJVM監視ツールについての記事を使用します

問題JVMの実行を解きます

1. 運用・保守チームは、通常、アラーム情報を受けた最初のものである（CPU、メモリ）

2. topコマンドの問題が認められます。メモリは、高いCPU使用率を成長します

3. 上部は、CPUとメモリの高い割合をスレッドれ、プロセス内のスレッドを観察-HP

4. JPSのjavaプロセスが:. WAITINGに焦点を当て、特定の位置決め用のスレッドの状態を見つける<上例えば待機をブロックjstack 0x0000000088ca3310>（java.lang.Object）メソッド100個のスレッドでの処理がある場合は、多くのスレッドが待機している ことを確認見つけることができます、どのスレッドが見つけるためにどのようにロックを保持していますか？情報検索のJstackダンプ、検索 スレッドがロックRUNNABLE参照を保持しています、

5. オービットGC状況jvisualvm、YGCとFGCスピードを参照してください

6. jmapの - ヒストポート|頭-20、見てどのように多くのオブジェクトが生成します

7. オンラインシステム、メモリもカトン（電気プロバイダは適していません）1、実行jmapは中のプロセスに重大な影響を及ぼし、特に大きい：パラメータHeapDump、OOM時間を設定するには、自動的にヒープダンプファイル2が生成されます多くのサーバをバックアップ（高可用性）、このサーバーの電源をオフにすると、他のサーバには影響しません オンラインポジショニング（未満で、通常は何か小さな会社）：3

8. Jvisualvmは、ダンプ・ファイルを用いて分析しました 

9. 問題のあるコードを探します

の概念に基づいたGCアルゴリズム

• カード表YGC、領域全体をスキャンするOLD必要を行い、効率が非常に低いとき以来、JVMはOLDエリアCardTable目標点Y領域が存在する場合、それだけでスキャン、汚れた、次のスキャンを設定され、CardTableを設計したので、構造体の汚れたカードは、カードの表は、ビットマップによって達成しました

CMS

CMSに関する質問

1. メモリの断片化

-XX：+ UseCMSCompactAtFullCollection -XX：0 CMSFullGCsBeforeCompactionデフォルトは圧縮前FGC介し回数を指し

1. フローティングガベージ

並行モード・失敗产生：同時コレクターは古い世代がいっぱいになる前に、到達不能オブジェクトの再利用を終了することができない、または割り当ては古い世代で利用可能な空き領域のブロックsatisfiedwithできない場合は、theapplicationが一時停止され、収集が完了した場合すべてapplicationthreadsが停止して

解決策：CMSをトリガーするしきい値を下げます

PromotionFailed

古い十分なスペースを維持するための同様のソリューション

-XX：CMSInitiatingOccupancyFraction 92％がそうCMSの古い十分なスペースという、この値を減らすことができます

G1

1. ▪https：//www.oracle.com/technical-resources/articles/java/g1gc.html

ケースの概要

OOMは、さまざまな理由を生産し、一部のプログラムがOOMを生成しないことがあり、絶えずFGC（CPUが高急騰が、メモリの回復は非常にまれ）（トップケース）

1. ハードウェアは、システムが、問題カトンをアップグレード

2. プール生成OOMの問題はリガオブジェクトのList（低すぎる）に進み、スレッドの不適切な使用

3. 笑顔JIRAの問題は、問題を解決するために、実際のシステムの再起動は本当にどこに問題ガベージコレクタ+ G1を置き換えるためにメモリを追加し続けて？知りません

4. TomcatのHTTPヘッダサイズが大きすぎる問題（ヘクター）

5. オーバーフローの問題でラムダ式方法の結果

1. ファイナライズ原因と頻繁にGCのキビ雲、HBaseの同期システム、nginxのアクセスタイムアウト警報システム、最後の調査を書き直し、ファイナライズを書き換えるC ++プログラマはGC C ++プログラマはファイナライズを書き換えますなぜ頻繁に質問を引き起こしましたか？（新削除）ファイナライズが長い（200msの）を取り

2. システムがある場合は、メモリの消費量が10％未満であったが、GCログを観察している、FGCは常に頻繁に農産物を見つけ、何が原因でしょうか？System.gc（）（この比較低）

3. Distuptor鎖の長さを設定することができます持って、大きすぎる場合は、ラージオブジェクトは、消費者が解除を完了するためのイニシアチブを取ることはありません、（死者スタイルから）オーバーフローします

4. JVM意志オーバーフロー、前の崩壊とmycat、一時的なバージョン1.6.5構文解析SQLサブクエリアルゴリズムでは、米国のSQL 9 Geが（死んスタイルから）数百万のオブジェクトの生成につながる存在します

5. スレッドの新しい番号、スレッドプールのソリューションを使用する必要がありますネイティブスレッドOOM、（低）を生成します：（あまりにTMlow）50％の物理メモリの割合を占め、ネイティブスレッドJVMのメモリを生産するために脇に、より多くのメモリを設定し、ヒープスペースを削減 - 80％

GCの共通パラメータ

• -Xmn -Xms -Xmx -Xss若い世代の最小ヒープ最大スタック空間
• -XX：+ UseTLAB使用TLAB、デフォルトで
• -XX：+ PrintTLABはTLABの使用を印刷
• -XX：TLABSizeはサイズTLABを設定しました
• -XX：+ DisableExplictGCにSystem.gc（）がない仕事、FGCを行います
• -XX：+ PrintGC
• -XX：+ PrintGCDetails
• -XX：+ PrintHeapAtGC
• -XX：+ PrintGCTimeStamps
• -XX：+ PrintGCApplicationConcurrentTime（低い）印刷アプリケーション時間
• -XX：+ PrintGCApplicationStoppedTime（低い）長い休止を印刷
• -XX：+ PrintReferenceGC（重要度が低い）に引用された参考文献のどのように多くの異なる種類の回復を記録
• -verbose：詳細クラスクラスローディングプロセス
• -XX：+ PrintVMOptions
• -XX：+ PrintFlagsFinal -XX：+ PrintFlagsInitial使用する必要があります
• -Xloggc：OPT /ログ/ gc.log
• -XX：年齢に代わってMaxTenuringThresholdリットル、最大15
• スピンロック時間-XX：PreBlockSpinホットコード検出パラメータ-XXは：CompileThresholdエスケープ解析スカラー置換は、これらの設定をお勧めしません...

パラレル共通パラメータ

• -XX：SurvivorRatio
• -XX：どのくらいの最後にラージオブジェクトをPreTenureSizeThreshold
• -XX：MaxTenuringThreshold
• -XX：+スレッドParallelGCThreadsの数パラレルコレクタは、同じことがCMS、同じ一般的なセットとCPUコアの数に適用されます
• -XX：+ UseAdaptiveSizePolicyゾーン自動的にサイズ比が選択されます

CMSの共通パラメータ

• -XX：+ UseConcMarkSweepGCを
• -XX：スレッドのParallelCMSThreads番号CMS
• -XX：CMSInitiatingOccupancyFractionは、CMSの何パーセント、デフォルトは68％（概算値）である古いのは、使用集め始めた後、SerialOldカトンが頻繁場合は、調整する必要があり、小さな（頻繁にCMSを回復）
• -XX：+ UseCMSCompactAtFullCollection圧縮するとFGC
• 何回圧縮FGC CMSFullGCsBeforeCompaction後：-XX
• -XX：+ CMSClassUnloadingEnabled
• パーマCMSInitiatingPermOccupancyFractionは、時間のどのような割合に回復することが-XX：
• GCTimeRatioは、GC実行時のプログラムや時間の割合を設定しました
• -XX：MaxGCPauseMillis休止時間は、GCは、この時間を達成するためのすべての手段を使用しようとする若い世代を削減するよう提案した時間であります

G1の共通パラメータ

• -XX：+ UseG1GC
• -XX：MaxGCPauseMillis推奨値、G1は、この値を達成するために、ブロック・ヤング地区の数を調整しようとします
• -XX：GCPauseIntervalMillis？GCインターバル
• -XX：+ G1HeapRegionSizeパーティションのサイズは、推奨値は次第に、12481632が増加しています。サイズ、ごみより長い生存期間の増加に伴って、より長い間隔GC、GCが、各時間ZGCが（ダイナミック・ブロック・サイズ）改善された長くなります
• G1NewSizePercentの最小スケールの新しい世代は、デフォルトでは5％
• G1MaxNewSizePercent新世代の最大の割合は、デフォルト値は60％であり、
• GCTimeRatio GC時間比率を推奨し、G1は、ヒープ領域の値に基づいて調整されます
• スレッドのConcGCThreads数
• G1ヒープ領域の占有率を開始InitiatingHeapOccupancyPercent

参考資料

1. https://blogs.oracle.com/ jonthecollector /私たちの-のコレクター
2. https://docs.oracle.com/javase/8/docs/technotes/tools/unix/java.html
3. http://java.sun.com/javase/technologies/hotspot/vmoptions.jsp
4. JVMのチューニングの参考資料ます。https：//docs.oracle.com/en/java/javase/13/gctuning/introduction-garbage-collection-tuning.html#GUID-8A443184-7E07-4B71-9777-4F12947C8184
5. jmapのコマンドリファレンス：https://www.jianshu.com/p/507f7e0cc3a3
   1. jmapの-heap PID
   2. jmapの-histo PID
   3. jmapの-clstats PID