Max Shard Per Node
The cluster limit on shards per node is set higher than the recommended default. Allowing more shards per node increases memory overhead for shard metadata and slows searches that must fan out across many shards.
For a complete list of insights, refer to AutoOps insights.
| Field | Value |
|---|---|
| Component | Elasticsearch |
| Severity | Medium |
| Scope | Node |
| Domains | configuration, shard-allocation, stability |
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 maximum number of shards per node is configured to 1000.
AutoOps shows different recommendations depending on how their conditions match your deployment or cluster.
Reduce shards per node
Condition: Always shown for this insight.
Too many shards per node (limit 1000) hurts performance. Reindex or shrink to fewer shards, delete unneeded data, and set a cluster shards-per-node cap to 1000 with the action below.
PUT _cluster/settings?pretty
{
"persistent": {
"cluster.routing.allocation.total_shards_per_node": "1000"
}
}
Requires the manage index privilege. Requires Elasticsearch 8.0.0 or later. This action changes cluster or index configuration.
Impact: many shards degrades indexing and search performance and can destabilize the cluster. Elasticsearch allows you to set a limit on the number of shards per node. While you can increase this limit, it is not recommended to do so, since having many shards on the node slows down search operations. This is because the responses need to be collated across many shards. Furthermore, Elasticsearch must maintain data about the mappings and the shard state in memory, so having many shards unnecessarily ties up cluster resources, leaving less available for indexing and search.