java.lang.OutOfMemoryError: GC overhead limit exceeded

Products

• CA Continuous Application Insight (PathFinder)
• Service Virtualization

Issue/Introduction

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

java.lang.OutOfMemoryError: GC overhead limit exceeded
        at java.util.Vector.<init>(Vector.java:135)
        at java.util.Vector.<init>(Vector.java:148)
        at java.util.Vector.<init>(Vector.java:157)
        at java.lang.ClassLoader.<init>(ClassLoader.java:250
        at java.lang.ClassLoader.<init>(ClassLoader.java:316) 

The same error (java.lang.OutOfMemoryError: GC overhead limit exceeded) can occur for other components like the VSE (Virtual Service Environment Service).

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

 

 

Environment

All supported DevTest releases.

Cause

Running out of memory.

Resolution

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:

-Xms4096m
-Xmx4096m
-XX:+UseConcMarkSweepGC
-XX:+CMSIncrementalMode

Bring down the Registry.
Delete all the registry logs.
Start the Registry.

To enable the CMS Collector use.

-XX:+UseConcMarkSweepGC
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.

-XX:+CMSIncrementalMode
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:

-Xmx2048m

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