Blog
March 28, 2018
Why G1GC is the Best Choice for Garbage Collection in ActiveMQ
Web Infrastructure,
Middleware
Need to do JVM garbage collection in ActiveMQ? In this blog, we discuss potential options, why G1GC garbage collection is the best choice for ActiveMQ, and how to get started on your deployment.
- What Is G1GC?
- Why Not Use JVM Garbage Collection?
- Tips For G1GC Garbage Collection in ActiveMQ
- How G1GC Works
- How Do I Enable G1GC?
- Get Started With G1GC and ActiveMQ
What Is G1GC?
G1GC is a low-latency garbage collection algorithm.
G1GC lends itself to shorter individual garbage collection cycles. This reduces the duration of “stop-the-world” collections. And it therefore reduces the probability of disruption of message delivery.
Why Not Use JVM Garbage Collection?
Java has standard JVM garbage collection settings. But this doesn't work well for ActiveMQ.
In general, it is recommended that a Java application’s JVM garbage collection settings be left alone. The JVM in most cases does a good job of selecting proper garbage collection algorithms. And tweaking this configuration turns off the automatic cleaning ergonomics. This can result in decreased or sub-optimal garbage collection performance.
A Java message oriented middleware solution like ActiveMQ is always the exception to this rule. Message Oriented Middleware tends to create many small, short-lived objects inside the JVM. This means that most objects will reside in the JVM heap’s “New” or “Eden” area of memory. The potential for memory fragmentation increases significantly. The specific behavior of Message Oriented Middleware lends itself to different object patterns and behavior than seen in other Java applications.
That's why Garbage-First Garbage Collector (G1GC) is the best choice for ActiveMQ.
Tips For G1GC Garbage Collection in ActiveMQ
First, reducing the duration of a garbage collection pause can mean the difference between a buggy and unstable message delivery system and a solid, long-running one. With so many messages coming in and out of the broker, especially in a high-frequency messaging environment, even short disruptions can cause message backlog. The point of ActiveMQ is to be a stable and fast mechanism for moving data around an infrastructure, and it should never be the bottleneck to this work.
Second, the memory usage of the broker itself should be consistent, avoiding fragmentation and therefore reducing the probability of an out-of-memory condition, so that a broker can run for months or even years at a time without interruption.
How G1GC Works
G1GC helps to accomplish these goals by partitioning the JVM heap into segments — or “buckets” as they are often called — of like objects.
Partitioning the heap this way allows for several efficiency optimizations:
- The garbage collector can correlate similar objects into the same area of memory, and choose either parallel or concurrent mark-sweep garbage collection based on current object behavior.
- Segments in memory with the most object waste can be cleaned up first, allowing even an incomplete garbage collection run to clean up as many disposable objects as possible.
- Heap memory fragmentation can be isolated and compacted in segments rather than compacting the entire heap.
- An exact number for the garbage collection pause can be specified, ensuring the shortest possible span of broker downtime during a parallel garbage collection.
How Do I Enable G1GC?
G1GC is very easy to enable. The “-XX:+UseG1GC” parameter can be added to the ACTIVEMQ_OPTS or ACTIVEMQ_OPTS_MEMORY variables in the /bin/activemq launch script.
A number of additional tuning parameters are available to you which will allow explicit control over:
- The exact amount of time that the collector spends cleaning during each cycle.
- The size of various areas in the heap.
- The number of individual object buckets that are created.
Note: JDK 1.7_14 or later is recommended if you wish to use G1GC. JDK <= 1.6 does not provide G1GC, and the functionality was considered experimental until JDK 1.7_14. Always use the newest JDK available to you in the desired major release to ensure the greatest possible efficiency, performance, and security.
Once you’ve turned on G1GC, a number of JMX mBeans are available to you which can help you monitor garbage collection behavior to ensure that it is performing as desired. These mBeans can be found under java.lang.GarbageCollector and java.lang.Memory in the JMX tree:
In the picture, you can see the attributes specific to the G1GC garbage collector. Important mBeans here include:
| G1GC Attribute | Definition |
|---|---|
| LastGCInfo | A Composite Data structure with values including: GcThreadCount – Total number of threads used in the GC. |
| CollectionCount | The total number of GCs performed since the broker started. |
| CollectionTime | The total amount of time spent garbage collecting. |
These are broken out into G1 Young Generation and G1 Old Generation categories. So, you can look at statistics from garbage collection in both the New and Old areas of memory.
In addition to using JMX, you can also use the Visual GC plugin for JVisualVM, which comes with your JDK. JVisualVM can be launched from the “/bin” directory of your JDK installation, and provides a nice visual of memory management within the JVM, as well as a set of tools such as a live thread analyzer, a memory and CPU sampler, and a lightweight application profiler.
From the Tools -> Plugins menu, you can install the Visual GC plugin:
Which can be used to provide a visual overview of garbage collection behavior in the JVM, including the total duration of GC Time, the total number of collections, and the amount of memory in each area of the JVM Heap:
Get Started With G1GC and ActiveMQ
The G1GC garbage collection algorithm has consistently proven to be the best choice for ActiveMQ. By categorizing objects into buckets and cleaning up as much waste as possible, G1GC can adapt itself well to a message environment with both high and low message volume, and with messages of varying sizes. Because G1GC allows explicit control over its behavior, you can tune it to work around the precise nature of your messaging system.
G1GC and ActiveMQ are great tools. But to get the most out of them, you might need a little help. Luckily, you can enlist the help of open source architects at OpenLogic by Perforce.
Get in touch with one of our experts today and drive your business forward with ActiveMQ support.