JVM heap sizing

The Java™ virtual machine (JVM) heap is an independent memory allocation that can reduce the capacity of the main memory heap.

Every integration server creates its own JVM. The integration server uses the JVM to execute the internal administration threads that require Java. This usage is typically minimal. The primary use of the JVM is for the message flow nodes that include the IBM® primitives, user defined extensions, and Java routines that are called from ESQL. You cannot control how much of the JVM heap the IBM primitives use, but you can affect usage of the JVM heap in the Java that is implemented in the following resources:
  • A Java user-defined extension node
  • A JavaCompute node
  • A Java routine that is called from ESQL
  • Mapping notes running a graphical data map
  • XSLTransform node
  • SOAP nodes

The JVM is created with a minimum of 32 MB of space, and a maximum of 256 MB, allocated and reserved for its use. As with any JVM, you can pass parameters in to set the minimum and maximum heap sizes.

You might need to increase the maximum heap size allocated if you plan to run large messages through the Java primitive nodes listed above.

To give more capacity to a message flow that is going to process large messages, reduce the minimum JVM heap size to allow the main memory heap to occupy more address space. For details of how to reduce the minimum JVM heap size, see Setting the JVM heap size.

The key indicators of a successful JVM heap setting are:

  • GC overhead - the percentage of time spent in stop-the-world GC versus the time spent running the application
  • GC pause times - the length of the stop-the-world GC cycles

The requirements on these two values vary according to what you are trying to achieve; for a batch application, a low GC overhead would be important, but pause times might be less relevant. For real-time applications, the pause times are more important than the overall GC overhead.

It is often possible to achieve GC overheads of less than 1 percent and pause times under 1 second (with the exception of compaction cycles). Typically, if the GC overhead is more than 10 percent, it can be reduced by tuning. Pause times of more than 2 seconds are often avoidable, typically by tuning to avoid compaction.

The optimum values for any situation can only be determined by experimenting with values and monitoring the results, because there are so many variables, including the complexity of the message flow and the size of the messages being processed.

You could begin by running a single instance of the message flow using the default heap size, and then increasing the message size and number of instances in a controlled way to their maximum values. Ensure that you make one change at a time. While you are doing this, monitor JVM heap usage and GC activity using resource statistics to ensure that the heap size is sufficiently large to process the largest messages without exceeding the targets for GC overhead and GC pause times. Also ensure that you monitor JVM heap usage on a regular basis, and ensure that the recommended thresholds are not being exceeded.

For more detailed analysis, you can use the Java Health Center, which is available through the IBM Support Assistant.