Pete Freitag Pete Freitag

OutOfMemoryError - GC overhead limit exceeded

Updated on January 22, 2021
By Pete Freitag

Someone asked me recently about the following exception on their ColdFusion / Tomcat server:

java.lang.OutOfMemoryError: GC overhead limit exceeded

This exception is thrown by the garbage collector (in the underlying jvm, it's not specific to Tomcat or ColdFusion), when it is spending way too much time collecting garbage. This error essentially means that you need to add more memory, or reconfigure your garbage collection arguments. You can suppress this error by adding -XX:-UseGCOverheadLimit to your JVM startup arguments.

Here's what Sun has to say about it:

The parallel / concurrent collector will throw an OutOfMemoryError if too much time is being spent in garbage collection: if more than 98% of the total time is spent in garbage collection and less than 2% of the heap is recovered, an OutOfMemoryError will be thrown. This feature is designed to prevent applications from running for an extended period of time while making little or no progress because the heap is too small. If necessary, this feature can be disabled by adding the option -XX:-UseGCOverheadLimit to the command line.

You can think of the OutOfMemoryError like this. Imagine your garbage collector is a janitor in an office building. His job is to collect papers from each office, recycle the paper so the office can have new blank sheets of paper. Your janitor is going to each office to see if there is any thing in the recycling bin to collect, but most offices are using their paper (memory) and not recycling it (freeing it). The Out of Memory Error is thrown when the janitor (GC) is spending all his time going from office to office but not finding much, if any paper to recycle. It's a supply / demand problem and we either need more paper to work with (more RAM), or more efficient use of the paper we have (better code).

java jvm coldfusion garbage collector tuning performance

OutOfMemoryError - GC overhead limit exceeded was first published on March 25, 2010.

If you like reading about java, jvm, coldfusion, garbage, collector, tuning, or performance then you might also like:

Weekly Security Advisories Email

Advisory Week is a new weekly email containing security advisories published by major software vendors (Adobe, Apple, Microsoft, etc).


@Bilal Thanks, yes increasing the heap size should be the first step, if possible.
by Pete Freitag on 03/25/2010 at 1:02:32 PM UTC
I ran into "java.lang.OutOfMemoryError: GC overhead limit exceeded" on a CF 8.0.1 development server but occasionally the exception was "java.lang.OutOfMemoryError: Java heap space" instead. It turned out the problem was that Server Monitoring was enabled with Memory Tracking turned on.

This post I found has more details the solution in this post is:
"In the CF administrator: Go to Server Monitoring Launch Server Monitor Up at the top there should be 3 options that say Stop Monitoring, Stop Profiling, Stop Memory Tracking. Turn them off.
However, these are turned off by default ...."
by Marc on 03/26/2010 at 1:42:18 PM UTC
RE: ...if you have CF standard you can bump this to 1024 MB

Argh! What?! I'm running into more and more issues like this and I'm really becoming disappointed with Adobe. It appears they have two versions of CF now -- developer and Enterprise because Standard is all but useless in a production environment.
by steve sommers on 03/02/2011 at 7:33:18 PM UTC
@Steve that comment you are referring to is a bit outdated... ColdFusion 8 Standard did not support 64 bit, ColdFusion 9 standard does, and thus you can go above 1GB heap sizes. The limit on the heap size is due to the 32 bit architecture, and if you run Enterprise on 32 bit you run into the same limitations.
by Pete Freitag on 03/03/2011 at 10:48:12 AM UTC
Whew! I did quite a bit of searching after I read that post and could not find any info that confirmed or denied the limit. It seems strange that this information is not more readily available in the specs or documentation.
by steve sommers on 03/03/2011 at 12:34:42 PM UTC
@Steve I agree it is a bit hard to find this info... There is a technote here: and I wrote a blog entry on it back in 2004:
by Pete Freitag on 03/03/2011 at 12:44:10 PM UTC