Do I need to increase max heap size?

Hi Manjari.pandey,

Greetings. I reviewed your GC log analysis report the duration of your GC log is just 3 min 38 sec with this short window we cannot make a decision to increase the heap size. Can you please do some activity with your application and take the GC log after a few hours and upload it so that we can investigate and make a decision?

As per the attached GC log report, You are having an excellent GC throughput: 100%. One can't ask better than this. Also, your average pause time is only 0.0363 ms. So I don't see a need to increase the heap size. I am just curious, what makes you think that you need to increase the max heap size? 

Hi manjari,

I reviewed your GC report. Here are my few observations:

a) 'Ergonomics' event : 1 min 34 sec 864 ms of GC pause time is triggered by 'Ergonomics' event. GC ergonomics tries to grow or shrink the heap dynamically to meet a specified goal such as minimum pause time and/or throughput..

Solution:
You can pass '-XX:-UseAdaptiveSizePolicy' argument. It will disable JVM from dynamically adjusting the sizes of the young generation and old generation at runtime based on workload characteristics. Additionally it will also disable the garbage collector from trying to meet default GC throughput goals. It will minimize the number of Ergonomics GC events that are getting triggered.

b) G1 Evacuation Pause event : Due to 'G1 Evacuation Pause' your application is pausing for

31 sec 99 ms.

Our ML algorithm, provides following suggestion to improve the 'G1 Evacuation pause' time:

Solution:
1. Evacuation failure might happen because of over tuning. So eliminate all the memory related properties and keep only min and max heap and a realistic pause time goal (i.e. Use only -Xms, -Xmx and a pause time goal -XX:MaxGCPauseMillis). Remove any additional heap sizing such as -Xmn, -XX:NewSize, -XX:MaxNewSize, -XX:SurvivorRatio, etc.

2. If the problem still persists then increase JVM heap size (i.e. -Xmx).

3. If you can't increase the heap size and if you notice that the marking cycle is not starting early enough to reclaim the old generation then reduce -XX:InitiatingHeapOccupancyPercent. The default value is 45%. Reducing the value will start the marking cycle earlier. On the other hand, if the marking cycle is starting early and not reclaiming, increase the -XX:InitiatingHeapOccupancyPercent threshold above the default value.

4. You can also increase the value of the '-XX:ConcGCThreads' argument to increase the number of parallel marking threads. Increasing the concurrent marking threads will make garbage collection run fast.

5. Increase the value of the '-XX:G1ReservePercent' argument. Default value is 10%. It means the G1 garbage collector will try to keep 10% of memory free always. When you try to increase this value, GC will be triggered earlier, preventing the Evacuation pauses. Note: G1 GC caps this value at 50%.

c) It looks like your application's Initial heap size and Max heap size is set to different values. Setting initial and Max heap size to same value has potential to improve your application's availability, performance and startup time. See details here.

d) As you are using G1 GC algorithm you may consider passing -XX:+UseStringDeduplication to your application. It will remove duplicate strings in your application and has potential to improve overall application's performance. You can learn more about this property in this article.