Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 15 Next »

Heap memory tuning

Many data objects are created and destroyed in memory while streaming. Therefore, it is recommended to allocate at least 1/2 of server physical memory for Java memory heap. For example, if server RAM is 32 Gb, then it is recommended to allocate 16 Gb with the following settings in file:


Garbage collector tuning

Garbage collector (GC) is an important part of Java VM. When GC is running, it dramatically increases the server load and may stop execution of other tasks; therefore, it is recommended to minimize the number of GC invocations using the following settings in file:

#Disable heuristic rules

#Reduce Old Gen threshold

# Use System.gc() concurrently in CMS

# Disable System.gc() for RMI, for 10000 hours

Concurrent Mark Sweep (CMS) Garbage Collector

The Concurrent Mark Sweep (CMS) collector is designed for applications that prefer shorter garbage collection pauses and can afford to share processor resources with the garbage collector while the application is running. This collector should be considered for any application with a low pause time requirement.

1. Сonfigure CMS GC in the (For example, allocating 24G under memory heap and tuning the NewSize and MaxNewSize parameters to control the new generation’s minimum and maximum size by setting these sizes to be equal. In general, keep the Eden size between one fourth and one third of the maximum heap size.)

# Used CMS GC
-XX:+UseConcMarkSweepGC -Xms24g -Xmx24g -XX:NewSize=6144m -XX:MaxNewSize=6144m

# Log

2. After restarting WCS, we can see the result of the garbage collector in the gc-core.log log file. The output may vary depending on the installed version of Java. For example,

openjdk version "1.8.0_222":

openjdk version "12.0.2":

The Z Garbage Collector

The Z Garbage Collector (ZGC) is a scalable low latency garbage collector for Java 12. ZGC performs all expensive work concurrently, without stopping the execution of application threads for more than 10 milliseconds, which makes it suitable for applications requiring low latency and/or use a very large heap. It should be noted that ZGC requires more processor resources than CMS GC.

Example of installing of ZGC with OpenJDK version 12:

1. Download the latest release of OpenJDK 12 from


2. Extract the archive to folder and move its contents to the working directory:

tar xvf openjdk-12.0.2_linux-x64_bin.tar.gz
mv jdk-12.0.2 /usr/java/jdk-12.0.2

3. Create symbolic links to OpenJDK 12:

ln -sfn /usr/java/jdk-12.0.2 /usr/java/default
ln -sfn /usr/java/default/bin/java /usr/bin/java
ln -sfn /usr/java/default/bin/jstack /usr/bin/jstack
ln -sfn /usr/java/default/bin/jcmd /usr/bin/jcmd
ln -sfn /usr/java/default/bin/jmap /usr/bin/jmap

4. Verify your Java installation:

java --version

openjdk 12.0.2 2019-07-16
OpenJDK Runtime Environment (build 12.0.2+10)
OpenJDK 64-Bit Server VM (build 12.0.2+10, mixed mode, sharing)

5. Install WCS (if required).

6. Tune the (for example, allocating 24G under memory heap):

-XX:+UnlockExperimentalVMOptions -XX:+UseZGC -Xms24g -Xmx24g -XX:+UseLargePages -XX:ZPath=/hugepages

7. Сonfigure ZGC according to the recommendations (the number of memory pages (2048K each) with a margin of a quarter more than that obtained from calculating the memory for heap (1.25 * 24G / 2M)) and add the required parameters in the server startup:

mkdir /hugepages
echo "echo 13051 >/sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages" >>/etc/rc.local
echo "mount -t hugetlbfs -o uid=0 nodev /hugepages" >>/etc/rc.local
chmod +x /etc/rc.d/rc.local
systemctl enable rc-local.service
systemctl restart rc-local.service

8.  After restarting WCS, the gc-core.log log files show the periodic operation of the garbage collector. To understand the working model of Z Garbage Collector, you can see this presentation.

  • No labels