Opsian report help

This guide contains some additional help for Opsian reports.

Report warnings

Samples in the JVM

This warning is generated when significant report samples are in non-Java code. To identify the source of these it is worth checking your GC logs or MBeans to evaluate whether there is potentially a GC-related performance issue.


Samples in the GC

This warning is generated when significant report samples are in the JVM collecting garbage. To identify the source of these it is worth checking your GC logs or MBeans to evaluate whether there is potentially a GC-related performance issue.


Samples that were not walkable

This warning is generated when there are significant report samples where Opsian was unable to determine a call trace. This can happen where a significant amount of time is spent in special JVM methods such as System.arraycopy().


Samples in a Safepoint

This warning is generated when there are significant report samples where the JVM was inside a safepoint. To identify the source of these it is worth checking your GC logs or MBeans to evaluate whether there is potentially a GC-related performance issue. If running on Java 9 on or above, enabling safepoints in your unified logs can help identify the cause of excessive time spent in safepoints that aren't GC.


Classload event disabled

The JVMTI classload event has been disabled which prevents Opsian from profiling. For information on how to enable this event please contact support@opsian.com


Low samples

We recommend reports are based on a minimum of 1,000 samples. Try running the report over a longer time period. The system being profiled may also be under insufficient load.


Health checks

This section covers the pre-configured health checks in Opsian's System & JVM diagnostics functionality. If you have any questions around these checks or want some advice on remedies then don't hestitate to can contact Opsian support.


System.gc() triggered collections

This check looks for Garbage Collections that were triggered by calls to the System.gc() method from application code. The use of this method is heavily discouraged as it is unnecessary with modern Garbage Collectors. The default behaviour for the G1 collector is to trigger a full stop-the-world collection and this can lead to unwanted multi-second pause durations on medium to large heaps.

We recommend using the JVM parameter -XX:-DisableExplicitGC to disable calls to System.gc() from causing a collection if this check fails.


Metaspace-triggered collections

The Metaspace is an area of memory used by the JVM to store class metadata. As of Java 8 it replaces PermGen. It contains entries that are allocated or released depending on whether there are still classes present in the JVM heap that require them. A garbage collection of the JVM heap will potentially result in some classes no longer being needed and their metaspace entries being released.

It is usual for applications at startup to encounter metaspace triggered collections. This check triggers when there are metaspace triggered collections detected after application startup. The first step to fixing the underlying issue identified by this check is to determine if there are any JVM parameters that might attempting to tune the metaspace by limiting size, expansion or free ratio (e.g -XX:MaxMetaspaceSize, -XX:MaxMetaspaceExpansion, -XX:MinMetaspaceFreeRatio and -XX:MaxMetaspaceFreeRatio). If those parameters are present and removed, this may be sufficient.

If metaspace-triggered collections persist then Opsian support can advise on additional parameters for tuning the metaspace thresholds based on the steady-state performance of your application in production.


Percent of time spent in GC pauses

This check compares the ratio of time the application has spent in it's own code with that of time spent paused inside the JVM. The primary cause of time spent paused is normally Garbage Collection and this can be determined by inspecting the number and size of collections on the System & JVM diagnostics overview. If there are only small or infrequent collections then the pause times may be due to other JVM machinery. Either way Opsian support will be able to provide further diagnosis and a recommended fix.


Max pause durations

This check triggers when an excessive pause is detected, by default 1000ms. Long garbage collector pauses can hurt user experience in user-facing services and can cause knock-on performance issues for downstream consumers in backend services. There are many ways long pause times can be addressed, from tuning heap sizing to reducing allocation itself. Opsian support will be able to provide further diagnosis and a recommended fix.