Tomcat heap usage: watch the post-GC baseline, not the sawtooth peak

Every JVM heap graph looks the same: a jagged sawtooth that climbs steadily, drops sharply, and repeats. If you alert on “heap > 80%”, you will page on every pre-GC peak. That alert fires dozens of times per hour on a healthy Tomcat, training your team to ignore heap warnings until a real OutOfMemoryError arrives and nobody saw it coming.

The heap is designed to fill between garbage collection cycles. High instantaneous usage is normal. The signal that matters is the valley after each collection: the post-GC baseline. When that baseline is stable, your live data set is bounded. When it rises over hours or days, live data is accumulating and a leak is underway.

What it is and why it matters

The JVM heap is a bounded memory region where application objects live until the garbage collector reclaims them. In a generational collector (Parallel, G1, CMS, ZGC, Shenandoah), newly allocated objects go into Eden. As Eden fills, a minor GC runs, sweeping dead objects and promoting survivors to old generation. Objects that survive long enough end up in old gen and stay there until a major collection runs.

Because allocation is continuous and collection is periodic, heap usage between collections climbs steadily. On a graph, this produces the characteristic sawtooth: usage rises as objects are allocated, then drops sharply when GC runs. The low point of each tooth is the post-GC baseline.

The post-GC baseline represents your live data set: objects that are still reachable and cannot be collected. Sessions, cached data, in-flight request objects, application singletons. When the live data set is stable, the sawtooth valleys stay at roughly the same level. When it is growing, the valleys climb.

Instantaneous heap usage tells you nothing useful for leak detection. A heap at 85% of max might have 80% garbage that the next young GC will reclaim in milliseconds. The same 85% might have 80% live data that no collection can touch. Without knowing whether that 85% is a pre-GC peak or a post-GC valley, you cannot tell the difference.

How it works

flowchart TD
    A["Eden fills with new objects"] --> B["Young GC runs"]
    B --> C["Dead objects reclaimed"]
    C --> D["Survivors promoted to old gen"]
    D --> E{"Old gen post-GC baseline"}
    E -->|"Stable across cycles"| F["Healthy: live data bounded"]
    E -->|"Rising over hours"| G["Memory leak in progress"]
    G --> H["GC frequency increases"]
    H --> I["Latency spikes, throughput drops"]
    I --> J["OOM or GC death spiral"]

The diagnostic question is never “how full is the heap right now?” It is always “what does the heap look like immediately after a collection, and is that number trending up?”

To answer that, you need one of three signals: GC log output with pre- and post-collection values, jstat showing old generation utilization, or a monitoring system that samples at GC boundaries.

GC logs. On Java 9+, enable unified JVM logging with -Xlog:gc*:file=/var/log/tomcat/gc.log:time,uptime:filecount=5,filesize=10M. On Java 8, use -XX:+PrintGCDetails -Xloggc:/var/log/tomcat/gc.log. Each GC event logs the heap state before and after the collection. The “after” value is your post-GC baseline. Trending that value over hours or days is the most direct leak detection method available.

jstat. jstat -gcutil <pid> 1000 prints per-generation utilization every second. The columns are S0, S1, E (Eden), O (old gen percentage), M (Metaspace percentage), CCS, YGC, YGCT, FGC, FGCT, GCT. The O column is old generation utilization as a percentage of old gen capacity. Old gen is where long-lived objects accumulate, so O is the best single-column proxy for post-GC baseline drift. jstat reads JVM internals without triggering collections or stopping the world. Run it as the same user that owns the JVM process, or with equivalent attach permissions.

# Watch old gen utilization percentage every second.
# If multiple Tomcat instances run, specify the PID explicitly.
jstat -gcutil $(pgrep -f 'catalina.startup.Bootstrap') 1000

Manager Status XML. The Tomcat Manager app exposes /manager/status?XML=true, which returns <jvm><memory free="..." total="..." max="..."/></jvm>. This is an instantaneous snapshot of the whole heap. It does not correlate with GC events, so you cannot determine the post-GC baseline from it alone. If you are scraping the Manager XML for heap monitoring, you are seeing the sawtooth, not the valleys.

The Manager endpoint also reports total (committed heap) and max (maximum heap). These differ when -Xms is less than -Xmx. The JVM grows the committed region on demand. If you compute “heap used / max” but only have free and total from the XML, you are computing used / committed, not used / max. That ratio is more volatile and will mislead you.

Where it shows up in production

The false-positive problem is most acute with monitoring setups that scrape JMX or Manager XML on a fixed interval and alert on a percentage threshold. The scraper has no idea where in the GC cycle the heap is, so it catches pre-GC peaks constantly.

The 80% threshold trap. Many heap monitoring guides recommend alerting when heap exceeds 80% of max. On a Tomcat with -Xmx2g and a healthy allocation rate, the heap will spend most of its time between 60% and 85% as Eden fills between young GCs. An instantaneous “heap > 80%” alert will fire on every cycle. Operators either silence the alert, missing real leaks, or widen the threshold until it never fires, also missing real leaks.

G1GC and shallower valleys. Since Java 9, G1 is the default collector. G1 performs mixed GC pauses that reclaim young and selected old gen regions together, following a concurrent marking cycle. The post-GC baseline may not drop as sharply as it does with Parallel GC’s compacting full collections. The valleys are real but shallower. Operators who learned heap monitoring on Parallel GC may misread G1’s flatter sawtooth as “GC is not reclaiming memory.” With G1, any Full GC (as opposed to a mixed collection pause) is a red flag. In most cases it means concurrent collection failed to keep up (concurrent mode failure or an evacuation/allocation failure), but a Full GC can also be triggered by an explicit System.gc() call, a JNI critical section (GCLocker-initiated GC), or a humongous allocation failure - so check the GC cause in the log rather than assuming routine behavior.

Container limits. In Kubernetes or containerized deployments, the cgroup memory limit may be lower than -Xmx. The JVM detects the cgroup limit (with -XX:+UseContainerSupport, default since Java 10) and may set max heap accordingly. If the limit is misconfigured, the OS OOM killer can terminate the JVM before any Java-level OOM fires. The kernel kills on RSS, not heap. Monitor both.

Metaspace is not heap. Classloader leaks fill Metaspace, not the heap. The heap sawtooth looks perfectly healthy while Metaspace grows monotonically across redeploys until OutOfMemoryError: Metaspace kills the process. If MaxMetaspaceSize is not set, there is no JVM-level OOM, just a silent OS kill. Metaspace monitoring is a separate concern from heap baseline tracking, but both matter.

Common misuses

Pattern	What happens	What to do instead
Alert on instantaneous heap > 80%	Constant false positives from pre-GC peaks	Alert on post-GC baseline trending up over hours
Use Manager XML `free` as the heap signal	Sawtooth noise, no GC correlation	Use `jstat -gcutil` O column or GC log post-GC values
Single threshold without baseline	One-size-fits-all misses workload patterns	Establish per-deployment post-GC baseline, alert on deviation
Watch heap only, ignore Metaspace	OOM: Metaspace kills process with heap looking fine	Monitor Metaspace separately, set `-XX:MaxMetaspaceSize`
Treat G1 Full GC as routine	G1 Full GC usually means concurrent collection failed, but explicit `System.gc()`, GCLocker (JNI critical section), or humongous allocation failure can also trigger it	Any G1 Full GC warrants investigation; check the GC cause
Alert on committed/total instead of used/max	Ratio shifts as JVM grows committed region	Use `used / max`, not `used / committed`

Signals to watch in production

Signal	Why it matters	Warning sign
Post-GC old gen utilization (jstat O column)	Old gen is where long-lived objects accumulate	O trending upward over hours despite normal GC frequency
Post-GC heap from GC logs	Direct measurement of live data after each collection	Post-GC value rising across collection cycles
Full GC frequency	Full GC in G1 means concurrent collection failed	Any Full GC; multiple per minute is a crisis
GC overhead ratio (GC time / wall clock)	Measures how much CPU GC is consuming	Over 5% sustained is concerning, over 20% is a death spiral
Active session count	Sessions are a primary heap consumer	Growing monotonically without plateau
Process RSS vs container limit	Kernel kills on RSS, not heap	RSS approaching cgroup limit
Old gen post-GC vs max old gen	Direct leak indicator independent of young gen noise	Post-GC old gen over 80% of old gen max, trending up

How Netdata helps

Netdata’s Java collector scrapes JMX memory and GC beans at per-second resolution, so the sawtooth is visible in full detail rather than aliased away by coarse polling intervals.
Correlating the heap utilization chart with the GC collection time chart on the same dashboard lets you identify post-GC valleys without parsing logs manually.
ML-based anomaly detection flags deviations from the established post-GC baseline pattern, surfacing rising valleys before they cross a fixed threshold.
Per-pool breakdowns (Eden, Survivor, Old Gen, Metaspace) make old gen drift visible separately from young gen noise.
GC collection count and time charts make it immediately clear when GC frequency is increasing, which is the companion signal to rising post-GC baselines.