日志中reason=[parent]、[fielddata]、[in_flight_requests]精准指向熔断类型：[parent]表JVM堆整体吃紧；[fielddata]多因text字段聚合导致；[in_flight_requests]源于bulk写入或搜索并发激增。
直接看日志里的 [parent]、[fielddata] 或 [in_flight_requests] —— 这三个关键词决定了你该查哪块，而不是盲目调 JVM。
怎么看日志定位熔断器类型
错误日志里 reason=[parent] Data too large 或 reason=[fielddata] Data too large 不是装饰，是精准指向。别跳过它：
-
[parent]：说明总内存（所有子熔断器加起来）已逼近 JVM 堆上限，real usage和limit差值常小于 10MB，说明节点整体吃紧； -
[fielddata]：几乎都和对text字段做sort、terms聚合或脚本访问有关，尤其字段基数高（如日志内容、用户昵称）； -
[in_flight_requests]：多见于大批量bulk写入或并发搜索请求激增，new bytes reserved值小但usages.in_flight_requests累积高，说明 HTTP 请求体堆积。
查 fielddata 占用不能只看 _cat/indices
GET /_cat/indices?v&h=index,fielddata.memory_size&s=fielddata.memory_size:desc 只给总量，掩盖了“哪个字段在吃内存”。真正要盯的是：
- 单字段级监控：
GET /_nodes/stats/indices/fielddata?fields=*，返回里会按字段名拆出memory_size_in_bytes，重点看那些没被显式keyword化却参与聚合的text字段； - 驱逐数为 0 是危险信号：
evictions长期为 0，说明缓存进得去、出不来，indices.fielddata.cache.size没生效或设得太小； - 别信“清理就能好”：执行
POST /my_index/_cache/clear?fielddata=true后如果查询立刻复现相同字段的熔断，说明业务逻辑没改，只是把问题延迟了。
调整熔断器配置前先确认真实内存压力
很多人一见 parent 熔断就去调 indices.breaker.total.limit，结果只是把 OOM 推迟几分钟。必须先确认：
- 查当前 JVM 实际使用：
GET /_nodes/stats/jvm?filter_path=**.mem.*，对比heap_used_in_bytes和heap_max_in_bytes，若长期 >85%，说明 GC 已乏力； - 看 GC 行为：
GET /_nodes/stats/jvm?filter_path=**.gc.*，如果collectors.young.collection_count高但collection_time_in_millis也高，G1 GC 可能正在频繁 mixed GC，这时调熔断器上限反而加重负担； -
indices.breaker.total.use_real_memory设为true（ES 7.0+ 默认）才让父熔断器基于真实堆占用判断，否则它只估算，容易误触发。
临时缓解和长期修复的区别在哪
线上救火时，POST /_cluster/settings 动态调参可以压住告警，但下次查询结构不变，照样爆：
- 临时：降低
indices.breaker.fielddata.limit到 40%（治标），或提高indices.fielddata.cache.size强制驱逐（治标不治本）； - 长期：把高频聚合的
text字段加fields.keyword多字段映射，查询时显式用my_field.keyword；或者用doc_values=false关掉不用聚合字段的倒排加载； - 最易忽略的一点：
search.max_buckets默认 10000，如果聚合深度大、分桶多，request熔断器会先于fielddata触发——这个参数不是内存相关，但直接影响熔断路径。
