ES写入数据时:circuit_breaking_exception[[parent] Data too large

报错:

txt 复制代码
circuit_breaking_exception[[parent] Data too large, data for [<transport_request>] would be [12318476937/11.2gb], which is larger than the limit of [12237372108/12.2gb], real usage: [12318456248/11.2gb]

原因:

(1)表面原因是在ES中大量内存被占用,GC无法对heap进行垃圾回收,导致node内存用量超出limit限制。

(2)根本原因是ES设置有问题,默认配置是JVM内存使用达到75%的时候进行full GC,默认配置总熔断器indices.breaker.total.use_real_memory 它的值直接影响JVM堆内存分配的大小, 1、值为 true, indices.breaker.total.limit 为堆大小的 95%。 2、值为 false,indices.breaker.total.limit 为堆大小的70%

如果在还未到ES的full GC的时候,已经达到ES总熔断器的上限了,那么此时ES的内存一直没有回收,不断插入新数据,那么就会产生报错。

解决:1、在elasticsearch.yml添加配置:

yml 复制代码
indices.breaker.total.use_real_memory:false
indices.breaker.total.limit: 70%

2、修改ES的jvm.options:

yml 复制代码
-Xms10g
-Xmx10g
## GC configuration
-XX:+UseConcMarkSweepGC
-XX:CMSInitiatingOccupancyFraction=60
-XX:+UseCMSInitiatingOccupancyOnly

假如JVM的内存设置的是10GB,经过以上配置后,熔断器的内存范围是7GB,GC的内存范围是6GB,那么在未达到熔断器的最高标准时,JVM会进行full GC,那么就不会报错了。或者就无脑加大ES的内存也是可以的,毕竟内存大了,可能永远就达不到熔断了。

相关推荐
updayday854几秒前
供应商补交资质文件时,采购难以核对缺件和新版本 - Ping64 文件收集
大数据·网络·数据库·安全·智能路由器
小飞象—木兮4 分钟前
经营分析核心思路:经营分析的六层执行框架、底层原则、 全行业通用经营分析方法论
大数据·人工智能·矩阵·数据分析·用户运营
星云低代码开发平台19 分钟前
AI 销售周报的数据契约:CRM 商机、ERP 订单与异常核对
大数据·人工智能·企业ai
数脉24 分钟前
让每一次提问都有据可答:我们的数据血缘平台 AI 助手功能预告
大数据·数据挖掘·数据分析
Light6026 分钟前
四款云端 Agent 的安全边界画在三个地方
大数据·数据库·安全·个人agent·安全边界·提示注入·grok bot
starzy199029 分钟前
Flink 任务调度 Graph 源码深度剖析:从 StreamGraph 到 ExecutionGraph 的三层演进
java·大数据·flink
徐礼昭|商派软件市场负责人1 小时前
如何打通2B与2C库存?如何破解“线上缺货、线下积压”的内耗?——OMS全渠道「库存一盘货」策略详解
大数据·库存管理·订单管理·商派oms·oms系统
Regentsoft丽晶软件1 小时前
全渠道一盘货驱动零售品牌DTC转型,破除传统零售割裂和库存冗余
大数据·人工智能·零售
jkyy20141 小时前
从手机原生相机到医疗机构:规模化膳食采集能力的多场景落地实践
大数据·数码相机·智能手机·健康医疗