Heap size above recommended max
The JVM heap on a node is configured at or above the compressed ordinary object pointers (COOPs) threshold (about 26 to 30 GB on most systems). Above that range, COOPs might be turned off and heap efficiency drops, which hurts node performance.
For a complete list of insights, refer to AutoOps insights.
| Field | Value |
|---|---|
| Component | Elasticsearch |
| Severity | Medium |
| 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.
Node es-data-01 has heap size configured to 30.
AutoOps shows different recommendations depending on how their conditions match your deployment or cluster.
Tune JVM heap below the COOPs limit
Condition: Always shown for this insight.
Configured heap on instance-00001 is at or above the compressed ordinary object pointers (COOPs) threshold. Lower -Xmx to the sweet spot below that limit for your hardware (typically under 26–30.5 GB) so COOPs stay enabled and this insight clears. Use the action below after each change, and stop when using_compressed_ordinary_object_pointers is true.
For es-data-01 nodes, also stay within about 60% of available RAM, capped at the COOPs limit.
GET _nodes/jvm?filter_path=nodes.*.jvm.using_compressed_ordinary_object_pointers
Requires the manage cluster privilege. Requires Elasticsearch 8.0.0 or later. This action is read-only.
JVM heap size is set with environment variables or jvm.options. On data nodes, heap is typically at most about half of available RAM so the operating system and file-system cache still have room.
Past a system-dependent limit around 26 to 30 GB, the JVM might stop using compressed ordinary object pointers. Pointers grow and heap efficiency drops, so larger heaps past that threshold often perform worse rather than better. Scaling with more nodes is usually more effective than pushing a single heap past the compression threshold.