High heap usage
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
JVM heap usage on a node is at or near its configured maximum. Near-cap heap slows search and indexing, increases garbage collection, and raises the chance the node becomes unresponsive or leaves the cluster.
For a complete list of insights, refer to AutoOps insights.
| Field | Value |
|---|---|
| Component | Elasticsearch |
| Severity | Medium |
| Scope | Node |
| Domains | memory, stability |
You can customize these settings to adjust when AutoOps detects this event and presents the insight. Refer to AutoOps event settings for details.
The default customization settings are:
| Setting | Type | Default |
|---|---|---|
| High heap threshold percent | Percentage | 10 |
| Successive samples for high heap | Integer | 3 |
| Search queue threshold | Integer | 5 |
| Search latency threshold (ms) | Integer | 250 |
| Write queue threshold | Integer | 1 |
| Index latency threshold (ms) | Integer | 80 |
Raising these thresholds reduces noise but delays detection. Lowering them triggers the insight sooner but can increase alerts during minor blips.
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.
Heap usage is high on es-data-01 and es-data-02. Heap used: 30. Current max heap size: 500 GB GB.
Indices with high search activity:
logs-prod-000045Indices with high indexing activity:
logs-prod-000045
AutoOps shows different recommendations depending on how their conditions match your deployment or cluster.
Increase heap on node
Condition: Shown when RAM available on node and still abiding heap size rules.
Current max heap is 30 GB. Set JVM heap to 31 GB (suitable for this machine type), then restart the node.
Review query logs
Condition: Shown when cluster version is 9.4 or above.
Review query logs on es-data-01 to find expensive searches that fill the queue. Query logs (Elasticsearch 9.4+) give structured per-query timing with less overhead than search slow logs. See Query logs.
Enable and review search slow logs
Condition: Shown when cluster version is below 9.4.
Enable search slow logs with the action below, then review the slow log to find expensive queries. See Slow logs for configuration details.
PUT logs-prod-000045/_settings{ "index.search.slowlog.threshold.query.warn": "10s", "index.search.slowlog.threshold.query.info": "5s", "index.search.slowlog.threshold.query.debug": "2s", "index.search.slowlog.threshold.query.trace": "500ms", "index.search.slowlog.threshold.fetch.warn": "1s", "index.search.slowlog.threshold.fetch.info": "800ms", "index.search.slowlog.threshold.fetch.debug": "500ms", "index.search.slowlog.threshold.fetch.trace": "200ms" }
Requires the manage index privilege. Requires Elasticsearch 8.0.0 or later. This action changes cluster or index configuration.
Balance old and young GC
Condition: Shown when deployment is Self-managed (CCM).
Set -XX:NewRatio=2 in your JVM options file to tune the ratio between old and young GC, then perform a rolling restart of affected nodes.
Upgrade node hardware
Condition: Shown when configured heap exceeds recommended max on a data node.
This node is under memory pressure. Reduce heap size to less than 31 GB.
Add coordinating node
Condition: Shown when no coordinating node and slow searches/queues/rejections exist.
Add a coordinating-only node to handle client requests and reduce load on data nodes.
Tune circuit breakers
Condition: Always shown for this insight.
Tune circuit breaker limits to prevent out-of-memory errors while allowing legitimate query and aggregation load. Adjust parent, fielddata, and request breaker settings in elasticsearch.yml based on your heap size and workload.
Each Elasticsearch node runs on a JVM with a configured heap size. Heap holds indexing buffers, query state, caches, and other in-process structures. When usage stays near the maximum, the collector works harder and pauses grow.
Sustained high heap can slow search and indexing, trip circuit breakers, and in severe cases make the node unresponsive or disconnect from the cluster. Common drivers include expensive queries, heavy aggregations, large field data, and heap sized too small for the workload.