配置项作用 #
action.search.shard_count.limit 配置项限制单次搜索请求最多可以查询的分片数量。该限制旨在防止针对过多分片的大规模搜索请求导致协调节点 CPU 或内存资源耗尽。
配置项类型 #
该配置项为动态配置，可以在运行时通过集群更新 API 进行修改，无需重启节点。
默认值 #
Long.MAX_VALUE（9223372036854775807，实际上无限制）
是否必需 #
可选配置项
取值范围 #
1 ~ Long.MAX_VALUE
配置原理 #
当搜索请求发起时，系统会计算该请求涉及的分片总数（包括本地集群和远程集群的所有分片）。如果分片数量超过此限制，搜索请求将被拒绝并返回错误。
错误信息 #
当超出限制时，系统会返回以下错误信息：
IllegalArgumentException: Trying to query [分片数量] shards, which is over the limit of [限制值].
This limit exists because querying many shards at the same time can make the job of the coordinating node very CPU and/or memory intensive.
It is usually a better idea to have a smaller number of larger shards.
Update [action.search.shard_count.limit] to a greater value if you really want to query that many shards at the same time.
使用示例 #
# 限制单次搜索最多查询 1000 个分片
action.search.shard_count.limit: 1000
# 设置为无限制（默认值）
action.search.shard_count.limit: 9223372036854775807
推荐设置建议 #
生产环境建议：根据集群规模和硬件配置设置合理的限制值
推荐配置：
# 中小型集群（单次搜索建议不超过 500 个分片）
action.search.shard_count.limit: 500
# 大型集群（单次搜索建议不超过 1000 个分片）
action.search.shard_count.limit: 1000
设置理由：
- 保护协调节点：防止过大的搜索请求耗尽协调节点的 CPU 和内存资源
- 提高集群稳定性：避免因个别大查询导致整个集群性能下降
- 促进合理分片设计：鼓励使用较少但更大的分片，而非大量小分片
- 防止意外查询：避免因使用
*通配符导致意外查询过多索引
计算分片数量的场景 #
以下场景会累加分片数量：
# 查询单个索引（1个分片）
GET /my-index/_search
# 查询多个索引（每个索引的分片数累加）
GET /index1,index2,index3/_search
# 使用通配符查询（匹配的所有索引分片数累加）
GET /logs-*/_search
# 跨集群查询（本地集群+远程集群分片数累加）
GET /cluster1:logs-*,cluster2:metrics-*/_search
如何优化 #
如果遇到此限制错误，可以考虑以下优化方案：
1. 缩小查询范围
# 优化前：查询所有日志索引
GET /logs-*/_search
# 优化后：只查询特定日期范围
GET /logs-2024-01-*/_search
2. 使用索引别名
# 创建只包含必要索引的别名
POST /_aliases
{
"actions": [
{"add": {"index": "logs-active", "aliases": "logs-searchable"}}
]
}
# 通过别名查询
GET /logs-searchable/_search
3. 优化分片设计
- 减少小分片的数量
- 合并过小的分片
- 合理设置索引的分片数量
注意事项 #
- 动态更新：修改此配置后立即生效，影响所有新执行的搜索请求
- 适用范围：此限制适用于所有类型的搜索操作，包括普通搜索、聚合查询、滚动查询等
- 与 max_concurrent_shard_requests 的区别：此配置限制的是单次请求涉及的分片总数，而
max_concurrent_shard_requests控制的是并发访问的分片数量 - 跨集群搜索：使用跨集群搜索（CCS）时，所有集群的分片数都会计入此限制
