java.lang.OutOfMemoryError: GC overhead limit exceeded

Document ID : KB000074837
Last Modified Date : 26/03/2018
Show Technical Document Details
Issue:
One of the Lisa 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)   
Environment:
Linux Redhat 6.9
Cause:
Running out of memory.
Resolution:
Set the RegistryService.vmoptions file to these values:

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

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

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