High CPU Utilization
CPU usage on a node has crossed your configured threshold for enough consecutive samples to signal a problem. Response times and throughput can degrade, and error rates might increase on that node.
For a complete list of insights, refer to AutoOps insights.
| Field | Value |
|---|---|
| Component | Elasticsearch |
| Severity | Medium |
| Scope | Node |
| Domains | performance, cpu, 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 |
|---|---|---|
| CPU threshold in percentage | Integer | 80 |
| Successive samplings to trigger | Integer | 5 |
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.
The CPU utilization on node es-data-01 and es-data-02 has crossed the defined threshold of 12 % usage. There is high GC happening on this node
AutoOps shows different recommendations depending on how their conditions match your deployment or cluster.
Enable and review search slow logs
Condition: Always shown for this insight.
Enable search slow logs with the action below, then review logs on es-data-01 for long-running or repeatedly executed queries. Tune or rewrite expensive queries to reduce CPU load. On 8.14+, set index.search.slowlog.include.user to true to identify which user triggered slow searches.
PUT _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.
Check cluster health
Condition: Shown when cluster.status != green.
Your cluster status is not green. Open the "Status yellow" insight in AutoOps for remediation steps.
Enable memory lock on nodes
Condition: Shown when memory not locked, only outside of ESS.
As a last resort if OS-level memory locking is not enough, set bootstrap.memory_lock: true in elasticsearch.yml on each affected node, then perform a rolling restart. This keeps the JVM heap from being swapped out.
Reduce shard count
Condition: Shown when node contains too many shards.
Use the shrink API to reduce shard count from 24 to 12. See the Shrink API for prerequisites.
Review field data and query caches
Condition: Shown when cluster status is not green on the affected node.
Large field data or query caches can drive high CPU. Monitor cache usage and clear oversized caches with the Clear cache API when needed.
High CPU usage can lead to slower response times, reduced throughput, increased error rates, and instability or crashing of the cluster. It can also indicate inefficient resource usage, leading to higher costs. Lastly, if Elasticsearch shares hardware with other applications, its high CPU usage can negatively impact their performance. To avoid these problems, it's crucial to appropriately configure the cluster, optimize operations, monitor performance, and scale resources as necessary.