---
title: High CPU Utilization
description: Describes what AutoOps detects and surfaces with the High CPU Utilization insight: CPU usage on a node has crossed your configured threshold for enough consecutive samples to signal a problem.
url: https://docs-v3-preview.elastic.dev/elastic/autoops-insights/tree/main/elasticsearch/high_cpu_utilization
products:
  - Elastic Cloud Enterprise
  - Elastic Cloud Hosted
  - Elastic Cloud on Kubernetes
  - Elasticsearch
applies_to:
  - Elastic Cloud Hosted: Generally available
  - Elastic Cloud on Kubernetes: Generally available
  - Elastic Cloud Enterprise: Generally available
  - Self-managed Elastic deployments: Generally available
---

# 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.
<note>
  For a complete list of insights, refer to [AutoOps insights](https://docs-v3-preview.elastic.dev/elastic/autoops-insights/tree/main/elasticsearch).
</note>


## Insight details


| Field     | Value                       |
|-----------|-----------------------------|
| Component | Elasticsearch               |
| Severity  | Medium                      |
| Scope     | Node                        |
| Domains   | performance, cpu, stability |


## Customization settings

You can customize these settings to adjust when AutoOps detects this event and presents the insight. Refer to [AutoOps event settings](https://docs-v3-preview.elastic.dev/elastic/docs-content/tree/main/deploy-manage/monitor/autoops/ec-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       |

<tip>
  Raising these thresholds reduces noise but delays detection. Lowering them triggers the insight sooner but can increase alerts during minor blips.
</tip>


## Example: What you might see in AutoOps

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 is high


#### What was detected

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

#### Recommendations

<note>
  AutoOps shows different recommendations depending on how their conditions match your deployment or cluster.
</note>

<dropdown title="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.
  ```json

  {
    "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"
  }
  ```

  <note>
    Requires the `manage` index privilege. Requires Elasticsearch 8.0.0 or later. This action changes cluster or index configuration.
  </note>
</dropdown>

<dropdown title="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.
</dropdown>

<dropdown title="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.
</dropdown>

<dropdown title="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](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-indices-shrink) for prerequisites.
</dropdown>

<dropdown title="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](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-indices-clear-cache) when needed.
</dropdown>


#### Background and impact

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.