6

以下に示すように、すべてが期待どおりに機能している最中に、stop-the-world GC 操作に +60 秒かかりました。（テラコッタ）クライアントがドロップアウトし、その間（テラコッタサーバー）が応答しなかったと不平を言ったため、それはずっと世界を止めていると判断される可能性があります。

これは若い/マイナー GC ですか? はいの場合、それは若い世代 (エデン + サバイバー?) の飢餓が原因である可能性があります。

109333(KB)だけ解放されるの？

さまざまなメモリ コンテナーのグラフ化を開始します。このような問題をさらに診断するためにできる他の提案はありますか?

date, startMem=24589884, endMem=24478495, reclaimed=111389, timeTaken=0.211244 (1172274.139: [GC 24589884K->24478495K(29343104K), 0.2112440 secs])
date, startMem=24614815, endMem=24505482, reclaimed=109333, timeTaken=61.301987 (1172276.518: [GC 24614815K->24505482K(29343104K), 61.3019860 secs])
date, startMem=24641802, endMem=24529546, reclaimed=112256, timeTaken=2.68437 (1172348.921: [GC 24641802K->24529546K(29343104K), 2.6843700 secs])

Sun JVM は 1.6 で、次の構成を使用します。

-Xms28672m -Xmx28672m -XX:+UseConcMarkSweepGC -XX:+PrintGCTimeStamps -XX:+PrintGC

GC をさらにデバッグするための適切な構成調整:

'-XX:+PrintGCDateStamps' Print date stamps instead of relative timestamps
'-XX:+PrintGCDetails' Will show what cpu went for (user, kern), gc algorithm used 
'-XX:+PrintHeapAtGC' will show all of the heaps memory containers and their usage
'-Xloggc:/path/to/dedicated.log' log to specific file
4

1 に答える 1

1

-XX:+UseConcMarkSweepGC同時収集を可能にする

デフォルト対。 CMS

所要時間の合計は、stop-the-world フェーズ (JVM がブロックされている) と並行フェーズ (JVM がユーザー コードを実行している) の合計です。

+60 秒のうち JVM をブロックしている秒数に関する情報がないため、詳細な GC ロギングを有効にしてさらに調査する必要があります。

于 2013-01-28T17:39:47.397 に答える