7

Web アプリケーション用に JVM を構成するための適切な設定を探しています。古い/若い/パーマの世代について読んだことがありますが、この構成でこれらのパラメーターを使用するのはうまくいきません。

4GBのうち、約3GBがキャッシュ( EhCacheを使ったアプリカティブキャッシュ)に使われているので、それを考慮して最適な設定を探しています。参考までに、キャッシュはアプリケーションの存続期間中は静的です (ディスクからロードされ、期限切れになることはありません) が、頻繁に使用されます。

私はすでにアプリケーションのプロファイリングを行い、DB クエリ、アプリケーションのアーキテクチャ、キャッシュ サイズなどに関する最適化を実行しました。ここで JVM 構成のアドバイスを探しています。ガベージ コレクターの99% のスループットを測定したところ、フル GC の実行時に 6 ～ 8 秒の一時停止がありました (約 1/2 時間に 1 回)。

現在の JVM パラメータは次のとおりです。

-XX:+UseParallelGC -XX:+AggressiveHeap -Xms2048m -Xmx4096m
-XX:NewSize=64m -XX:PermSize=64m -XX:MaxPermSize=512m
-verbose:gc -XX:+PrintGCDetails -Xloggc:gc.log

これらのパラメーターは、かなり前に記述されているため、完全にオフになっている可能性があります... アプリケーションがそれほど大きくなる前に。

Java 1.5 64 ビットを使用しています。

改善の可能性はありますか？

編集：マシンには4つのコアがあります。

4

3 に答える 3

5

-XX:+UseParallel*古い*GC は、マルチコア マシンでフル GC を高速化する必要があります。

異なる NewRatio 値でプロファイリングすることもできます。キャッシュされたオブジェクトは Tenured 世代に存在するため、-XX:NewRatio=7 でプロファイリングしてから、より高い値とより低い値を使用して再度プロファイリングします。

プロファイリング中に実際の使用を正確に再現できない場合があるため、GC が実際に使用されている場合は必ず監視し、小さな変更 (サバイバー スペースなど) を加えて、それらの影響を確認してください。

以前のアドバイスでは、Xms および Xmx で AggressiveHeap を使用しないでください。それが今でも正しいかどうかはわかりません。

編集:デプロイされている OS/ハードウェア プラットフォームをお知らせください。

30 分ごとの完全なコレクションは、古い世代がかなりいっぱいであることを示します。newRatio の値が高いと、若い世代を犠牲にしてより多くのスペースが与えられます。JVM に 4g 以上を提供できますか、それとも制限されていますか?

また、目標/非機能要件が何であるかを知ることも役立ちます。スループットが低下するリスクを冒してこれらの 6 秒または 7 秒の一時停止を回避したいですか?それとも、これらの一時停止は、可能な限り最高のスループットを得るために許容できる妥協点ですか?

一時停止を最小限に抑えたい場合は、両方を削除して CMS コレクターを試してください。

-XX:+UseParallelGC -XX:+UseParallelOldGC

と追加

-XX:+UseConcMarkSweepGC -XX:+UseParNewGC

さまざまな NewRatio 値を使用してプロファイリングし、どのようにうまくいくかを確認します。

CMS コレクターの欠点の 1 つは、パラレルの古いコレクターやシリアルのコレクターとは異なり、古い世代を圧縮しないことです。古い世代が断片化しすぎて、マイナー コレクションが一度に多くのオブジェクトを古い世代にプロモートする必要がある場合、完全なシリアル コレクションが呼び出される可能性があり、これは長い一時停止を意味する可能性があります。(私はこれを本番環境で一度見たことがありますが、圧縮コレクションを呼び出す代わりにメモリ不足になった IBM JVM を使用していました!)

これは問題にならないかもしれませんが、アプリケーションの性質にもよりますが、毎晩または毎週再起動することで確実に回避できます。

于 2012-01-10T13:30:37.623 に答える
4

Java 6update30または7update2、64ビットを使用すると、はるかに効率的です。たとえば、デフォルトで32ビット参照を使用します。

また、可能であれば、ダイレクトメモリまたはメモリマップトファイルを使用するようにEhcacheを構成します。これにより、GCへの影響を最小限に抑えることができます。

これらのオプションを使用すると、ヒープのフットプリントをほぼなくすことができます。たとえば、16GBのメモリを搭載したマシンで最大180GBのメモリマップファイルを使用するアプリがあり、ヒープサイズは6MBです。完全なGCは、手動でトリガーすると最大11ミリ秒かかりますが、GCが発生することはありません。;）

8 TBのファイルをメモリにマップして更新する簡単な例が必要な場合は、http://vanillajava.blogspot.com/2011/12/using-memory-mapped-file-for-huge.html

于 2012-01-10T13:30:54.580 に答える
0

投稿を膨らませないように -server を削除したことを願っています。それ以外の場合は、すぐに有効にする必要があります。起動時間が少し長いことを除けば (これは、何日も実行する必要がある Web アプリケーションにとって実際には問題ではありません)、c2 以外を使用する理由はありません。これにより、一般的にパフォーマンスが向上する可能性があります。トピックに戻ります。

残念ながら、私が考えることができる最善の方法は、古い JVM では機能しません。G1 ガベージ コレクタは、基本的にレイテンシを短縮するように設計されています。一般的に一時停止を削減しようとするだけでなく、一時停止の目標と間隔を設定するためのいくつかの調整パラメーターも提供します。このページを参照してください。

java6 への実験的なバックポートがありますが、最新の状態に保たれているとは思えません。そして、Java 1.5 向けに GC などを最適化するために時間を無駄にする人はもういないと思います。

PS: IBM の JVM と明らかにazul システムもあるでしょう(それは深刻な提案ではありませんでした ;)) が、それらは明らかに問題外です..それらについて言及したかっただけです。

于 2012-01-10T17:45:42.023 に答える