GARBAGE COLLECTION AND PERFORMANCE TUNING

For all the tests referred to in this book the JVM garbage collection option used was: -XX:+UseParallelOldGC. Many people choose the Concurrent Mark and Sweep (CMS) collector, collection is slower on both the Eden space and Old generation. The following graph shows the difference between using the throughput collector with parallel collection on the Old generation in comparison to using the CMS collector, which works on the Old generation and parallel collection on the Eden space.

Figure 9.5. Transactional OLTP Workload

The difference in performance between the Parallel Garbage Collector and the Concurrent Mark and Sweep Garbage collector can be explained by their underlying design. If you do not specify the option -XX:+UseParallelOldGC, the throughput collector defaults to parallel collection on the Eden space, and single threaded collection on the Old generation. With a 12GB heap, the Old generation is 8GB in size, which is a lot of memory to garbage collect in a single thread fashion. By specifying that the Old generation should also be collected in parallel, the collection algorithms designed for the highest throughput is used, hence the name "throughput collector". When the option -XX:+UseParallelOldGC is specified it also enables the option -XX:+UseParNewGC. In comparison, the CMS collector is not optimized for throughput but instead for more predictable response times. The focus of this book is tuning for throughput, not response time. The choice of garbage collector depends on whether higher throughput or more predictable response times benefits the application most. For real-time systems, the trade-off is usually lower throughput for more deterministic results in response times.

OTHER JVM OPTIONS TO CONSIDER

This section covers some additional JVM options:

• -XX:+CompressedOops
• -XX:+AggressiveOpts
• -XX:+DoEscapeAnalysis
• -XX:+UseBiasedLocking
• -XX:+EliminateLocks

Warning

When considering the JVM options covered in this section, be aware that their behavior is subject to change depending on the version, therefore the effect of each should be tested before being implemented in a production environment.

Compressed OOPs, covered briefly in Section 9.1, “32-bit vs. 64-bit JVM”, implements a compression of the internal memory pointers within the JVM for objects and so reduces the heap. From JVM revision 1.6.0_20 and above compressed OOPs is on by default but if an earlier revision of the JDK is being used this option should be used for heap sizes 32GB and lower.

Aggressive optimizations, -XX:+AggressiveOpts, enables additional Hotspot JVM optimizations that are not enabled by default. The behavior enabled by this option is subject to change with each JVM release and so its effects should be tested prior to implementing it in production.

The final options are locking based options, -XX:+DoEscapeAnalysis, -XX:+UseBiasedLocking and -XX:+EliminateLocks. They are designed to work together to eliminate locking overhead. Their effect on performance is unpredictable for specific workloads and so require testing prior to being implemented. Reduced locking should improve concurrency and, on current multi-core hardware, improve throughput.

In summary, all these options should be considered on their merits. To accurately judge their impact on performance they should be tested independently of each other

PROFILING

Profiling is monitoring the resource usage of an application with the aim of detecting areas for improvement. One of the difficulties in profiling is choosing a tool which provides useful data without having too great an impact on performance itself. On Red Hat Enterprise Linux, the OProfile tool is available for profiling the JBoss Enterprise Application Platform, requiring less system resources that other profiling tools.

10.1. Install

Task: Install OProfile

Complete this task to install OProfile and its dependencies.

1. In a terminal, enter the following command:

   yum install oprofile oprofile-jit
   

2. For all enabled yum repositories (/etc/yum.repos.d/*.repo), replace enabled=0 with enabled=1 in each file's debuginfo section. If there is no debug section, add it, using the example below as a template.

   [rhel-debuginfo]
   name=Red Hat Enterprise Linux $releasever - $basearch - Debug
   baseurl=ftp://ftp.redhat.com/pub/redhat/linux/enterprise/$releasever/en/os/$basearch/Debuginfo/
   enabled=1
   gpgcheck=1
   gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release
   

3. In a terminal, enter the following command, modifying the JDK version number to match the version installed:

   yum install yum-plugin-auto-update-debug-info java-1.6.0-openjdk-debuginfo