search cancel

java.lang.OutOfMemoryError: GC overhead limit exceeded


Article ID: 74837


Updated On:


CA Application Test CA Continuous Application Insight (PathFinder)


The registry is going down frequently with the Out Of Memory error .

java.lang.OutOfMemoryError: GC overhead limit exceeded
        at java.util.Vector.<init>(
        at java.util.Vector.<init>(
        at java.util.Vector.<init>(
        at java.lang.ClassLoader.<init>(
        at java.lang.ClassLoader.<init>( 

The same error (java.lang.OutOfMemoryError: GC overhead limit exceeded) can occur for other components.

For example it may occur in the vse.log:

ERROR com.itko.util.Pulse            - Error calling object pulse()
java.lang.OutOfMemoryError: GC overhead limit exceeded




Running out of memory.


All supported DevTest releases.


Increase the Java heap memory configured for the component with the error.

If the error is reported by the registry, increase the Registry.vmoptions and RegistryService.vmoptions files with the following values for example:


Bring down the Registry.
Delete all the registry logs.
Start the Registry.
This resolved the issue.

To enable the CMS Collector use.

The Concurrent Mark Sweep (CMS) collector (also referred to as the concurrent low pause collector) collects the tenured generation. It attempts to minimize the pauses due to garbage collection by doing most of the garbage collection work concurrently with the application threads. Normally the concurrent low pause collector does not copy or compact the live objects. A garbage collection is done without moving the live objects. If fragmentation becomes a problem, allocate a larger heap.

CMSIncrementalMode currently uses certain young gen allocation point threshold crossings to act as the strobe to enable and disable the CMS work. The CMS collector can be used in a mode in which the concurrent phases are done incrementally. Recall that during a concurrent phase the garbage collector thread is using one or more processors. The incremental mode is meant to lessen the effect of long concurrent phases by periodically stopping the concurrent phase to yield back the processor to the application. This mode, referred to here as i-cms, divides the work done concurrently by the collector into small chunks of time that are scheduled between young generation collections. This feature is useful when applications that need the low pause times provided by the CMS collector are run on machines with small numbers of processors (for example, 1 or 2).

If the error is reported by the VSE, increase the -Xmx value in the VirtualserviceEnvironmentService.vmoptions and VirtualserviceEnvironment.vmoptions files as follows, for example:


This value can be increased further if the error persists and there is enough memory available on the machine.