Javaゴミ回収メカニズムの監視方法6
6507 ワード
GC最適化結果の分析
GCパラメータおよび-verbosegcパラメータを設定した後、tailコマンドでログが正しく生成されることを確認します.パラメータ設定が正しくない場合やログが生成されていない場合は、時間を無駄にします.ログが正しければ、1～2日間収集を続けます.その後、ログをローカルPCにダウンロードし、HPJMeterで分析したほうがいいです.
Full GC実行時間Minor GC実行時間Full GC実行間隔Minor GC実行間隔Entire Full GC実行時間Entire Minor GC実行時間Entire GC実行時間Full GC実行時間Minor GC実行時間最良のGCパラメータを見つけることは非常に幸運なことですが、多くの場合、私たちは幸運の神の配慮を得ることはできません.GCの最適化を行う際には、できるだけ慎重にしなければなりません.一歩最適化を完了するには、OutOfMemoryErrorを招くことが多いと思います.
最適化の例
では、私たちはずっと紙の上で兵を話しています.今、実際のGC最適化の例を見てみましょう.
例1
次の例では、サービスSの最適化について、最近導入されたサービスSについて、Full GCに時間がかかりすぎます.
jstat–gcutilの実行結果を参照してください.
1
2
一番左のPerm空間は最初のGC最適化には重要ではなく,今回のYGCパラメータの値がより有用である.
Minor GCとFull GCの平均値を下表に示す
表3:Service SのMinor GCとFull GCの平均実行時間
GCタイプ
GC実行回数
GC実行時間
へいきん
Minor GC
54
2.047
37 ms
Full GC
5
6.946
1,389 s
最も重要なのは次の2つのデータです
新生代実際使用空間:212992 KB 古い年代の実際の使用空間:1884160 KB したがって,総メモリ空間は2 GBであり,Perm空間ではない場合,新生代と旧世代の比は1:9である.jstatと-verbosegcログでデータ収集を行い、3台のサーバを以下のように設定します.
NewRatio=2
NewRatio=3
NewRatio=4
一日後、システムのGCログをチェックしたところ、NewRatioパラメータが設定されていて幸いにもFull GCは発生せず、
どうして?
NewRatio=2: 45 ms
NewRatio=3: 34 ms
NewRatio=4: 30 ms
NewRatio=4が最適パラメータであることを示したが,その新生代空間は最小であったが,GC時間は確かに最短であった.このパラメータを設定した後、システムはFull GCを実行していません.
この問題を説明するために、サービスの星がしばらくしてjstat-gcutilを実行した結果を示します.
1
2
サーバからのリクエストが少ないためにGCの実行頻度が低下していると思われるかもしれません.実際,Full GCは実行されなかったが,Minor GCは2424回実行された.
例2
これはServiceAの例であり、JVMが8秒以上停止していることを社内のアプリケーションパフォーマンス管理システム(APM)で発見したため、GC最適化を行った.フルGCの実行時間が長すぎる理由を見つけ,解決に着手した.
GC最適化の第一歩は,−verbosegcパラメータを追加し,以下の結果を得ることである.
図1:GC最適化前のSTW時間
上図に示すように、HPJMeterによって自動的に生成されるピクチャの1つです.X座標は、JVMの実行時間を表します.Y座標はGC毎の時間を表す.CMS緑点、Full GC結果を表します.Parallel Scavengeブルーポイント、Minor GC結果を表します.
前にCMS GCが一番速いと言ったことがありますが、上記の結果は何らかの理由で最大15秒かかりました.何がこの結果を招いたのですか.私の前提を思い出したかどうか、CMSはメモリのクリーンアップを行う時、遅くなります.同時に、サービスのメモリは–Xms 1 gと–Xmx 4 gに設定され、実際には4 GBのメモリが割り当てられている.
そこで、GCタイプをCMSからParallel GCに変更しました.さらにメモリを2 GBに変更し、NewRatioを3に設定します.数時間後にjstat-gcutilを使用して次の結果を得ました.
1
2
4 GB時の15秒に対し、フルGCは平均3秒となった.しかし、3秒と同じくらい遅いので、以下の6つのシーンを設計しました.
Case 1: -XX:+UseParallelGC -Xms1536m -Xmx1536m -XX:NewRatio=2
Case 2: -XX:+UseParallelGC -Xms1536m -Xmx1536m -XX:NewRatio=3
Case 3: -XX:+UseParallelGC -Xms1g -Xmx1g -XX:NewRatio=3
Case 4: -XX:+UseParallelOldGC -Xms1536m -Xmx1536m -XX:NewRatio=2
Case 5: -XX:+UseParallelOldGC -Xms1536m -Xmx1536m -XX:NewRatio=3
Case 6: -XX:+UseParallelOldGC -Xms1g -Xmx1g -XX:NewRatio=3
どれが一番速いですか.その結果、メモリが小さいほど結果がよくなります.次の図はCase 6の結果を示しています.これはGCの性能が一番いいです.最も長い応答時間は1.7秒しかありません.平均時間は1秒以内です.
図2:Case 6のタイムチャート
以上の結果に基づく.Case 6に従ってGCパラメータを調整しました.しかし、これにより毎晩OutOfMemoryErrorが発生する.ここでは具体的な原因を説明するのは難しい.簡単に言えば、バッチによってメモリが漏洩しました.関連する問題はすでに解決された.
GCログを短時間で分析するだけですべてのサーバを簡単に最適化することは危険です.GCログとアプリケーションを同時に分析する必要があることを常に覚えておいてください.
私が前に述べたように、例で述べたGCパラメータは、同じサーバ上に設定できるが、同じCPU、オペレーティングシステム、JDKバージョン、および同じサービスを実行していることを前提として、GC最適化に関する2つの例をレビューした.しかし、私が使ったパラメータを直接あなたのサービスに使わないでください.それらは必ずしも良い仕事ができるとは限りません.
結論
私は経験によってGCの最適化を行い、スタックダンプを実行してメモリの詳細を分析しませんでした.メモリを正確に分析すると、より良い最適化効果が得られます.しかし,この解析はメモリ使用量が相対的に固定されている場合に一般的に適用される.ただし、サービスが大幅にオーバーロードされ、大量のメモリが消費されている場合は、これまでの経験に基づいてGCの最適化を強くお勧めします.
いくつかのサービスでG 1 GCパラメータを設定し、パフォーマンステストを行いました.しかし、正式な環境では適用されておらず、G 1 GCパラメータの速度は他のGCタイプよりも速い.しかし、JDK 7にアップグレードしなければなりません.また、彼の安定性もしばらく保障されておらず、致命的な間違いが発生するかどうかは誰も知らない.だからまだ正式に応用されていない時
将来のある日、JDK 7が本当に安定している(これは彼が今不安定だというわけではない)、WASがJDK 7に対して最適化を行った後、G 1 GCは最終的に予想通りに動作することができ、GC最適化を行う必要はないかもしれません.
GC最適化の詳細については、Slideshare.comにログインして関連リソースを参照してください.Everything I Ever Learned About JVM Performance Tuning @Twitterを強くお勧めします.著者Attila Szegedi、Twitterエンジニア.時間をかけて読んでください.
By Sangmin Lee, NHN Performance Engineering Lab.
著者のSangmin LeeはNHN性能工学研究院に就職した
原文:cubrid、コンパイル:ImportNew-王暁傑
訳文アドレス:http://www.importnew.com/3146.html
【転載が必要な場合は、本文に原文リンク、訳文リンク、翻訳者などの情報を表示して保持してください.ご協力ありがとうございます.】
GCパラメータおよび-verbosegcパラメータを設定した後、tailコマンドでログが正しく生成されることを確認します.パラメータ設定が正しくない場合やログが生成されていない場合は、時間を無駄にします.ログが正しければ、1～2日間収集を続けます.その後、ログをローカルPCにダウンロードし、HPJMeterで分析したほうがいいです.
Full GC実行時間Minor GC実行時間Full GC実行間隔Minor GC実行間隔Entire Full GC実行時間Entire Minor GC実行時間Entire GC実行時間Full GC実行時間Minor GC実行時間最良のGCパラメータを見つけることは非常に幸運なことですが、多くの場合、私たちは幸運の神の配慮を得ることはできません.GCの最適化を行う際には、できるだけ慎重にしなければなりません.一歩最適化を完了するには、OutOfMemoryErrorを招くことが多いと思います.
最適化の例
では、私たちはずっと紙の上で兵を話しています.今、実際のGC最適化の例を見てみましょう.
例1
次の例では、サービスSの最適化について、最近導入されたサービスSについて、Full GCに時間がかかりすぎます.
jstat–gcutilの実行結果を参照してください.
1
2
S0 S1 E O P YGC YGCT FGC FGCT GCT 12.16 0.00 5.18 63.78 20.32 54 2.047 5 6.946 8.993 一番左のPerm空間は最初のGC最適化には重要ではなく,今回のYGCパラメータの値がより有用である.
Minor GCとFull GCの平均値を下表に示す
表3:Service SのMinor GCとFull GCの平均実行時間
GCタイプ
GC実行回数
GC実行時間
へいきん
Minor GC
54
2.047
37 ms
Full GC
5
6.946
1,389 s
最も重要なのは次の2つのデータです
新生代実際使用空間:212992 KB 古い年代の実際の使用空間:1884160 KB したがって,総メモリ空間は2 GBであり,Perm空間ではない場合,新生代と旧世代の比は1:9である.jstatと-verbosegcログでデータ収集を行い、3台のサーバを以下のように設定します.
NewRatio=2
NewRatio=3
NewRatio=4
一日後、システムのGCログをチェックしたところ、NewRatioパラメータが設定されていて幸いにもFull GCは発生せず、
どうして?
NewRatio=2: 45 ms
NewRatio=3: 34 ms
NewRatio=4: 30 ms
NewRatio=4が最適パラメータであることを示したが,その新生代空間は最小であったが,GC時間は確かに最短であった.このパラメータを設定した後、システムはFull GCを実行していません.
この問題を説明するために、サービスの星がしばらくしてjstat-gcutilを実行した結果を示します.
1
2
S0 S1 E O P YGC YGCT FGC FGCT GCT 8.61 0.00 30.67 24.62 22.38 2424 30.219 0 0.000 30.219 サーバからのリクエストが少ないためにGCの実行頻度が低下していると思われるかもしれません.実際,Full GCは実行されなかったが,Minor GCは2424回実行された.
例2
これはServiceAの例であり、JVMが8秒以上停止していることを社内のアプリケーションパフォーマンス管理システム(APM)で発見したため、GC最適化を行った.フルGCの実行時間が長すぎる理由を見つけ,解決に着手した.
GC最適化の第一歩は,−verbosegcパラメータを追加し,以下の結果を得ることである.
図1:GC最適化前のSTW時間
上図に示すように、HPJMeterによって自動的に生成されるピクチャの1つです.X座標は、JVMの実行時間を表します.Y座標はGC毎の時間を表す.CMS緑点、Full GC結果を表します.Parallel Scavengeブルーポイント、Minor GC結果を表します.
前にCMS GCが一番速いと言ったことがありますが、上記の結果は何らかの理由で最大15秒かかりました.何がこの結果を招いたのですか.私の前提を思い出したかどうか、CMSはメモリのクリーンアップを行う時、遅くなります.同時に、サービスのメモリは–Xms 1 gと–Xmx 4 gに設定され、実際には4 GBのメモリが割り当てられている.
そこで、GCタイプをCMSからParallel GCに変更しました.さらにメモリを2 GBに変更し、NewRatioを3に設定します.数時間後にjstat-gcutilを使用して次の結果を得ました.
1
2
S0 S1 E O P YGC YGCT FGC FGCT GCT 0.00 30.48 3.31 26.54 37.01 226 11.131 4 11.758 22.890 4 GB時の15秒に対し、フルGCは平均3秒となった.しかし、3秒と同じくらい遅いので、以下の6つのシーンを設計しました.
Case 1: -XX:+UseParallelGC -Xms1536m -Xmx1536m -XX:NewRatio=2
Case 2: -XX:+UseParallelGC -Xms1536m -Xmx1536m -XX:NewRatio=3
Case 3: -XX:+UseParallelGC -Xms1g -Xmx1g -XX:NewRatio=3
Case 4: -XX:+UseParallelOldGC -Xms1536m -Xmx1536m -XX:NewRatio=2
Case 5: -XX:+UseParallelOldGC -Xms1536m -Xmx1536m -XX:NewRatio=3
Case 6: -XX:+UseParallelOldGC -Xms1g -Xmx1g -XX:NewRatio=3
どれが一番速いですか.その結果、メモリが小さいほど結果がよくなります.次の図はCase 6の結果を示しています.これはGCの性能が一番いいです.最も長い応答時間は1.7秒しかありません.平均時間は1秒以内です.
図2:Case 6のタイムチャート
以上の結果に基づく.Case 6に従ってGCパラメータを調整しました.しかし、これにより毎晩OutOfMemoryErrorが発生する.ここでは具体的な原因を説明するのは難しい.簡単に言えば、バッチによってメモリが漏洩しました.関連する問題はすでに解決された.
GCログを短時間で分析するだけですべてのサーバを簡単に最適化することは危険です.GCログとアプリケーションを同時に分析する必要があることを常に覚えておいてください.
私が前に述べたように、例で述べたGCパラメータは、同じサーバ上に設定できるが、同じCPU、オペレーティングシステム、JDKバージョン、および同じサービスを実行していることを前提として、GC最適化に関する2つの例をレビューした.しかし、私が使ったパラメータを直接あなたのサービスに使わないでください.それらは必ずしも良い仕事ができるとは限りません.
結論
私は経験によってGCの最適化を行い、スタックダンプを実行してメモリの詳細を分析しませんでした.メモリを正確に分析すると、より良い最適化効果が得られます.しかし,この解析はメモリ使用量が相対的に固定されている場合に一般的に適用される.ただし、サービスが大幅にオーバーロードされ、大量のメモリが消費されている場合は、これまでの経験に基づいてGCの最適化を強くお勧めします.
いくつかのサービスでG 1 GCパラメータを設定し、パフォーマンステストを行いました.しかし、正式な環境では適用されておらず、G 1 GCパラメータの速度は他のGCタイプよりも速い.しかし、JDK 7にアップグレードしなければなりません.また、彼の安定性もしばらく保障されておらず、致命的な間違いが発生するかどうかは誰も知らない.だからまだ正式に応用されていない時
将来のある日、JDK 7が本当に安定している(これは彼が今不安定だというわけではない)、WASがJDK 7に対して最適化を行った後、G 1 GCは最終的に予想通りに動作することができ、GC最適化を行う必要はないかもしれません.
GC最適化の詳細については、Slideshare.comにログインして関連リソースを参照してください.Everything I Ever Learned About JVM Performance Tuning @Twitterを強くお勧めします.著者Attila Szegedi、Twitterエンジニア.時間をかけて読んでください.
By Sangmin Lee, NHN Performance Engineering Lab.
著者のSangmin LeeはNHN性能工学研究院に就職した
原文:cubrid、コンパイル:ImportNew-王暁傑
訳文アドレス:http://www.importnew.com/3146.html
【転載が必要な場合は、本文に原文リンク、訳文リンク、翻訳者などの情報を表示して保持してください.ご協力ありがとうございます.】