最近在使用公司Elasticseach 7.3.1时,经常报出以下错误,环境时好时坏:
"[circuit_breaking_exception] [parent] Data too large, data for [<http_request>] would be [2052417488/1.9gb], which is larger than the limit of [2040109465/1.8gb], real usage: [2052417488/1.9gb], new bytes reserved: [0/0b], usages [request=144/144b, fielddata=3777512/3.6mb, in_flight_requests=0/0b, accounting=5296757/5mb], with { bytes_wanted=2052417488 & bytes_limit=2040109465 & durability=\"PERMANENT\" }"
直观原因: 分配给ES的堆内存不够用了。
分析: 向ES写入数据时,大致分为以下4个步骤:
1. 数据写入到buffer中。
2. 每隔一段时间 (可以在settings中通过refresh_interval手动设置值)刷新buffer,将数据组装并保存到index segment file(可以看作是一份File,只不过目前存储在内存中)
3. index segment file在被创建后,会被立刻读取并写入到OS Cache中(此时数据就可以对客户端提供搜索服务了)。
4. 默认每隔30分钟或translog过大时,ES会将当前内存中所有的index segment标记并形成一个commit point(类似git 的commit id),进行原子性的持久化操作,操作完毕后,删除本次已经已经了持久化的index segment,腾出内存空间。
所以我认为出现上述的情况是因为: buffer的刷新时间间隔过长或一次新增的数据量过大,导致数据堆集在buffer中,此外由于OSCache 默认30分钟会进行一次自动的flush,清空内存中的部分数据,因此ES会出现"时好时坏"的现象。
解决方案:
方案一.增加分配给ES应用的内存 (验证通过)
编辑 /opt/elasticsearch/config jvm.option,将-Xms和-Xmx 调大,初始值都是1G。修改配置后,需要重启ES才能生效。
方案二.清空缓存 (尚未验证)
curl -XPOST -u admin:Admin@123 'http://xxx:9200/elasticsearch/_cache/clear?fielddata=true'
方案三: GET /_flush 执行所有索引的flush操作