このセクションでは、実際の戦闘部品のみを紹介します。特定の理論的パラメーターについては、Baiduをお願いします。
必要なツール：LinuxサーバーJMETERテストツールXSHELL Webアプリケーション
TomcatのJVMパラメーターはCatalina.shで構成できます。ウィンドウにある場合は、.batファイルを構成できます。
構成1：
ここでは、GCログパスを/home/log/gc.logとして構成してGCログを印刷し、初期ヒープと最大ヒープメモリを50mに設定し、出力ダンプファイルがオーバーフローされると、シリアルガベージコレクターを使用し、永続的な生成サイズは50mです。
Webアプリケーションを対応するディレクトリに配置し、server.xmlを構成し（構成はここに導入されていません）、tomcatを起動します。
スループットテストは、圧力テストツール（JMeter）を使用して実行されます。それを使用したことがない学生は、公式ウェブサイトhttp://jmeter.apache.org/でダウンロードして学ぶことができます
ユーザーグループ（10個のスレッド、各スレッドが1000回リクエスト）を作成し、HTTPリクエストの情報を設定し、集約レポートとGCログを生成します
最初にGCログを見てみましょう。
画面上の完全なGC、最後に集約レポートを確認してください。
スループットは1秒あたり122.7に維持されます。このケースから、古い世代は基本的にいっぱいであり、FullGCの後、新世代は少し残っていることがわかります。一般に、完全なGCの一時停止時間は最も長く、非常に頻繁に発生します。明らかに、そのような構成は不合理です。
構成2：
この構成により、主に最大ヒープメモリが増加します。仮想マシンを自動的に拡張し、安定したヒープメモリサイズを取得するため。
82924Kの最大ヒープメモリは約80mに注意してください。つまり、仮想マシンは自動的にヒープメモリを80mに拡張し、安定させることを意味します。この構成テストは、次のテストのために安定したヒープメモリを見つけるためだけです。
構成3：
ヒープの初期メモリを128mに設定します。
構成2の結果から、ヒープメモリは最終的に約80mで安定しているため、80m未満のヒープメモリが多数のGC反応を引き起こす可能性が高いため、HEAPメモリを128mに設定してGCSの数を減らすことができます。
スループットがわずかに増加し、GCの数が大幅に減少し、GCの時間間隔が長くなっていることがわかります。
構成4：
現在、マルチスレッドパラレルリサイクルであるParallalgc Recyclerを使用しています。
マルチスレッドパラレルを使用したGC Recyclerのスループットはわずかに改善されました。 （ParallalGCとSerialGCは、GC圧力なしでスループットにほとんど影響しません。）
構成5：
構成6：
構成3の結論によると、GCは80m未満のヒープメモリで頻繁に発生します。構成4で得られた結論と組み合わせて、特定のGC圧力がある場合、ParallelGCとSerialGCのスループットは特定の違いを示します。 5と6のヒープメモリが64m <80mで構成されている場合、頻繁なGCが発生します。異なるGCリサイクルターを使用する場合、理論的にはスループットに大きな違いがありますが、なぜ私の実験の違いがそれほど大きくないのですか？ねえ、私の家族は貧しいです。シングルコアCPUを使用しています。シングルコアの場合、ParallelGCのパフォーマンスの変更は明らかではありません。シングルコアまたは並列機能が弱い場合は、SerialGCをお勧めします。条件を持っている学生は、マルチコアサーバーで試してみることができます！
構成7：
Parnewgcを使用してみてください。新世代はParnewGCを使用してリサイクルしますが、古い世代は依然としてSerialGCを使用してリサイクルしています。パフォーマンスがどのようになっているか見てみましょう。
シリアルリサイクル業者をすべて使用するよりも優れたパフォーマンスを持っていますが、パラレルリサイクルラーをすべて使用するよりもパフォーマンスが低下します。
さらに、JDKバージョンのアップグレードもパフォーマンスを少し改善する可能性がありますが、JDKバージョンのアップグレードには特定のリスクが伴い、いくつかの未知のバグがJDKの新しいバージョンに導入される場合があります。
最後に、参照用に一般的に使用されるJVM構成パラメーターをリストしました。
1。シリアル回復期間に関連するパラメーター
•xx：+ueseSerialgc：新世代および古い世代のシリアルコレクターを使用する
•-XX：Survivorratio：エデンエリアのサイズと生存地域の比率を設定します
•-xx：getnuresizethershold：大きなオブジェクトのしきい値を設定して、老齢を直接入力します。オブジェクトのサイズがこの値を超えると、老年期に直接割り当てられます
•-xx：maxtenuringthreshold：老齢に入るオブジェクトの最大年齢値を設定します。各マイナーGCの後、被験者の年齢は1によって追加されます。この年齢よりも大きいオブジェクトは間違いなく老年に入ります。
2。並列GC関連パラメーター
•XX：+useParnewgc：新世代の並列コレクターを使用します。
•XX：+useparalleloldgc：老年期の並列コレクターを使用します
•XX：+parallelgcthreads：ガベージコレクションに使用されるスレッドの数を設定します。通常、CPUの数に等しく設定できます。多数のCPUがある場合、比較的小さな値を設定することも可能です。
•-xx：+maxgcpausemillis：最大ガベージコレクションの一時停止時間を設定します。その値は0より大きい整数です。コレクターが動作する場合、Javaヒープまたは他のパラメーターのサイズを調整し、可能な限りMaxgcpausemillisまでの一時停止時間を制御します。
•-xx： +useadaptiveSizepolicy：適応GC戦略をオンにします。このモードでは、新世代のサイズやサバイビオの比率、古い世代のオブジェクトの年齢などのパラメーターは、ヒープサイズ、スループット、一時停止のバランスポイントを実現するために自動的に調整されます。
•-xx：+gctimeratio：スループットサイズを設定します。その値は0〜100の証明書です。Gctimeratioの値がNであると仮定すると、システムはごみ収集に1/（1+n）時間を超えて時間を費やします。
3。CMSコレクターに関連するパラメーター
•xx：+useconcmarksweepgc：新世代は並列コレクターを使用し、古い世代はCMS+シリアルコレクターを使用します。
•-xx：parallelcmsthreads：CMSのスレッド数を設定します。
•XX：CMSITIANGITINGOCCUPANCYFRACTION：老年期のスペースを使用した後にトリガーされるCMSコレクターの量を設定し、デフォルト68％
•xx：usecmscompactatullcollection：Garbage Collectionを完了した後にCMSが1回デフラグする必要があるかどうかを設定します
•XX：CMSFULLGCBEFORECOPCACTION：CMS Garbage Collectionが実行される回数を設定し、メモリ圧縮が実行されます。
•-XX：+CMSCLASSUNLOADINGENABLED：クラスメタデータの回復を可能にします
•XX：CMSINITIATINGPERMOCCUPANCYFRACTION：永続的な占有率がこの割合に達すると、CMS回復を開始します（-XX：+CMSClassunLoadingEnabledがアクティブ化されています）
•XX：USECMSITINITINGOCCUPANCINGLY：CMSの回復は、しきい値に到達したときにのみ実行されることを意味します。
•XX：+CMSINCREMENTALMODE：単一のCPUにより適した増分モードを使用します。インクリメンタルモードは、中央で破棄されたものとしてマークされ、JDK9で完全に削除されます。
4。G1回復期間に関連するパラメーター
•-xx：+useg1gc：G1回復を使用します
•-xx：+maxgcpausemillis：最大ガベージコレクションの一時停止時間を設定します
•-xx：+gcpauseintervalmillis：一時停止時間間隔を設定します。
5。TLAB関連
•-xx：+usetlab：TLAB割り当てをオンにします。
•-xx：+printtlab：TLAB関連の割り当て情報を印刷します
•-xx：tlabsize：tlabサイズを設定します
•XX：+ResizetLab：TLABサイズを自動的に調整します
6.他のいくつかのパラメーター
•-xx：+disableexplicitgc：露示GCを無効にします
•-xx：+rebricitgcinvokesconcurrent：並行性を使用して、明示的なGCを処理します
上記のJVM Tomcat Performance Practical（推奨）は、私があなたと共有するすべてのコンテンツです。参照を提供できることを願っています。wulin.comをもっとサポートできることを願っています。