When the TIBCO StreamBase 7.x server is running, it fails after a long period of running with error:

java.lang.OutfMemoryError: GC overhead limit exceeded

java.lang.OutOfMemoryError GC overhead limit exceeded

Note: This article is only for StreamBase 7.x.

This is how to respond to errors in sbd output like these:

2009-02-10 11:05:19.100-0500 [EnqueueClient (172.18.14.180:1930)] ERROR c.streambase.sb.xmlrpc.XmlRpcManager - Java heap space
Exception in thread "EnqueueClient (172.18.14.6:3740)" [error] java.lang.OutOfMemoryError: GC overhead limit exceeded

For reference see:
https://www.oracle.com/java/technologies/javase/gc-tuning-6.html#par_gc.oom
"Excessive GC Time and OutOfMemoryError -- The parallel 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."

The best way to size an application to see how much RAM will be needed to launch it is to set the relevant -Xms and -Xmx settings to as much physical RAM as you can allow and add the -verbose:gc setting. The output will be something like this:

[GC 744875K->681429K(777728K), 0.1330120 secs]
[GC 751381K->681594K(777728K), 0.2700550 secs]
[GC 751546K->682121K(777728K), 0.0652790 secs]
[GC 752073K->684712K(777728K), 0.0317210 secs]
[Full GC 749058K->47325K(777728K), 85.4002760 secs] ** wow!
[GC 117277K->50239K(777728K), 0.0592540 secs]
[Full GC 109154K->52323K(777728K), 0.4170530 secs]
[GC 122275K->54817K(777728K), 0.0115080 secs]
[Full GC 102482K->57032K(777728K), 0.3357050 secs]
[GC 126984K->59827K(777728K), 0.0407400 secs]
[Full GC 101930K->26261K(777728K), 2.3508700 secs]
[GC 96213K->29034K(777728K), 0.0124360 secs]
[Full GC 98865K->31658K(777728K), 0.4487010 secs]
[GC 101610K->34156K(777728K), 0.0116610 secs]
[Full GC 81975K->36589K(777728K), 0.5034000 secs]
[GC 106541K->42452K(777728K), 0.2350760 secs]

Note for the above trace, the first number after "GC" is the size of the heap before GC. The maximum value is the size to set -Xmx for the current application. When you see a "Full GC", it means that enough heap was requested to force the garbage collector to be aggressive. If "Full GC" repeats frequently, then the -Xmx setting is too small and needs to be increased to not risk seeing an OutOfMemoryError.

The rule of thumb for setting -Xmx: Don't set the maximum memory to above 70% of the physical memory or it will grind to a halt swapping to virtual memory.

As for configuring StreamBase, excessive queuing of tuples is the primary cause of Heap exhaustion. Tune using the sbd.sbconf settings in the <server>, <page-pool>, and <java-vm> sections.

Run with '-verbose:gc' set in the <java-vm> section, monitor with 'sbmanager' (for the graphs) and see what's getting used under what conditions.

Typically resolving the "OutOfMemoryError: GC overhead limit exceeded" does not involve tuning the garbage collector, but instead involves tuning the memory parameters: -Xms256M, -Xmx512M, and -XX:MaxPermSize=256M; and modifying the queuing within the application.