Hello Kousika!
I can understand why promoted bytes and promotion rates are reported as n/a in a few of your GC log files. Let me see whether I can explain it properly.
Based on the GC log file you have sent, I can see that you have enabled GC log file rotation in your applications. Please be advised that enabling GC log file rotation has certain lunatic behaviour. Current issue that we are facing is surfacing because of it.
In your GC log files, young gen, old gen size are reported. These Generation size information is required to calculate the promoted bytes information. Below is the excerpt from your GC log file:
[75577.133s][info][gc,heap ] GC(7061) Eden regions: 742->0(743)
[75577.133s][info][gc,heap ] GC(7061) Survivor regions: 26->25(96)
[75577.133s][info][gc,heap ] GC(7061) Old regions: 1430->1303
In the above example it's reported that in the GC event #7061, old generation region count was 1430, after the GC event, region count dropped to 1303.
This information is not enough to calculate the generation size in (bytes). Formula to compute Generation size is below:
Generation Size = Region Count * Region Size
In the above example, we have only region count and region size is not present. Region size is reported in the initial few lines of the GC log file. Below is an example of it:
[2017-10-22T20:14:17.636-0700] Heap region size: 1M
In your case since the GC log file is rotated, 'Heap region size' information is missing. Thus GCeasy isn't able to compute individual region size, due to that Young Gen Graph, Old Gen Graph, Total promoted bytes, Avg promotion rate metrics are not printed in the report.
So how to fix this problem? You want to stop the GC log file rotation. Don't worry about the growing file size. Use the %t prefix approach as outlined in this blog post. Using the %t approach all the GC events from the starting of the JVM will be reported in one single GC log file. It's easy for troubleshooting and GC log file management.
Edit your Comment