4

ある時点で、私のアプリケーションは多くの一時配列を作成し始めます。これは予期された動作であり、Young Generation に多くのスペースを与えたいので、一時配列は Tenured Generation に昇格されません。

JVM オプション: java -Xmx240g -XX:+UseConcMarkSweepGC -XX:NewRatio=2 -XX:+PrintGCTimeStamps -verbose:gc -XX:+PrintGCDetails

ある時点で、私の GC ログは次のようになり始めます。

800.020: [GC 800.020: [ParNew: 559514K->257K(629120K), 0.1486790 secs] 95407039K->94847783K(158690816K), 0.1487540 secs] [Times: user=3.34 sys=0.05, real=0.15 secs] 
800.202: [GC 800.202: [ParNew: 559489K->246K(629120K), 0.1665870 secs] 95407015K->94847777K(158690816K), 0.1666610 secs] [Times: user=3.79 sys=0.00, real=0.17 secs] 
800.402: [GC 800.402: [ParNew: 559478K->257K(629120K), 0.1536610 secs] 95407009K->94847788K(158690816K), 0.1537290 secs] [Times: user=3.48 sys=0.02, real=0.15 secs]

Young Generation のサイズが 629120K (=629M) であるという事実に非常に混乱しています。158690816K (=158G) である Tenured Generation サイズの 1/2 (NewRatio=2 のため)。Tenured サイズの生成は、予想どおり NewRatio および Xms に対応します。つまり、合計ヒープ サイズの 2/3 です。

JVM バージョン: java version "1.7.0_21" Java(TM) SE Runtime Environment (build 1.7.0_21-b11) Java HotSpot(TM) 64-Bit Server VM (build 23.21-b01, mixed mode)

更新: この時点 (実行時間 800 秒) で、プログラムの一時的な配列の使用量がピークに達していると思います。プログラムが 629M Young 世代のサイズを超えない場合、NewRatio を増やす必要があるということですか? プログラムにより多くのワークロードを与えることを計画しており、一時アレイのボリュームと永続アレイのボリュームの比率が同じになると予想しているとします。

以前に NewRatio=8 でプログラムを実行しましたが、gc ログは主に次のような行で構成されています。

800.004: [GC 800.004: [ParNew: 186594K->242K(209664K), 0.1059450 secs] 95345881K->95159529K(126655428K), 0.1060110 secs] [Times: user=2.41 sys=0.00, real=0.10 secs] 
800.122: [GC 800.122: [ParNew: 186610K->221K(209664K), 0.1073210 secs] 95345897K->95159522K(126655428K), 0.1073900 secs] [Times: user=2.37 sys=0.07, real=0.11 secs] 
800.240: [GC 800.240: [ParNew: 186589K->221K(209664K), 0.1026210 secs] 95345890K->95159524K(126655428K), 0.1026870 secs] [Times: user=2.34 sys=0.00, real=0.10 secs] 
800.357: [GC 800.357: [ParNew: 186589K->218K(209664K), 0.1043130 secs] 95345892K->95159527K(126655428K), 0.1043810 secs] [Times: user=2.30 sys=0.07, real=0.10 secs] 

NewRatio は現在、Young 世代のサイズに影響を与えていると思われますが、現在の Young 世代はヒープ サイズの 1/9 をはるかに下回っているため、そうすべきではありません。

更新 2: これは膨大な科学計算であり、私のソリューションには最大 240 GB のメモリが必要です。これはメモリリークではなく、アルゴリズムは私が思いついた最高のものです。

4

2 に答える 2

1

AdaptiveSizePolicy を無効にして実行してみてください-XX-UseAdaptiveSizePolicy

これにより、各ヒープ領域のサイズを事前に設定できるようになり、実行時のサイズの動的変更が無効になります。

于 2013-04-22T03:30:41.130 に答える
0

まず、-XX:NewRatio および -XX:OldSize JVM フラグの意味を確認してください。

NewRatio は、古い世代に対する若い世代の比率です (たとえば、値 2 は、古い世代の最大サイズが若い世代の最大サイズの 2 倍になることを意味します。つまり、若い世代はヒープの 1/3 まで取得できます)。

若い世代のサイズが正しいことがわかります。

Javaヒープのスペース/世代間の比率は一定ですか?も確認することをお勧めします。を使用して最初から静的サイズを設定します

-Xms240g -Xmx240g -XX:NewSize=120g -XX:MaxNewSize=120g -XX:-UseAdaptiveSizePolicy
于 2013-04-29T14:22:17.500 に答える