Question

GC overhead limit exceeded

0

Hi, we’re receiving critical log messages, and the following error is shown in the log. Do you have suggestions or know which component this is? Jul 12 11:01:05.315 - CRITICAL - ActionManager: Error in execution of monitored action 'RegularClientAction' (execution id: 1594544260276-30, execution type: CLIENT) Jul 12 11:01:05.316 - CRITICAL - ActionManager: #011at com.mendix.basis.actionmanagement.CoreActionHandlerImpl.doCall(CoreActionHandlerImpl.scala:79)

asked 2020-07-10

Wilfried Mulder

2 answers

Rom van Arendonk · Answer 1 · 2020-07-14

Out of memory exceptions are project specific, and it'll be very hard to point to a specific part in your application without having knowledge of it. This is one of two types of common out of memory exception (the other is a heap space error). Such error are hard to debug, mostly because there is very little information available after the crash.

The CG overhead limit exceeded is caused by the garbage collector looking for memory to free, but it doesn't find any. Usually, this indicates that there are many concurrent actions running on the server, or that one component has a memory leak (i.e. it doesn't let the garbage collector free the memory even when the component doesn't need it anymore).

The Mendix Cloud provides some tools to help you diagnose these problems when the system is running. The first thing to check would be Metrics of your environment, and the tab Running Now. The second thing to check is the Metrics, JVM object heap. You should see the read area being garbage collected once it reaches around 60% of total memory and the pink area should be garbage collected to look like triangles. I would consider the following picture okay, although the amount of free space from the red area is very little. Then again, this is a small test environment, so it's probably okay.

If either red of pink area's keep increasing (such as in the image below), there is a memory leak. In this case, I believe you can request a memory dump from Mendix (or you can try to run your app locally and make a memory dump there). Such a memory dump can be analyzed, e.g. by using the MAT plugin for Eclipse. When looking at a memory dump, you will see the objects that are present in memory, and this will usually point to the problem area in your application.

Nirmalkumar · Answer 2 · 2020-07-15

This actually means application needs (Java) memory to create more objects, but java memory is already full of active objects in which moment, garbage collection kicks in and tries to free up memory. But given almost most of the objects in memory are active, it cleans up very little, but also spends more time in cleaning.

Indeed its quite hard to trace why GC overhead limit exceeded. But few pointers based on my experience:

Immediate temporary solution: the INFRA must be upgraded to support the amount of concurrent users using the application.
Check if your INFRA can support the number of concurrent users.
When this issue occurs, in my situation happened many times, I would download the logs and try to find the pattern of usage by our users.
We might be able to find which particular functionality when overused causes this. And see, if we can limit some dataset on those areas to fix this.
Trust me, I have looked in heap dumps of Mendix many times. But it never gave me much useful information, thats because of how Mendix is built internally. End of line, you see mostly String and a lot of Strings. MAT or JvisualVM no difference.

This is not JVM running out of memory, which is memory leaks that can be analysed and fixed.

IMHO, limiting data being processed and/or increasing Hardware might be fix the issue.