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.
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:
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.