7

サーバーには 128 GB の RAM と 64 コアがあり、CentOS 6.3 で Tomcat 7.0.30 と Oracle jdk1.6.0_38 を実行しています。

60 分ごとに、45 ～ 60 秒かかっていたガベージ コレクションが表示されます。-XX:-UseConcMarkSweepGC を追加すると、ページの読み込み時間が約 10% 増加しましたが、許容できるトレードオフである約 3 秒に短縮されました。

私たちの設定:

-Xms30g
-Xmx30g
-XX:PermSize=8g
-XX:MaxPermSize=8g
-Xss256k
-XX:-UseConcMarkSweepGC

32 ビット アドレッシングを維持するために、ヒープを 30 GB に設定しました (32 GB を超えると、64 ビット アドレッシングはより多くのメモリを消費するため、改善を確認するには約 48 GB に移動する必要があると読みました)。

VisualGC を使用すると、Eden スペースが 30 ～ 60 分ごとに循環していることがわかりますが、Survivor 0、Survivor 1、Old Gen、および Perm Gen ではあまり変化がありません。

強力なサーバーがあります。3 秒の GC 時間をさらに短縮するために、他にどのような最適化を行うことができますか?

パフォーマンスやスケーリングを改善するための推奨事項はありますか?

役立つ他の出力または構成情報はありますか?

4

2 に答える 2

4

直感に反するように聞こえるかもしれませんが、メモリの割り当てを大幅に減らしてみましたか? たとえば、本当に 30G ヒープが必要ですか? 4G以下でうまくいく場合：ガベージコレクションはより頻繁になるかもしれませんが、それが起こるとずっと速くなります. 通常、クリーンアップに時間がかかるため、大量のメモリを割り当てるよりも、この方法の方が望ましいと思います。

本当に 30G のメモリが必要なためにこれが役に立たない場合でも、他の人が同様の問題を抱えている可能性があり、割り当てを減らすことでメリットが得られる可能性があります。

于 2013-01-06T09:52:37.630 に答える
2

一時停止を減らすためにインクリメンタル GC が必要なようです。

  • -XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode

そして、visualgc を使用しないトレースでは、これは常にうまくいきました (catalina.out の出力):

  • -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintGCTimeStamps

2013-01-05T22：52：13.954+0100：15918369.557：[GC 15918369.557：[defnew：65793K-> 227K（98304K）、0.0031220秒] 235615K-> 170050K（491520K）、0.003220K） =0.00、実数=0.00 秒]

これで遊ぶことができたら：

  • -XX:NewSize=ABC -XX:MaxNewSize=ABC
  • -XX:SurvivorRatio=ABC
  • -XX:NewRatio=ABC

参考：仮想マシンのガベージコレクションのチューニング

于 2013-01-05T21:58:55.820 に答える