Setting Heap Memory Size for the Publication and Subscription Servers v6.2

The publication server and the subscription server are configured to run with a default set of heap size parameters. Either the default settings for 32-bit platforms or the default settings for 64-bit platforms are set by parameter JAVA_HEAP_SIZE when xDB Replication Server is installed.

This parameter is configured in the xDB Startup Configuration file. See xDB Startup Configuration File for information on the xDB Startup Configuration file.

The following is an example of the xDB Startup Configuration file.

#!/bin/sh

JAVA_EXECUTABLE_PATH="/usr/bin/java"
JAVA_MINIMUM_VERSION=1.8
JAVA_BITNESS_REQUIRED=64
JAVA_HEAP_SIZE="-Xms256m -Xmx1536m"
PUBPORT=9051
SUBPORT=9052

On a 32-bit system, the initial heap size is set to 128 megabytes (-Xms128m) and the maximum limit is set to 512 megabytes (-Xmx512m). On a 64-bit system the initial heap size is 256 megabytes (-Xms256m) and the maximum limit is 1536 megabytes (-Xmx1536m).

Typically, these values can handle the average workloads. However, depending upon the average row size and pending backlog of replication updates, it may be beneficial to increase the default heap size settings.

The default values can be modified by changing the JAVA_HEAP_SIZE parameter setting in the xDB Startup Configuration file. Be sure to restart the publication server and the subscription server (see Registering a Publication Server and Registering a Subscription Server ) after making such changes.

The heap size value should conform to the available RAM on the host running the publication server or subscription server. The basic guideline is that the maximum heap size should not exceed 25% of the total RAM size.

The following factors should also be considered.

If both the publication server and subscription server are running on the same host, then the minimum and recommended RAM capacity are shown by the following.

  • Minimum RAM Size. For a 32-bit system, use 4 gigabytes; for a 64-bit system use 8 gigabytes.
  • Recommended RAM Size. For a 32-bit system, use 8 gigabytes; for a 64-bit system use 16 gigabytes.

By default, both the publication server and subscription server are started and both are required for single-master replication systems. However if only multi-master replication systems are to be configured and used, then the subscription server is not needed. In such cases, the subscription server should be stopped to avoid redundant use of memory.

If both the publication server and the subscription server are running on the same host, then each server reserves its own heap buffer. Thus, the total heap size for both the publication and subscription servers, obtained by adding the maximum heap size for both servers, should comply with the available RAM on the host.

Tuning heap size and configuration parameters for larger rows

When one or more publication tables contain a large size column, for example, XMLType (Oracle/EPAS data type), it is essential to adjust specific parameters to avoid Out Of Memory errors. The XMLType column is stored in Large Objects (LOBs). The LOB storage maintains content accuracy to the original XML. So it retains and stores all the white spaces present in the XML. This data occupies large space when it is loaded and held in-memory by xDB as part of the replication process.

Tune the following parameters to reduce the data maintained in the memory for XMLType and other large-size columns:

  • Increase HEAP size between 4GB to 8GB depending on the maximum size of large column(4GB for column size below 30MB, 6GB for column size between 30 and 100 BM, and 8GB for column size > 100 MB).
  • Set the configuration parameter txSetMaxSize to a lower value (10 to 50) depending on the average size of row data. For a large column (>100MB), set txSetMaxSize to less than or equal to 5.
  • Set the configuration parameter syncBatchSize to a lower value (4 to 10 (rows)) depending on the size of the column data. For a very large column (>100MB), set syncBatchSize to less than 4.
Note

Higher values of txSetMaxSize and syncBatchSize boost the performance of the replication process; however, increasing it to a relatively larger value might result in an Out of Memory error. These values need to be tuned based on the column size.