CODEWITHSUNDEEP
garbage-collectionjvmterracotta
user135361
user135361

Reputation: 125

JVM minute long GC

As seen below, in the midst of everything working as expected a stop-the-world GC operation took +60 seconds. It could be determined to be a stop the world for the entire time, because the (terracotta) clients dropped of, complaining it (the terracotta server) didn't respond during that time.

Is this young/minor GC? If yes, could it be because of starvation in the young generation (eden + survivors?).

Is only 109333(KB) free'd?

I'll start graphing the different memory containers, any other suggestion what can be done to further diagnose problems like these?

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 is 1.6, using the following config:

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

Sane config adjustments to further debug 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

Upvotes: 6

Views: 1485

Answers (1)

fglez
fglez

Reputation: 8552

-XX:+UseConcMarkSweepGC enables concurrent collection

Default Vs. CMS

Total time taken is the sum of stop-the-world phases (JVM blocked) and concurrent phases (JVM executing user code).

You should enable detailed GC logging to further investigate, as you have no information about how many of that +60 seconds are blocking the JVM.

Upvotes: 1

Related Questions