Advanced Usage of GC Log Analyzer
This section is for users are already familiar with the basic workings of GC Log Analyzer (GC Log Analyzer) and explores how GC Log Analyzer can be used for system analysis and performance management.
Analysis of the JVM Environment Using GC Log Analyzer
The information presented in GC Log Analyzer can be overwhelming. Every system, application and configuration are different so any exact method for performance analysis, and solutions to any issues, are highly subjective. However, there are some data points which can definitely give us an idea of how the system is handling the JVM environment and give us clues to where the problem lies. This section includes some commonly used data points which you can use to help you identify potential issues with your JVM environment, and how you might go about solving those issues.
Using the GC Graphs
System: Load Average and System: Memory Use are the first graphs you should check. They tell you immediately if there is a substantial problem with your application configuration against your system. Load Average tells you how many CPU threads your application is using and Memory Use tells you how much memory is being consumed. Typically, more threads are used during warmup of the application, and you want to see stable memory usage without dips or spikes throughout the run.
GC: GC Time (Percent) tells you how hard the GC is working. If the GC is running at 100% frequently, either your heap is too small or your transaction rate is too low. This can be solved using -Xmx and adjusting -transaction.rate.
Java Heap Use: Committed/Peak/AfterCollection can be used to identify when you don’t have enough memory committed to the Java heap. If you see the Java heap maxing out frequently, or worse, flat-lining at the maximum value, you need to increase the Java heap using -Xmx.
Java Heap: Live Set (Known Live)/(Not Known as Dead) shows data being created and loaded. It’s typical to see a large spike in the beginning during application warmup.
Java Heap: Memory Allocation Rate (Objects) shows how much memory is being consumed by object creation over time. Ideally, you want to see this graph stabilize as quickly as possible.
GC and Safepoint: Pause Duration shows GC pause durations. When GC pause durations are long and frequent, you know there is a problem. Long GC pauses usually indicate stop-the-world GC activity. This can be confirmed by looking at GC and Safepoint: Application Thread Allocation Delayed. If thread allocation looks the same as GC pause duration, you can be sure that stop-the-world GC activity is happening. Stop-the-world GC pauses can be mitigated by increasing -Xmx or by telling the application to do a full GC after reference data is loaded, using -forcegcafterdata true.
Compiler Statistics: Compiler Threads shows the number of threads allocated to the compiler
Compiler Statistics: Tier 1/Tier2 Compile Counts shows the total number of compilations over time