New Relic APM JVM Heap Growth: Confirming a Leak Without Worsening Memory Pressure

New Relic APM's JVM overview surfaces heap used/committed, GC pause time, and GC count as the primary signals for a suspected memory leak. The Java agent samples these metrics on an interval and does not capture object-level detail, so heap trends alone cannot confirm whether growth originates from the application or from agent-side retention such as transaction trace and event sample limits.

Continuous Profiling can expose allocation hotspots that indicate leaks, but enabling it on a JVM already showing sustained heap growth introduces instrumentation overhead that may worsen latency or trigger OOM. The unresolved decision is whether to lower the profiler sampling interval to catch short-lived allocations or raise it to minimize overhead on a pressured process. Agent configuration keys, defaults, and feature names also vary by agent version, adding uncertainty to any tuning choice.

Given these constraints, what is the safest diagnostic sequence for confirming a leak using New Relic APM data before enabling continuous profiling in production? How should the profiler sampling interval be selected when the JVM is already under memory pressure? Which agent-side sample limits should be reviewed first to rule out agent-induced retention?