what exactly counts alert "GC
Caused Suspension Time"? Customer during performance test often receives alert . Application works with no delays. Attached log has info, Full GC duration is 2-3s once or twice per minute. GC chart reports more than 15% time at GC.
Aarchived GC log attached too gc.log
Used java 1.8.0_171 with params :
-XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+UseGCLogFileRotation
Thank you for explanation.
Solved! Go to Solution.
This alert means that 15 % of the total transaction time (PerePath Duration) is spent on garbage collector. For example, if your PP time = 10 s than GC time = 1,5 s for this PP
on your screen we can see that this time equally 10 s (it's a big enough time). We also see that garbage cleaning occurs quite often.
you have delays for GC Caused Suspension Time but it's up to you to decide whether they affect your application or not
also I will tell you what GC Caused Suspension Time = GC old gen + GC young gen
Hi @Andrey S.,
thanks for your explanation. Your last sentence about how the GC Caused Suspension Time is going to be calculated is exactly how I also understood that and in the praxis a couple of time confirmed. But now I have a really strange situation and don't know which of the values is correct.
As you can see GC Time on Young & Old generation showing very high values and the GC Caused Suspension Time only about 5-6 seconds.
Do you have any clue what is here wrong?
Peter, Keep in mind that a subset of GC time is suspension time. Not all GC work requires the worker threads to be suspended. So obviously the critical GC time is that part which affects the users, namely suspension time.
One thing that might help is to create a stacked graph with Old Gen, Survivor and Young Gen together. Then put Committed on there as a reference. It's possible you're running out of OldGen. This can be seen in the OldGen Graph by the fact that it keeps peaking at Aprox 1G, then flatlines around 21:33.
You might want to experiment and remove all your -XX memory directives, these are experimental and may have undesired impact. With AppMon, you still get the visibility to determine the results of removing them, without the risk of them being present.
Consider increasing MX and seeing if OldGen stablizes, or use AppMon Memory Diagnostics to determine the long living object(s) which take up all the OldGen space. This could be useful to the developers to address your memory behavior.