Loading

Unbalanced Shards

Shard counts across data nodes are skewed enough that some nodes carry far fewer shards than peers in the same tier. Uneven load wastes capacity on light nodes and can overload hot nodes for indexing and search.

Note

For a complete list of insights, refer to AutoOps insights.

Field Value
Component Elasticsearch
Severity Medium
Scope Node
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
Unbalanced shard percent above the average Percentage 50

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.

Affected data tier: hot, warm.

Average number of shards per node: 1000

Nodes with the lowest number of shards: - logs-prod-000045: 1,200 docs/s Nodes with the highest number of shards: - logs-prod-000045: 1,200 docs/s

Note

AutoOps shows different recommendations depending on how their conditions match your deployment or cluster.

Impact: This indicates that the load is not balanced evenly across the cluster, resulting in suboptimal utilization of resources. This leads to slow indexing and search performance. The cluster will usually balance the index shards evenly across all the data nodes that are active in the cluster. There are two basic processes that govern how shards are distributed among the data nodes. The first is shard allocation, which is an algorithm by which the master node decides which unallocated shards should go on which nodes. The second is shard rebalancing, which is the process of moving a shard from one node to another. There are a number of settings that could keep shards from being balanced properly.