Java garbage collection (GC) is an automatic memory management system that attempts to reclaim memory used by objects that are no longer in use. This page describes TIBCO's suggested starting point for configuring the GC policy for running StreamBase Server.

When StreamBase Server is launched without a configuration file (whether from Studio or with sbd at the command prompt), no GC settings are used by default.

Starting with release 7.6.0, when you generate a default StreamBase Server configuration file in Studio and you opt to include the default contents, or when you generate a default configuration file with sbd –s, it contains the following suggested settings for the <java-vm> element:

<java-vm>
  <param name="jvm-args" value="
    -XX:+UseG1GC
    -XX:MaxGCPauseMillis=500 "/>
</java-vm>

These lines contain the suggested GC policy settings, which represent a compromise between tuple throughput and minimized latency, leaning more toward minimizing latency.

To favor better latency, reduce the MaxGCPauseMillis value. To favor better throughput, increase this value. There are practical maximum and minimum limits for this setting that are best found by performance testing your application.

Remember that when adding parameters to the <jvm-args> element in an sbconf file, you must repeat the default settings or lose them. See the Important note in Default Memory Settings on the Java VM Memory Settings page.

When using the G1 garbage collector, do not use any of the following parameters, which define the configuration for the non-G1 garbage collector:

StreamBase Studio honors the jvm-args parameter of the <java-vm> element as long as the server configuration file is at the root of the Studio project and is named sbd.sbconf. StreamBase bundles also run with any specified <java-vm> settings as long as the bundle is created with those configuration file settings.

Both StreamBase and Live Datamart support a customer-installed Azul Zing JDK. Zing has its own GC implementation, and is recommended for applications that require consistently very low latency, or that have very large heap requirements.