High concurrent rebalance
Cluster concurrent rebalance is above the recommended value. Many shards might relocate at once.
For a complete list of insights, refer to AutoOps insights.
| Field | Value |
|---|---|
| Component | Elasticsearch |
| Severity | Medium |
| Scope | Cluster |
| Domains | performance, shard-allocation |
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 |
|---|---|---|
| Maximum cluster concurrent rebalance | Integer | 2 |
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.
cluster.routing.allocation.cluster_concurrent_rebalance is 12. Recommended maximum: 2.
AutoOps shows different recommendations depending on how their conditions match your deployment or cluster.
Decrease concurrent rebalance limit
Condition: Always shown for this insight.
High concurrent rebalance can overload the cluster. Lower cluster.routing.allocation.cluster_concurrent_rebalance with the action below.
PUT _cluster/settings
{
"persistent": {
"cluster.routing.allocation.cluster_concurrent_rebalance": 2
}
}
Requires the manage cluster privilege. Requires Elasticsearch 8.0.0 or later. This action changes cluster or index configuration.
This setting caps how many shards the cluster can move at once to rebalance shard distribution across nodes, while respecting allocation filters and forced awareness.
When shards move, both the sending and receiving nodes need disk and network capacity. If concurrent rebalance is too high, the cluster might consume too many resources at once during relocation. That can slow indexing and search while moves are in progress.