2

Solr インストールの gc ログ ファイルを調べていたところ、若い世代の gc に 30% の時間がかかっていることに気付きました。以下のログ スニペットは約 1 秒に及び、gc 時間の合計は 0.34 秒になります。

私の質問は次のとおりです。これは問題ですか?もしそうなら、何が原因ですか?

Linuxでjdk 1.6.0_24を実行しています

1004626.109: [GC 1004626.109: [ParNew: 74847K->5219K(76672K), 0.0838750 secs] 10831779K-
10762151K(11525824K), 0.0841790 secs] [Times: user=0.24 sys=0.00, real=0.09 secs] 
1004626.320: [GC 1004626.320: [ParNew: 73379K->5468K(76672K), 0.0527070 secs] 10830311K->10762874K(11525824K), 0.0529680 secs] [Times: user=0.20 sys=0.00, real=0.06 secs] 
1004626.511: [GC 1004626.511: [ParNew: 73628K->4986K(76672K), 0.0591070 secs] 10831034K->10763002K(11525824K), 0.0593820 secs] [Times: user=0.20 sys=0.00, real=0.05 secs] 
1004626.698: [GC 1004626.698: [ParNew: 73146K->5611K(76672K), 0.0523060 secs] 10831162K->10764169K(11525824K), 0.0525820 secs] [Times: user=0.21 sys=0.00, real=0.05 secs] 
1004626.902: [GC 1004626.902: [ParNew: 73771K->6878K(76672K), 0.0653490 secs] 10832329K->10765868K(11525824K), 0.0656210 secs] [Times: user=0.22 sys=0.00, real=0.06 secs]
4

2 に答える 2

4

いいえ、それは問題ではありません。これは、オブジェクトが行き来することを意味します。オブジェクトをスコープ内で作成し、使用すると、GC の対象となります。それは何かが間違っているという兆候ではないと思います。

もう 1 つの極端な例が問題になります。オブジェクトが作成され、古くなり、長く残りすぎます。ここでメモリ リークが発生し、perm 領域がいっぱいになります。

于 2012-04-21T12:53:01.503 に答える
2

ここに問題があると思います。

私は GC ログを読む専門家ではありませんが、76672K の「若い」スペースと 11525824K の合計ヒープ サイズがあると言っていると思います。さらに、各 GC サイクル後の合計ヒープ使用量は 10765868K であり、増加しています。そして、(明らかに) 時間の ~30% をガベージ コレクションに費やしています。

私の診断では、あなたのヒープはほぼ満杯であり、直接的な結果としてガベージ コレクションにかなりの (そして増加している) 時間の割合を費やしています。

私のアドバイスは、アプリケーションを再起動し (短期)、メモリ リークを探すことです (長期)。メモリ リークがない場合 (つまり、アプリケーションがそのヒープ スペースをすべて使用している場合)、アプリケーションのメモリ使用量を減らす方法を探す必要があります。

あなたのアプリケーションはかなりの量のガベージを生成しているように見えますが、それは必ずしも心配する必要はありません。HotSpot GC はガベージをかなり効率的に再利用できます。パフォーマンスの問題を引き起こすのは、処理しなければならない非ガベージの量です。

于 2012-04-21T14:18:44.240 に答える