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
Depending on the time of day, full GC happens as often as every 5 minutes when busy, or up to 30 minutes can go by in between full GCs during the slow periods.
Typically, your JVM should: Spend less than 0.5 seconds in each GC cycle. The percentage of time in garbage collection should be less than 3% - This percentage can be calculated by dividing the sum of the garbage collection times over an interval by the interval.
Large Heap size If heap size is quite high, then more garbage will be get accumulated in the heap. When Full GC is triggered to evict the all the accumulated garbage in the heap, it will take long time to complete. Logic is simple: If you have small can full of trash, it's going to be quick and easy to dispose them.
-XX:+UseConcMarkSweepGC
enables concurrent collection
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With