Replicators are implemented as Java processes, which use two types of memory: stack space, which is allocated per running thread and holds objects that are allocated within individual execution stack frames, and heap memory, which is where objects that persist across individual method calls live. Stack space is rarely a problem for Tungsten as replicators rarely run more than 200 threads and use limited recursion. The Java defaults are almost always sufficient. Heap memory on the other hand runs out if the replicator has too many transactions in memory at once. This results in the dreaded Java OutOfMemory exception, which causes the replicator to stop operating. When this happens you need to look at tuning the replicator memory size.
To understand replicator memory usage, we need to look into how replicators work internally. Replicators use a "pipeline" model of execution that streams transactions through 1 or more concurrently executing stages. As you can can see from the attached diagram, an Applier pipeline might have a stage to read transactions from the Extractor and put them in the THL, a stage to read them back out of the THL into an in-memory queue, and a stage to apply those transactions to the Target. This model ensures high performance as the stages work independently. This streaming model is quite efficient and normally permits Tungsten to transfer even exceedingly large transactions, as the replicator breaks them up into smaller pieces called transaction fragments.
The pipeline model has consequences for memory management. First of all, replicators are doing many things at one, hence need enough memory to hold all current objects. Second, the replicator works fastest if the in-memory queues between stages are large enough that they do not ever become empty. This keeps delays in upstream processing from delaying things at the end of the pipeline. Also, it allows replicators to make use of block commit. Block commit is an important performance optimization in which stages try to commit many transactions at once on Targets to amortize the cost of commit. In block commit the end stage continues to commit transactions until it either runs out of work (i.e., the upstream queue becomes empty) or it hits the block commit limit. Larger upstream queues help keep the end stage from running out of work, hence increase efficiency.
Bearing this in mind, we can alter replicator behavior in a number of ways to make it use less memory or to handle larger amounts of traffic without getting a Java OutOfMemory error. You should look at each of these when tuning memory:
wrapper.conf. This controls the amount of heap
memory available to replicators. 1024 MB is the minimum setting for most
replicators. Busy replicators, those that have multiple services, or
replicators that use parallel apply should consider using 2048 MB
instead. If you get a Java OutOfMemory exception, you should first try
raising the current setting to a higher value. This is usually enough to
get past most memory-related problems. You can set this at installation
time as the
in the replicator properties file. This controls two things, the size of
in-memory queues in the replicator as well as the block commit size. If
you still have problems after increasing the heap size, try reducing
this value. It reduces the number of objects simultaneously stored on
the Java heap. A value of 2 is a good setting to try to get around
temporary problems. This can be set at installation time as the
the replicator properties file. This parameter sets the block commit
count in the final stage in the Applier pipeline. If you reduce the global
buffer size, it is a good idea to set this to a fixed size, such as 10,
to avoid reducing the block commit effect too much. Very low block
commit values in this stage can cut update rates on Targets by 50% or
more in some cases. This is available at installation time as the
replicator.properties file. This parameter
controls the size of fragments for long transactions. Tungsten
automatically breaks up long transactions into fragments. This parameter
controls the number of bytes of binlog per transaction fragment. You can
try making this value smaller to reduce overall memory usage if many
transactions are simultaneously present. Normally however this value has
Finally, it is worth mentioning that the main cause of out-of-memory conditions in replicators is large transactions. In particular, Tungsten cannot fragment individual statements or row changes, so changes to very large column values can also result in OutOfMemory conditions. For now the best approach is to raise memory, as described above, and change your application to avoid such transactions.
The replicator commits changes read from the THL and commits these changes
in Targets during the applier stage according to the block commit size or
interval. These replace the single
parameter that controls the size of the buffers used within each stage of
When applying transactions to the database, the decision to commit a block of transactions is controlled by two parameters:
The default operation is for block commits to take place based on the transaction count. Commits by the timer are disabled. The default block commit size is 10 transactions from the incoming stream of THL data; the block commit interval is zero (0), which indicates that the interval is disabled.
When both parameters are configured, block commit occurs when either value limit is reached. For example,if the event count is set to 10 and the commit interval to 50s, events will be committed by the applier either when the event count hits 10 or every 50 seconds, whichever is reached first. This means, for example, that even if only one transaction exists, when the 50 seconds is up, that single transaction will be applied.
In addition, the execution of implied commits during specific events within
the replicator can also be controlled to prevent fragmented block commits by
property. This property can have either of the following values:
strict — Commit block on
service name changes, multiple fragments in a transaction, or
unsafe_for_block_commit. This is the default setting.
lax — Don't commit in
any of these cases.
The block commit interval can be controlled using the
option to tpm, or through the
blockCommitInterval. If only a
number is supplied, it is used as the interval in milliseconds. Suffix of s,
m, h, and d for seconds, minutes, hours and days are also supported.
./tools/tpm update alpha \ --repl-svc-applier-block-commit-size=20 \ --repl-svc-applier-block-commit-interval=100s
The block commit parameters are supported only in applier stages; they have no effect in other stages.
Modification of the block commit interval should be made only when the commit window needs to be altered. The setting can be particularly useful in heterogeneous deployments where the nature and behaviour of the target database is different to that of the source extractor.
For example, when replicating to Oracle, reducing the number of transactions within commits reduces the locks and overheads:
./tools/tpm update alpha \ --repl-svc-applier-block-commit-interval=500
This would apply two commits every second, regardless of the block commit size.
When replicating to a data warehouse engine, particularly when using batch loading, such as Redshift, Vertica and Hadoop, larger block commit sizes and intervals may improve performance during the batch loading process:
./tools/tpm update alpha \ --repl-svc-applier-block-commit-size=100000 \ --repl-svc-applier-block-commit-interval=60s
This sets a large block commit size and interval enabling large batch loading.