circuit_breaking_exception,“reason“:“[parent] Data too large, data for [＜http_request＞]

ES 断路器，jvm堆内存不够当前查询加载数据所以会报data too large, 请求被熔断。

一、出现原因

批量导入数据过多 或者 查询数据太多，比较频繁 

集群状态为yellow或red时，分析原因：

GET _cluster/allocation/explain

二、定期清理缓存

出现这样问题，一般是 服务器 内存不够导致的，可以加大 ES可用的内存，但是如果加大不了，那么为了保证服务的可用性，可以 来一个定时任务，定期清理 索引缓存。

虽然可能导致 查询会慢，但是总比直接报错 查询不了和 保存数据不成功要好得多

1、清理缓存方法

删除 数据采集 索引 缓存： POST /collect_data*/_cache/clear

监控 字段缓存 ：GET /_stats/fielddata?fields=*

2、重启集群节点

如果清理缓存无效，_cache/clear ， 那么可重启。

如果 频繁出现  Data too large 异常，我认为可以 再减低  indices.fielddata.cache.size  这个设置。 让其 尽快的清理 缓存。

同时增大  ES的 可用内存，和 可用内存对应的限制大小： 即 indices.breaker..limit

通过监控，找到出现问题的原因：GET /_cluster/stats?pretty

三、优化查询

1、增加服务器内存和ES集群增加

当索引数据太多，服务器内存太小，哪怕定时清理 缓存即 _cache/clear，还是出现了 触发了熔断器的异常。此时只能考虑去升内存和扩ES集群了。

2、避免使用  索引名*

这种类似 select * from table 的方式

比如 我这里 是每年或者每个月产生一个 索引比如  user_2020, 和 user_2019

查询的时候，我 这样 使用 索引 ：  user*  这样去查询， 这样肯定影响查询性能，

如果一个 复杂的聚合语句， ES会去聚合 所有 user 开头的索引， 那肯定占用的内存非常多。

此时可以考虑 是否是 ES的查询语句 使用方式问题？检查，并优化

更多调优参考：  https://blog.csdn.net/andy_only/article/details/98172044

3、JVM 配置使用G1垃圾收集器