Master JVM GC Log Analysis: A Step‑by‑Step Tuning Guide

This article walks through JVM GC log analysis and tuning, covering monitoring steps, parameter settings, log interpretation, and using the free GCEasy visualizer to identify performance issues and optimize Java applications.

Java Interview Crash Guide
Java Interview Crash Guide
Java Interview Crash Guide
Master JVM GC Log Analysis: A Step‑by‑Step Tuning Guide

2. JVM Tuning Practice

2.1 JVM Tuning Steps

Default strategy is most common but not optimal.

Step 1: Monitor and analyze GC logs

Step 2: Determine JVM issues

If parameters are reasonable, no timeouts, low GC frequency and duration, no optimization needed.

If GC pauses exceed 1‑3 seconds or occur frequently, optimization is required.

Step 3: Define tuning objectives

Step 4: Adjust parameters

Start with memory usage requirements, then latency, finally throughput; each step builds on the previous.

Step 5: Compare before‑and‑after results

Step 6: Repeat steps 1‑5

Find the optimal JVM settings.

Step 7: Apply JVM settings to application servers

Deploy the chosen parameters to all servers and monitor.

These are the basic JVM tuning steps. Let's start with step 1!

2.2 Analyzing GC Logs

2.2.1 Initial Parameter Settings

Machine environment:

CPU: 12 cores, Memory: 16 GB

Cluster: single node

Application version: 1.0

Database: 4 cores, 16 GB

Typical JVM parameters:

-Xms : minimum heap size; heap grows when free memory < 40 % until -Xmx.

-Xmx : maximum heap size; default is total memory/64 (max 1 GB); heap shrinks when free > 70 % down to -Xms.

-Xmn : max size of young generation (Eden + two Survivor spaces), e.g., -Xmn1024k, -Xmn1g.

-Xss : thread stack size, default 1 MB; smaller stacks allow more threads.

The total heap = young + old generation; it does not include Metaspace. Default old/young ratio is roughly 2:1.

In development you can set Xms and Xmx differently, but in production they should be equal to avoid heap size jitter.

Important: usually set Xms and Xmx to the same value!

Enable detailed GC logging:

-XX:+PrintGCDetails – prints detailed GC information.

-XX:+PrintGCTimeStamps and -XX:+PrintGCDateStamps – add timestamps.

-XX:+PrintHeapAtGC – prints heap state at each GC.

-Xloggc:./logs/gc.log – writes GC log to file.

Example IDEA VM options on Windows:

-XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintGCDateStamps -XX:+PrintHeapAtGC -Xloggc:E:/logs/gc-default.log

2.2.2 Interpreting Young GC Logs

2022-08-05T13:45:23.336+0800: 4.866: [GC (Metadata GC Threshold) [PSYoungGen: 136353K->20975K(405504K)] 160049K->48437K(720384K), 0.0092260 secs] [Times: user=0.00 sys=0.02, real=0.02 secs]

Explanation:

Timestamp of the GC event.

Uptime when GC occurred.

GC type (young) and reason (Metadata GC Threshold).

Young generation size before → after (total capacity in parentheses).

Total heap size before → after.

GC pause duration.

CPU time vs. real pause time.

2.2.3 Interpreting Full GC Logs

2022-08-05T20:24:47.815+0800: 6.955: [Full GC (Metadata GC Threshold) [PSYoungGen: 701K->0K(72704K)] [ParOldGen: 38678K->35960K(175104K)] 39380K->35960K(247808K), [Metaspace: 56706K->56706K(1099776K)], 0.1921975 secs] [Times: user=1.03 sys=0.00, real=0.19 secs]

Explanation follows the same pattern, showing a full‑heap collection, Metaspace details, and pause times.

Now we use a GC visualization tool (gceasy.io) to simplify analysis.

2.2.4 GC Visualization with GCEasy

Upload the GC log file to gceasy.io ; the tool generates a report with memory usage, throughput, pause statistics, and GC reasons.

1) JVM Memory Usage

Young Generation: allocated 74.5 MB, peak 74.47 MB

Old Generation: allocated 171 MB, peak 95.62 MB

Metaspace: allocated 1.05 GB, peak 55.38 MB

Total (Young + Old + Metaspace): allocated 1.3 GB, peak 212.64 MB

2) Key Performance Indicators

Throughput: 97.043 % (higher indicates lower GC overhead)

Average GC pause: 7.80 ms

Maximum GC pause: 190 ms

3) GC Visualization Results

The report shows three Full GC events early in the application lifecycle, which is abnormal.

4) GC Statistics

The tool provides total counts of Young and Full GCs, total pause time, and other aggregate metrics.

5) GC Causes

Metadata GC Threshold – 6 occurrences, average 43.3 ms, max 190 ms

Allocation Failure – 53 occurrences, average 3.77 ms, max 10 ms

Ergonomics – automatic balance between pause time and throughput (mentioned for completeness).

Using visualization tools like GCEasy makes GC log analysis fast, free, and much easier to understand.

Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

JavaJVMPerformance Tuninggclog analysis
Java Interview Crash Guide
Written by

Java Interview Crash Guide

Dedicated to sharing Java interview Q&A; follow and reply "java" to receive a free premium Java interview guide.

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.