JVM monitoring in Application Real-Time Monitoring Service (ARMS) charts memory metrics over time, but these charts alone cannot diagnose issues such as memory leaks or memory bloat. A memory snapshot captures the full heap state of a running JVM instance at a specific point in time, providing the object-level detail needed to identify root causes. We recommend that you generate memory snapshots and analyze the detailed memory usage data in the logs.
Prerequisites
Before you begin, ensure that you have:
An ARMS agent for Java V2.7.1.2 or later, released after September 24, 2021
A Linux server (only Linux servers support memory snapshots)
The AliyunARMSFullAccess permission granted to your Resource Access Management (RAM) user
Create a memory snapshot
A heap dump suspends the application process. The operation typically takes a few minutes but can take up to half an hour. Proceed with caution in production environments.
Log on to the ARMS console. In the left-side navigation pane, choose Application Monitoring > Application List.
On the Application List page, select a region in the top navigation bar and click the name of your application.
Icons in the Language column indicate the programming language: -
: Java - 
: Go - 
: Python - - (hyphen): an application monitored by Managed Service for OpenTelemetryIn the left-side navigation pane, click Application Details. On the page that appears, click the JVM monitoring tab.
In the upper-right corner of the JVM monitoring tab, click Create Memory Snapshot.
In the Create Memory Snapshot dialog box, select an IP address from the IP drop-down list and click Save.
If you already selected an instance in the navigation tree on the Application Details page, the IP address is automatically populated.
In the confirmation message, click Force to dump.
View and analyze snapshot results
In the upper-right corner of the JVM monitoring tab, click Historical Snapshots. The Number of Snapshot Jobs panel shows the status of each snapshot task: To check the progress of a specific task, find the task and click Details.
Color Status Green Successful Blue In progress Red Failed Find a task and click Analysis to open the results in the Application Troubleshooting Platform (ATP) console.
Heap dump impact
Memory snapshots use the built-in JVM heap dump mechanism (jmap -dump:all). Heap dumps may consume additional memory, trigger safe points and garbage collection (GC) cycles, and suspend all non-JVM threads. This suspension cannot be interrupted.
Carefully evaluate the risks before taking a snapshot in a production environment.
ARMS agent version compatibility
The memory snapshot feature depends on your ARMS agent version:
| ARMS agent version | Supported environments | Dependencies | Notes |
|---|---|---|---|
| V2.7.3.5 and earlier | Does not support JRE, Java 11, or Alpine Linux | JAVA_HOME environment variable and JAVA_HOME/lib/tools.jar | Limited compatibility |
| V2.8.3 to V3.2.8 | JRE, Java 8, Java 11, and Alpine Linux | JAVA_HOME environment variable and Java commands. Add $JAVA_HOME/bin to PATH | Broader compatibility |
| V3.2.9 and later | — | No need to add $JAVA_HOME/bin to PATH | Recommended version. To upgrade, see Update the ARMS agent |
Object Storage Service (OSS) bucket access
ARMS uploads snapshot data to an Object Storage Service (OSS) bucket for storage and processing. If the VPC where your application runs is configured with a limit on the number of OSS buckets that can be accessed, add the snapshot bucket to your access policy. The bucket name follows this format:
arms-heapdump-<regionId>Replace <regionId> with your region ID. For example, if your application runs in the China (Hangzhou) region, the bucket name is arms-heapdump-cn-hangzhou.
Without access to this OSS bucket, snapshot data cannot be collected.
Snapshot retention
Before July 1, 2023, ARMS retained historical snapshots indefinitely. Starting July 1, 2023, ARMS imposes a 90-day retention limit on historical snapshots, which means you cannot save memory snapshots created more than 90 days ago. Back up snapshots regularly to avoid data loss.
FAQ
Why can't snapshots be automatically created and analyzed before an out-of-memory (OOM) error?
When an application nears an OOM state, system resources are critically strained. A heap dump is resource-intensive and may itself trigger the OOM error during this period.
Instead, configure the JVM to capture a heap dump automatically when the OOM error occurs:
-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp/heap.binThese flags instruct the JVM to write a heap dump to /tmp/heap.bin on OOM.
In Kubernetes environments, map /tmp/heap.bin to a persistent storage volume to prevent data loss from pod restarts.
After the OOM occurs:
Upload the heap dump file to an OSS bucket. For details, see Get started with OSS.
Analyze the heap dump in the ATP console.