Node near out of memory
Elastic Cloud Hosted lets you manage and configure one or more deployments of the versioned Elastic Stack, hosted on Elastic Cloud. Availability This functionality is generally available and ready for production usage. Elastic Cloud on Kubernetes extends Kubernetes orchestration capabilities to allow you to deploy and manage components of the Elastic Stack. Availability This functionality is generally available and ready for production usage. This documentation corresponds to the latest patch available for each minor version. If you're not using the latest patch, check the release notes for changes. Elastic Cloud Enterprise is a self-managed orchestration platform for deploying and managing the Elastic Stack at scale. Availability This functionality is generally available and ready for production usage. This documentation corresponds to the latest patch available for each minor version. If you're not using the latest patch, check the release notes for changes. Self-managed deployments are Elastic Stack deployments managed without the assistance of an orchestrator. Availability This functionality is generally available and ready for production usage. This documentation corresponds to the latest patch available for each minor version. If you're not using the latest patch, check the release notes for changes.
ECH
Generally available
ECK
Generally available
ECE
Generally available
Self-managed
Generally available
A node is under severe JVM memory pressure: heap use stays very high while garbage collection consumes much of the time. The node might slow down, reject work, or disconnect from the cluster.
For a complete list of insights, refer to AutoOps insights.
| Field | Value |
|---|---|
| Component | Elasticsearch |
| Severity | High |
| Scope | Node |
| Domains | performance, memory, stability |
The following is an example of what you might see when this insight is triggered. Real insights use live data and links from your deployment or cluster.
High GC overhead on es-data-01 and es-data-02. Heap utilization is 30%. GC ran for more than 50% of the time over the last 30 seconds.
AutoOps shows different recommendations depending on how their conditions match your deployment or cluster.
Restart es-data-01 node
Condition: Always shown for this insight.
Restart the es-data-01 node to clear abnormal load and recover normal operation.
When heap stays near full and collectors run most of the time, the JVM spends capacity reclaiming memory instead of serving search and indexing. Pause times grow, thread pools back up, and the node can become unresponsive or leave the cluster.
Typical drivers include heap sized too small for the workload, expensive queries and aggregations, large field data, shard over-allocation, and concurrent heavy operations. Sustained pressure raises the risk of out-of-memory failures and cluster instability.