Process went down even though GC throughput is >99%! Whether I am having memory le...

Hi Vicky,

1. I can't see the memory leak in the attached report link.

2. Here are some observations and recommendations:

a) As you can see in below screenshot, your application was paused around 11 times during the full GC event and all these events took more than 5 seconds. Long-running GC events are unfavorable for application performance. Click here to see recommendations from GCeasy to reduce long pauses.

b) 41.39% of GC pause time (6 min 35 sec 353 ms) was taken by Full GC - Allocation Failure. 

Allocation failure happens for the following 2 reasons:

• Application is creating too many objects that can't be reclaimed quickly.
• When the heap is fragmented, direct allocation in the old generation may fail even if there is a lot of space.

Solutions:

• Increase the number of concurrent marking threads by setting -XX:ConcGCThreads value. Increasing the concurrent marking threads will make garbage collection run fast.
• Even though there is enough space in a heap, a Full GC can also occur due to the lack of a contiguous set of space. This can happen because of a lot of humongous objects present in the memory. A potential solution to solve this problem is to increase the heap region size by using the option -XX:G1HeapRegionSize to decrease the amount of memory wasted by humongous objects.
• Force G1 to start marking phase earlier. This can be achieved by lowering '-XX:InitiatingHeapOccupancyPercent' value. Default value is 45. It means the G1 GC marking phase will begin only when heap usage reaches 45%. By lowering the value, the G1 GC marking phase will get triggered earlier so that Full GC can be avoided.

c) 0.01% of GC pause time (128 ms) was taken by 'Metadata GC Threshold' event. This happens for the following 2 reasons:

• Configured metaspace size is too small than actual requirement
• There is a classloader leak (very unlikely, but possible).

Solution:

You may consider setting -XX:MetaspaceSize to a higher value. If this property is not present already please configure it. Setting -XX:MetaspaceSize to a higher value will reduce 'Metadata GC Threshold' frequency. If you still see 'Metadata GC Threshold' event reported, then you need to capture the heap dump from your application and analyze it.

d) -XX:+UseGCLogFileRotation argument is not recommended to be passed. It can have undesirable effects. Click here to learn more about its effect and alternative solutions.

Hi Vikky!

I don't think so you have a memory leak. It looks like there is heavy traffic volume from the time period 2.35 pm to 2.57 pm. If you zoom the Heap Usage graph, you can find that heavy traffic is flowing.

Hello Vikky,

1. There is no memory leak in the attached GCeasy report.

As I observed, traffic is huge between 2:35p.m - 2:57p.m. So heap size increased exponentially during the same interval. As traffic reduced after 2:57p.m. graph become flatter where heapsize is remained constant.(~10000mb). Kindly refer below image.

2) For GC tuning recommendation please check this link to reduce long pauses.