How to Analyze Java Garbage Collection Logs

Java garbage collection tuning is probably one of the fastest and least costly ways of improving Java application performance. But you can’t make good decisions without good information. How do you gain insights into how your Java GC is performing? Where does the information come from?

In this article, we’ll look at how to gather information to support your performance tuning decisions, and monitor their success.

What Information Do You Need?

Firstly, you need to understand what GC is, how it works and what the related terminology actually means. This article, What is Java Garbage Collection, is an excellent starting point for anyone new to GC concepts.

Secondly, you need to understand GC key performance indicators (KPI). These include:

• Throughput: The percentage of CPU time dedicated to application tasks as opposed to GC tasks;

• Latency: The period when application threads are paused waiting for GC tasks to complete. Average and maximum latency are both important when performance tuning;

• Footprint: Resources such as CPU time and memory used by GC.

Thirdly, before you begin performance tuning, you’ll need answers to questions such as:

• How often are minor and major GC events running?

• What triggered them? GC triggers include:

  • Allocation failure (no free memory to create new objects);

  • Evacuation pause: moving objects from one space to another;

  • Class unloading;

  • Explicit GC: instigated by the application program;

  • Humongous object collection: tidying up very large objects.

• How long are the events taking?

• How long are GC pauses?

• How much memory was used and reclaimed by GC in each heap space?

Where do you Obtain Java Garbage Collection Analytics?

JDK tools such as jvisualvm, jstat and jcmd can provide a certain amount of information about GC activities, but the primary source of information is the GC logs. You can request GC logging by using command line switches when invoking the JVM. <gc-log-file-path> should be replaced with the actual path to your log file.

• For Java 8 and earlier, the switch is: -XX:+PrintGCDetails -Xloggc:<gc-log-file-path>

• For Java 9 and later, the switch is: -Xlog:gc*:file=<gc-log-file-path>

How Do You Analyze Java GC Logs?

GC logs are produced as text files, and theoretically you could analyze them manually. However, there are two problems with this:

• For long-running programs, GC logs are likely to be thousands of lines long;

• The format of the log differs, depending on the GC algorithm and JVM version. There are at least 30 different log file formats, none of which are intuitive to read.

Here’s an example of a section of a log file.

Fig: Example of Java Garbage Collection Log

It contains lots of meaningful information, but would take many hours to analyze. If you’d like to know more about the actual format of the logs, this Step-by-Step Guide to GC Logs is very helpful.

What’s the Best Way to Analyze GC Logs?

By far the best way to get meaningful information from the logs is to use a specialized tool. Both IBM and Eclipse have log analysis applications available, but the most comprehensive and useful tool is probably GCeasy. You can submit your logs, and within minutes, you’ll receive tuning recommendations, graphs, charts and performance insights.

Let’s have a look at some of the information it produces.

1. Tuning Recommendations

The program uses AI to make specific recommendations based on the content of the logs. See below for an example.

Fig: GCeasy Tuning Recommendations

2. Memory Usage

GCeasy analyzes memory allocation and peak usage in each portion of runtime memory.

Fig: GCeasy Memory Analysis

3. Key Performance Indicators

GCeasy calculates key performance indicators from the logs, and shows the results like this:

Fig: GCeasy Key Performance Indicators

4. GC Frequency and Effect on the Heap

This GCeasy graph shows when GC events ran, and their effect on the available space in the heap.

Fig: GC Events and Heap Size

5. GC Event Triggers

The program analyzes the triggers that caused GC events, showing the frequency of each.

Fig: GC Event Triggers

These are just a sample of the information produced by GCeasy. As you can see, it provides the answers you need when performance tuning.

Conclusion

Analyzing Java Garbage Collection logs manually is a mammoth task.

With a good understanding of GC principles, and tools such as GCeasy, the logs become a valuable source of information for performance tuning and troubleshooting.