4

VisualVM を使用して、JBoss サーバーで次のヒープ使用量を観察しています。

ヒープ使用量の VisualVm スクリーンショット

サーバーは、次の (関連する) JVM オプションで開始されます。

-Xrs -Xms3072m -Xmx3072m -XX:MaxPermSize=512m -XX:+UseParallelOldGC -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000

また、現在、GC ロギングも有効にしています。

-XX:+PrintGC -XX:+PrintGCTimeStamps -XX:+PrintGCDetails -Xloggc:log\gc.log

基本的に、観察されたパターンに満足しています。メモリ リークがないように見えるからです (パターンは何日にもわたって繰り返されます)。

しかし、最適化の余地があるかどうか疑問に思っていますか?

まず、ヒープ使用量が約 2GB に達したときにガベージ コレクションが開始される理由がわかりません。ヒープが 3GB 利用可能になるので、後で開始できるように見えますか?

さらに、観察されたヒープ使用パターンと使用された JVM オプションに関するヒントに興味があります。

  • 観測されたパターンから、使用されている GC 戦略 (UseParallelOldGC) について結論を引き出すことができますか? この戦略は正しいものですか、それとも観測されたヒープ使用量を考慮して別の戦略を使用する必要がありますか?

  • GC プロセスを最適化して、ヒープ サイズ全体 (3GB) が使用されるようにすることはできますか?

  • 現在、3GB が完全に使用されていないようですが、Xms/Xmx を 2.5GB に減らす必要がありますか?

  • 私が見逃している明らかな GC 最適化はありますか? -XX:NewSize や -XX:NewRatio の調整はお好きですか?

  • 頭に浮かぶ他のヒントはありますか？

ありがとう！

4

1 に答える 1

7

スクリーンショットの GC の動作は「正常」に見えると思います。

通常、ヒープ領域がいっぱいになる前に主要なコレクションをトリガーする必要があります。または、いくつかのシナリオに基づいて、OutOfMemoryError が非常に簡単に発生する可能性があります。

また、Java のヒープ スペースが、新しい (eden)、現在の (サバイバー)、および古い (tenured) オブジェクトの個別の領域に分割されていることをご存知ですか?

この回答は、この件に関する優れた情報を提供するため、ここでは繰り返しません。

Javaメモリプールはどのように分割されていますか?

基本的に、ヒープの各領域は独自のコレクションをトリガーします。通常、eden スペースは頻繁に収集され、「迅速に」survivor および tenured スペースは通常より大きく、収集に時間がかかります。

上記のグラフに基づいて、ヒープ サイズを削減できますか?

はい。ただし、現在の構成では、アプリケーションがより忙しい期間や負荷のスパイクに遭遇する可能性がある場合に、アプリケーションに余裕ができます。

GC を最適化できますか?

はい。ただし、魔法の設定はありません。最初の質問は、本当に必要ですか? アプリケーションが単なる非対話型の「プロセッサ」である場合、私は気にしません。一時停止の少ないアプリケーションが本当に必要な場合は、いくつかの調整を利用できます. 通常、トレードオフは、同じ結果を得るために、より多くのリソースが必要になることです。

私の経験では、一時停止の少ない JVM 構成では、負荷が増加したときに非常に顕著な低下点があります。アプリケーションが通常かなりアイドル状態であるが、呼び出されたときに「迅速な」応答が期待される場合は、一時停止を短くすることが適切な場合があります。トラフィックや負荷がピークに達するビジーなシステムでは、従来のアプローチを好むかもしれません。

概要

いずれにせよ、構成を「改善」するために恣意的な変更を加えようとしないでください。アプローチについて科学的かつ専門的であること。

運用メトリックを利用できない場合は、Apache JMeterなどのツールを使用して負荷テスト シナリオを構築し、アプリケーションの一般的なライブ負荷、増加した負荷 (たとえば、10%、20%、50% など) および断続的な負荷をシミュレートすることを検討してください。ピーク負荷。

GC とアプリケーションの両方にメトリクスを使用し、少なくとも以下を測定します。

  • 平均スループット。
  • ピーク スループット。
  • 平均負荷 (CPU とメモリ)。
  • ピーク負荷。
  • アプリケーションの一時停止時間 (合計および個々の一時停止)。
  • コレクションの実行に費やされた時間。
  • 信頼性 (OOME など)。

現在の構成でアプリケーションのパフォーマンスに関する正確なベンチマークを記録できたことに満足したら、変更を開始する必要があります。

明らかに、構成とそのメトリックを記録します。変更を文書化し、同じベンチマーク テストを実行します。次に、パフォーマンスの向上 (または低下) と、適用可能なトレードオフを確認できます。

これは、あなたが始めるための主題に関するオラクルからのさらなる読み物です：

Java SE 6 仮想マシンのガベージ コレクションのチューニング

于 2012-10-24T10:39:13.013 に答える