2016-10-18 13 views
0

待ち時間を最適化するアプリケーションがありますので、フルGCでの平均時間を短縮したいと考えています。 "XX:+ UseParallelGC" とこれは私たちが見たものである。"-XX:+ UseParNewGC -XX:+ UseConcMarkSweepGC"に切り替わり、フルGCが発生する

[myhost ~]$ /usr/local/jdk7/bin/jstat -gcutil 9793 1000 
    S0  S1  E  O  P  YGC  YGCT FGC FGCT  GCT 
    0.00 49.57 95.93 93.32 99.48 10086 390.628 387 1005.334 1395.962 
56.99 0.00 7.42 93.32 99.48 10087 390.691 387 1005.334 1396.025 
56.99 0.00 22.19 93.32 99.49 10087 390.691 387 1005.334 1396.025 
56.99 0.00 36.28 93.32 99.49 10087 390.691 387 1005.334 1396.025 
[myhost ~]$ ps -p 9793 -o etime= 
4-12:40:52 

我々が使用に切り替えると、 "-XX:+ UseParNewGC -XXを:+ UseConcMarkSweepGCを" 私たちは多くのフルGCを参照してください。

[myhost]$ /usr/local/jdk7/bin/jstat -gcutil 2514 1000 
    S0  S1  E  O  P  YGC  YGCT FGC FGCT  GCT 
    0.00 100.00 100.00 99.62 24.20 716 28.151 24 44.250 72.401 
    0.00 100.00 100.00 99.62 24.20 716 28.151 24 44.250 72.401 
    0.00 100.00 100.00 99.62 24.20 716 28.151 24 44.250 72.401 
    0.00 100.00 100.00 99.62 24.20 716 28.151 24 44.250 72.401 
    0.00 100.00 100.00 99.62 24.20 716 28.151 24 44.250 72.401 
    0.00 100.00 100.00 99.62 24.20 716 28.151 24 44.250 72.401 
    0.00 100.00 100.00 99.62 24.20 716 28.151 24 44.250 72.401 
    0.00 100.00 100.00 99.62 24.20 716 28.151 24 44.250 72.401 
    0.00 100.00 100.00 99.62 24.20 716 28.151 24 44.250 72.401 
    0.00 100.00 100.00 99.62 24.19 716 28.151 24 44.250 72.401 
    0.00 100.00 100.00 99.62 24.19 716 28.151 24 44.250 72.401 
    0.00 0.00 5.92 99.44 24.19 716 28.151 24 56.361 84.512 
100.00 0.00 100.00 99.66 24.19 718 28.221 26 56.417 84.638 
100.00 0.00 100.00 99.66 24.19 718 28.221 26 56.417 84.638 
100.00 0.00 100.00 99.66 24.19 718 28.221 26 56.417 84.638 
100.00 0.00 100.00 99.66 24.19 718 28.221 26 56.417 84.638 
100.00 0.00 100.00 99.66 24.19 718 28.221 26 56.417 84.638 
100.00 0.00 100.00 99.66 24.19 718 28.221 26 56.417 84.638 
100.00 0.00 100.00 99.66 24.19 718 28.221 26 56.417 84.638 
100.00 0.00 100.00 99.66 24.19 718 28.221 26 56.417 84.638 
100.00 0.00 100.00 99.66 24.19 718 28.221 26 56.417 84.638 
100.00 0.00 100.00 99.66 24.19 718 28.221 26 56.417 84.638 
100.00 0.00 100.00 99.66 24.19 718 28.221 26 56.417 84.638 
100.00 0.00 100.00 99.66 24.19 718 28.221 26 56.417 84.638 
100.00 0.00 100.00 99.66 24.19 718 28.221 26 56.417 84.638 
100.00 0.00 34.98 99.87 24.20 720 28.319 27 68.708 97.026 
100.00 0.00 100.00 99.87 24.20 721 28.319 28 68.708 97.026 
100.00 0.00 100.00 99.87 24.20 721 28.319 28 68.708 97.026 
100.00 0.00 100.00 99.87 24.20 721 28.319 28 68.708 97.026 
100.00 0.00 100.00 99.87 24.20 721 28.319 28 68.708 97.026 
私たちは、JDKを使用している

-Xms256m -Xmx8192m -XX:PermSize=128m -XX:MaxPermSize=1024m 

[myhost ~]$ /usr/local/jdk7/bin/java -XX:+PrintCommandLineFlags -version 
-XX:InitialHeapSize=261346688 -XX:MaxHeapSize=4181547008 -XX:+PrintCommandLineFlags -XX:+UseCompressedOops -XX:+UseParallelGC 
java version "1.7.0_80" 
Java(TM) SE Runtime Environment (build 1.7.0_80-b15) 
Java HotSpot(TM) 64-Bit Server VM (build 24.80-b11, mixed mode) 

は、これが私たちのヒープの設定です

最初のインスタンスの稼働時間は4日以上です。 2番目のインスタンスはほんの数分しかなかった。巨大な一時停止を伴う完全なGCを頻繁に行っていることに気がついたので、設定を元に戻しました。

GCの統計情報が壁から外れないように、ここで調整する必要があるのは何ですか?

+0

あなたは、Java 7にバインドされていますか? gcを一時停止しようとしている場合は、G1GCが良い賭けになるかもしれません – Rogue

+0

ええ、今のところJava 7にかなり縛られています。 – fruitJuice

答えて

0

以前のキャプチャでは、レコードのみが存在しますが、各イベントには10​​05フルGC時間があります。 2回目のキャプチャでは、より多くのレコードが表示されますが、各イベントは44〜68フルGC時間しかありません。したがって、1回目と2回目のキャプチャのGC時間の合計を要約すると、設定を変更した後の2回目のGC時間は実際にFull GC時間が短くなります。

+0

最初のインスタンスの稼働時間は4日以上です。 2番目のインスタンスはほんの数分しかなかった。巨大な一時停止を伴う完全なGCを実行していることに気がついたので、設定を元に戻しました。 – fruitJuice

+0

あなたのjstatは4日以上のGC結果ではないと思います。間隔を1000に指定したので、jstatコマンドを停止するか、JVMプロセスが終了するまで、jstatは1秒ごとにgc statsを収集します。 – wonhee

+0

本当ですか?プロセスの開始以来、FGCおよびFGCTは収集されていませんか? – fruitJuice

0

人間工学によって、デフォルトのプラットフォーム依存選択とともにアプリケーション属性に関連するGCの動作を調整できる引数を指定できます。コレクタを変更しても、チューニングが実行されたGCのカウントにどのように影響するかは指定されていないため、コレクタ選択が間違っているとは言えません。

動作に関して言えば、ConcMarkSweepGCは、アプリケーションの中断時間が短いことを保証しますが、GCイベントの何かが生成されます。 Full GCの平均時間が改善されたことを示す2回目のテストでも、コレクタがどのようにメトリクスに適合するかを確認するためには、さらに長い時間テストする必要があります。

同時コレクタは、最近の履歴に基づいて、テナント生成がなくなるまでの残り時間と同時収集サイクルに必要な時間の推定値を保持します。これらの動的推定値に基づいて、並行回収サイクルが開始され、期限切れ世代が尽きる前に回収サイクルを完了することが目的です。その横に

、あなたはあなたができる、GC(コレクタの約束)と行っGCイベントで撮影した時の適切なバランスを得るために(他のコレクターのテストを含む)いくつかの例を実行する必要が同様に、コレクタの実行を取得する前に(世代仮説に基づいて)オブジェクトが促進される方法を制御することができますのparamsのためにテストする、または許容可能なヒープ使用状況が取得:

-XX:NewRatio=<N> 
-XX:CMSInitiatingOccupancyFraction=<N> 
関連する問題