Elasticsearch 7.x 聚合查询内存溢出通常由堆内存不足或聚合桶数量超限触发。最推荐的处理方向是优化聚合语句减少基数，其次调整集群配置参数，风险边界在于盲目增加 JVM 堆内存可能导致垃圾回收停顿时间过长。
先说结论：解决内存溢出需优先限制聚合复杂度，再考虑扩容内存资源。
- 先确认：查看日志区分是 circuit_breaking_exception 还是 heap_space 错误
- 先处理：调整 search.max_buckets 限制或使用 composite 聚合分页
- 再验证：监控节点堆内存使用率及垃圾回收频率
命令速用版
PUT _cluster/settings
{
"persistent": {
"search.max_buckets": 100000
}
}该 PUT 命令用于临时提高聚合桶数量上限，仅适用于确认业务需要且内存充足的场景。
为什么会这样
聚合查询内存溢出本质是数据加载量超过了 JVM 堆内存承受能力。
Elasticsearch 在执行 terms 等聚合时，需要在内存中维护桶的状态。当唯一值基数过大或嵌套聚合层级过深时，内存消耗呈线性或指数增长。集群默认启用了电路断路器（Circuit Breaker），当预估内存超过设定阈值时会主动抛出异常防止节点崩溃。
分步处理
步骤 1：识别报错类型
检查 Elasticsearch 日志或客户端返回错误。若包含 circuit_breaking_exception，说明触发了保护机制；若包含 CacheCleanupException 或 GC overhead，说明物理内存确实不足。
步骤 2：调整聚合桶限制
通过集群设置调整 search.max_buckets。默认值通常为 65535。若业务确实需要更多桶，可适当调大，但需配合内存监控。
PUT _cluster/settings
{
"transient": {
"search.max_buckets": 100000
}
}步骤 3：优化聚合语句
将大型 terms 聚合改为 composite 聚合。composite 聚合支持分页获取结果，避免一次性加载所有桶到内存。
步骤 4：检查字段类型
确认聚合字段是否为 keyword 类型。对 text 字段开启 fielddata 会消耗大量堆内存，生产环境建议避免。
怎么验证是否生效
执行原有聚合查询，观察是否不再报错。使用 _cat/nodes?v&h=name,heap.percent 命令检查堆内存百分比。若 heap.percent 持续高于 85% 且频繁 Full GC，说明集群配置仍需优化。
常见坑
- 不要将 JVM 堆内存设置为超过 31GB，否则压缩指针失效反而降低性能
- 避免在高基数字段上使用 nested 聚合，极易导致内存爆炸
- 调整 circuit breaker 阈值不是长久之计，仅作为临时止血手段
常见问题
Elasticsearch 7.x 默认聚合桶限制是多少？
默认 search.max_buckets 设置通常为 65535，具体取决于集群初始化配置。
增加 JVM 堆内存能解决所有聚合溢出吗？
不能，堆内存过大会增加垃圾回收停顿时间，应优先优化查询语句。
text 字段可以直接聚合吗？
不可以，text 字段需要开启 fielddata 才能聚合，但会消耗大量内存，建议使用 keyword 类型。