﻿---
title: Symptom: High CPU usage
description: Elasticsearch uses thread pools to manage CPU resources for concurrent operations. High CPU usage typically means one or more thread pools are running...
url: https://docs-v3-preview.elastic.dev/elastic/docs-content/pull/4620/troubleshoot/elasticsearch/high-cpu-usage
products:
  - Elasticsearch
applies_to:
  - Elastic Stack: Generally available in 9.0+
---

# Symptom: High CPU usage
Elasticsearch uses [thread pools](https://docs-v3-preview.elastic.dev/elastic/elasticsearch/tree/main/reference/elasticsearch/configuration-reference/thread-pool-settings) to manage CPU resources for concurrent operations. High CPU usage typically means one or more thread pools are running low.
If a thread pool is depleted, Elasticsearch will [reject requests](https://docs-v3-preview.elastic.dev/elastic/docs-content/pull/4620/troubleshoot/elasticsearch/rejected-requests) related to the thread pool. For example, if the `search` thread pool is depleted, Elasticsearch will reject search requests until more threads are available.
<admonition title="Simplify monitoring with AutoOps">
  AutoOps is a monitoring tool that simplifies cluster management through performance recommendations, resource utilization visibility, and real-time issue detection with resolution paths. Learn more about [AutoOps](https://docs-v3-preview.elastic.dev/elastic/docs-content/pull/4620/deploy-manage/monitor/autoops).
</admonition>


## Diagnose high CPU usage


### Check CPU usage

You can check the CPU usage per node using the [cat nodes API](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-cat-nodes):
```json
```

The response’s `cpu` column contains the current CPU usage as a percentage. The `name` column contains the node’s name. Elevated but transient CPU usage is normal. However, if CPU usage is elevated for an extended duration, it should be investigated.
To track CPU usage over time, we recommend enabling monitoring:
<applies-switch>
  <applies-item title="{ ess:, ece: }" applies-to="Elastic Cloud Hosted: Generally available, Elastic Cloud Enterprise: Generally available in 4.0+">
    - (Recommended) Enable [logs and metrics](https://docs-v3-preview.elastic.dev/elastic/docs-content/pull/4620/deploy-manage/monitor/stack-monitoring/ece-ech-stack-monitoring). When logs and metrics are enabled, monitoring information is visible on Kibana's [Stack Monitoring](https://docs-v3-preview.elastic.dev/elastic/docs-content/pull/4620/deploy-manage/monitor/monitoring-data/visualizing-monitoring-data) page.
      You can also enable the [CPU usage threshold alert](https://docs-v3-preview.elastic.dev/elastic/docs-content/pull/4620/deploy-manage/monitor/monitoring-data/configure-stack-monitoring-alerts) to be notified about potential issues through email.
    - From your deployment menu, view the [**Performance**](https://docs-v3-preview.elastic.dev/elastic/docs-content/pull/4620/deploy-manage/monitor/access-performance-metrics-on-elastic-cloud) page. On this page, you can view two key metrics:
      - **CPU usage**: Your deployment’s CPU usage, represented as a percentage.
    - **CPU credits**: Your remaining CPU credits, measured in seconds of CPU time.
    Elastic Cloud Hosted grants [CPU credits](https://docs-v3-preview.elastic.dev/elastic/docs-content/pull/4620/deploy-manage/deploy/elastic-cloud/ec-vcpu-boost-instance) per deployment to provide smaller clusters with performance boosts when needed. High CPU usage can deplete these credits, which might lead to [performance degradation](https://docs-v3-preview.elastic.dev/elastic/docs-content/pull/4620/troubleshoot/monitoring/performance) and [increased cluster response times](https://docs-v3-preview.elastic.dev/elastic/docs-content/pull/4620/troubleshoot/monitoring/cluster-response-time).
  </applies-item>

  <applies-item title="{ self:, eck: }" applies-to="Elastic Cloud on Kubernetes: Generally available in 3.0+, Self-managed Elastic deployments: Generally available in 9.0+">
    - Enable [Elasticsearch monitoring](https://docs-v3-preview.elastic.dev/elastic/docs-content/pull/4620/deploy-manage/monitor/stack-monitoring). When logs and metrics are enabled, monitoring information is visible on Kibana's [Stack Monitoring](https://docs-v3-preview.elastic.dev/elastic/docs-content/pull/4620/deploy-manage/monitor/monitoring-data/visualizing-monitoring-data) page.
      You can also enable the [CPU usage threshold alert](https://docs-v3-preview.elastic.dev/elastic/docs-content/pull/4620/deploy-manage/monitor/monitoring-data/configure-stack-monitoring-alerts) to be notified about potential issues through email.
  </applies-item>
</applies-switch>


### Check hot threads

If a node has high CPU usage, use the [nodes hot threads API](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-nodes-hot-threads) to check for resource-intensive threads running on the node.
```json
```

This API returns a breakdown of any hot threads in plain text. High CPU usage frequently correlates to [a long-running task, or a backlog of tasks](https://docs-v3-preview.elastic.dev/elastic/docs-content/pull/4620/troubleshoot/elasticsearch/task-queue-backlog).

## Reduce CPU usage

The following tips outline the most common causes of high CPU usage and their solutions.

### Check JVM garbage collection

High CPU usage is often caused by excessive JVM garbage collection (GC) activity. This excessive GC typically arises from configuration problems or inefficient queries causing increased heap memory usage.
For optimal JVM performance, garbage collection should meet these criteria:

| GC type  | Completion time | Frequency            |
|----------|-----------------|----------------------|
| Young GC | <50ms           | ~once per 10 seconds |
| Old GC   | <1s             | ≤once per 10 minutes |

Excessive JVM garbage collection usually indicates high heap memory usage. Common potential reasons for increased heap memory usage include:
- Oversharding of indices
- Very large aggregation queries
- Excessively large bulk indexing requests
- Inefficient or incorrect mapping definitions
- Improper heap size configuration
- Misconfiguration of JVM new generation ratio (`-XX:NewRatio`)


### Hot spotting

You might experience high CPU usage on specific data nodes or an entire [data tier](https://docs-v3-preview.elastic.dev/elastic/docs-content/pull/4620/manage-data/lifecycle/data-tiers) if traffic isn’t evenly distributed. This is known as [hot spotting](https://docs-v3-preview.elastic.dev/elastic/docs-content/pull/4620/troubleshoot/elasticsearch/hotspotting). Hot spotting commonly occurs when read or write applications don’t evenly distribute requests across nodes, or when indices receiving heavy write activity, such as indices in the hot tier, have their shards concentrated on just one or a few nodes.
For details on diagnosing and resolving these issues, refer to [Hot spotting](https://docs-v3-preview.elastic.dev/elastic/docs-content/pull/4620/troubleshoot/elasticsearch/hotspotting).

### Oversharding

Oversharding occurs when a cluster has too many shards, often times caused by shards being smaller than optimal. While Elasticsearch doesn’t have a strict minimum shard size, an excessive number of small shards can negatively impact performance. Each shard consumes cluster resources because Elasticsearch must maintain metadata and manage shard states across all nodes.
If you have too many small shards, you can address this by doing the following:
- Removing empty or unused indices.
- Deleting or closing indices containing outdated or unnecessary data.
- Reindexing smaller shards into fewer, larger shards to optimize cluster performance.

If your shards are sized correctly but you are still experiencing oversharding, creating a more aggressive [index lifecycle management strategy](https://docs-v3-preview.elastic.dev/elastic/docs-content/pull/4620/manage-data/lifecycle/index-lifecycle-management) or deleting old indices can help reduce the number of shards.
For more information, refer to [Size your shards](https://docs-v3-preview.elastic.dev/elastic/docs-content/pull/4620/deploy-manage/production-guidance/optimize-performance/size-shards).

### Additional recommendations

To further reduce CPU load or mitigate temporary spikes in resource usage, consider these steps:

#### Scale your cluster

Heavy indexing and search loads can deplete smaller thread pools. Add nodes or upgrade existing ones to handle increased indexing and search loads more effectively.

#### Spread out bulk requests

Submit smaller [bulk indexing](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-bulk-1) or multi-search requests, and space them out to avoid overwhelming thread pools.

#### Cancel long-running searches

Regularly use the [task management API](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-tasks-list) to identify and cancel searches that consume excessive CPU time.
```json
```

The response’s `description` contains the search request and its queries. `running_time_in_nanos` shows how long the search has been running.
```json
{
  "nodes" : {
    "oTUltX4IQMOUUVeiohTt8A" : {
      "name" : "my-node",
      "transport_address" : "127.0.0.1:9300",
      "host" : "127.0.0.1",
      "ip" : "127.0.0.1:9300",
      "tasks" : {
        "oTUltX4IQMOUUVeiohTt8A:464" : {
          "node" : "oTUltX4IQMOUUVeiohTt8A",
          "id" : 464,
          "type" : "transport",
          "action" : "indices:data/read/search",
          "description" : "indices[my-index], search_type[QUERY_THEN_FETCH], source[{\"query\":...}]",
          "start_time_in_millis" : 4081771730000,
          "running_time_in_nanos" : 13991383,
          "cancellable" : true
        }
      }
    }
  }
}
```

To cancel a search and free up resources, use the API’s `_cancel` endpoint.
```json
```

For additional tips on how to track and avoid resource-intensive searches, see [Avoid expensive searches](/elastic/docs-content/pull/4620/troubleshoot/elasticsearch/high-jvm-memory-pressure#avoid-expensive-searches).