2.2.5 Configuring Java Virtual Machine Memory

One of the difficulties of tuning Oracle GoldenGate for Big Data is deciding how much Java virtual machine (JVM) heap memory to allocate for the Replicat process hosting the Java Adapter. The JVM memory must be configured before starting the application. Otherwise, the default Java heap sizing is used. Specifying the JVM heap size correctly sized is important because if you size it to small, the JVM heap can cause runtime issues:

  • A Java Out of Memory exception, which causes the Extract or Replicat process to abend.

  • Increased frequency of Java garbage collections, which degrades performance. Java garbage collection invocations de-allocate all unreferenced Java objects resulting in reclaiming the heap memory for reuse.

Alternatively, too much heap memory is inefficient. The JVM reserves the maximum heap memory (-Xmx) when the JVM is launched. This reserved memory is generally not available to other applications even if the JVM is not using all of it. You can set the JVM memory with these two parameters:

  • -Xmx — The maximum JVM heap size. This amount gets reserved.

  • -Xms — The initial JVM heap size. Also controls the sizing of additional allocations.

The -Xmx and –Xms properties are set in the Java Adapter properties file as follows:

jvm.bootoptions=-Xmx512m -Xms32m 

There are no rules or equations for calculating the values of the maximum and initial JVM heap sizes. Java heap usage is variable and depends upon a number of factors many of which are widely variable at runtime. The Oracle GoldenGate Java Adapter log file provides metrics on the Java heap when the status call is invoked. The information appears in the Java Adapter log4j log file similar to:

INFO 2017-12-21 10:02:02,037 [pool-1-thread-1] Memory at Status : Max: 455.00 MB, Total: 58.00 MB, Free: 47.98 MB, Used: 10.02 MB

You can interpret these values as follows:

  • Max – The value of heap memory reserved (typically the -Xmx setting reduced by approximately 10% due to overhead).

  • Total – The amount currently allocated (typically a multiple of the -Xms setting reduced by approximately 10% due to overhead).

  • Free – The heap memory currently allocated, but free to be used to allocate Java objects.

  • Used – The heap memory currently allocated to Java objects.

You can control the frequency that the status is logged using the gg.report.time=30sec configuration parameter in the Java Adapter properties file.

You should execute test runs of the process with actual data and review the heap usage logging. Then analyze your peak memory usage and then allocate 25% - 30% more memory to accommodate infrequent spikes in memory use and to make the memory allocation and garbage collection processes efficient.

The following items can increase the heap memory required by the Replicat process:

  • Operating in tx mod (For example, gg.handler.name.mode=tx.)

  • Setting the Replicat property GROUPTRANSOPS to a large value

  • Wide tables

  • CLOB or BLOB data in the source

  • Very large transactions in the source data