JVM GC Log Analysis Report

Problem

In production, JVM GC logs are usually raw streams of timestamps, heap changes, and pause events. gc.log* files can record Full GC, Young GC, pause times, and heap usage, but they rarely answer the practical question: was the slowdown caused by GC, what is the risk level, and is the issue more likely an application allocation problem or a JVM tuning problem. This skill turns one or more GC log files into a reviewable analysis package suitable for performance owners, architects, or middleware teams.

How It Works and Boundaries

It starts by checking the available gc.log* files and whether the input is only part of a rotated log set. It then extracts key metrics such as time range, GC count, Full GC count, average/max/P95 pause, long pauses over 200ms, 500ms, and 1s, GC cause distribution, heap occupancy after collection, Metaspace changes, and peak windows. It also forms conclusions, such as whether there is a Full GC storm, frequent Young GC, long-tail pauses, or old-generation pressure, and marks issue items explicitly.

The output can include an HTML report and a Markdown summary, with optional line, pie, or bar charts rendered as self-contained HTML assets. It provides tuning guidance across application-side, JVM-parameter-side, and platform-side factors, rather than only recommending further observation. If only one rotated file is available, the log format is incomplete, or the data is insufficient, the report keeps the section and states the data boundary instead of presenting a partial sample as a full conclusion.