Elasticsearch [type=circuit_breaking_exception, reason=[parent] Data too large....]
前提环境:ElasticSearch 7.6.2、kibana 7.6.2-Xmx:1G问题根据一些条件进行query查询时出现了:ElasticsearchStatusException[Elasticsearch exception [type=circuit_breaking_exception, reason=[parent] Data too large, data for [<h
前提
环境:ElasticSearch 7.6.2、kibana 7.6.2
-Xmx:1G
问题
根据一些条件进行query查询时出现了:
ElasticsearchStatusException[Elasticsearch exception [type=circuit_breaking_exception, reason=[parent] Data too large, data for [<http_request>] would be [1035707518/987.7mb], which is larger than the limit of [986061209/940.3mb], real usage: [1035706544/987.7mb], new bytes reserved: [974/974b], usages [request=0/0b, fielddata=1487938/1.4mb, in_flight_requests=974/974b, accounting=1545815/1.4mb]]]
分析问题
出错这种错误的确是内存方面的原因,来看下,
Data too large, data for [<http_request>] would be [1035707518/987.7mb], //A
which is larger than the limit of [986061209/940.3mb], //B
real usage: [1035706544/987.7mb], //C
new bytes reserved: [974/974b] //D
这里有4个数值:
B处的数就是上限,超过这个就报错。(缺省是它是ES最大内存的95%)
C处的数值是你的本机上ES进程已使用的内存大小
D处的数值1150就是你本次操作(或者说执行当前的任务)所需要内存
C + D = A > B,所以报错了
结论
到这里你也应该很清楚问题的最终因素,内存?对,就是内存问题!
简单粗暴解决办法
你可以增大-Xmx量(如果物理内存足够的话)
当然,最省事的做法就是关闭CircuitBreaker检查(不建议)
关于ES的内存优化配置
断路器
indices.breaker.fielddata.limit
fielddata 断路器默认设置堆的 60% 作为 fielddata 大小的上限。
indices.breaker.request.limit
request 断路器估算需要完成其他请求部分的结构大小,例如创建一个聚合桶,默认限制是堆内存的 40%。
indices.breaker.total.limit
total 揉合 request 和 fielddata 断路器保证两者组合起来不会使用超过堆内存的 70%。
indices.fielddata.cache.size
缓存回收大小,无默认值, 有了这个设置,最久未使用(LRU)的 fielddata 会被回收为新数据腾出空间
PUT /_cluster/settings
{
"persistent": {
"indices.breaker.fielddata.limit": "60%"
}
}
PUT /_cluster/settings
{
"persistent": {
"indices.breaker.request.limit": "40%"
}
}
PUT /_cluster/settings
{
"persistent": {
"indices.breaker.total.limit": "70%"
}
}
最后一项要在elasticsearch.yml中配置
#最久未使用(LRU)的 fielddata 会被回收为新数据腾出空间
indices.fielddata.cache.size: 40%
建议
最好为断路器设置一个相对保守点的值。 记住 fielddata 需要与 request 断路器共享堆内存、索引缓冲内存和过滤器缓存。Lucene 的数据被用来构造索引,以及各种其他临时的数据结构。 正因如此,它默认值非常保守,只有 60% 。过于乐观的设置可能会引起潜在的堆栈溢出(OOM)异常,这会使整个节点宕掉。
另一方面,过度保守的值只会返回查询异常,应用程序可以对异常做相应处理。异常比服务器崩溃要好。
上面几项的关系
当前fieldData缓存区大小 < indices.fielddata.cache.size
当前fieldData缓存区大小 + 下一个查询加载进来的fieldData < indices.breaker.fielddata.limit
indices.breaker.request.limit + indices.breaker.fielddata.limit < indices.breaker.total.limit
Elastic官方文档:限制内存使用
————————————————
版权声明:本文为CSDN博主「小小小丶老鼠」的原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接及本声明。
原文链接:https://blog.csdn.net/qq_33576276/article/details/110945364
更多推荐
所有评论(0)