Caused by: org.elasticsearch.common.breaker.CircuitBreakingException: [parent] Data too large, data

背景

告警提示，ElasticSearch的集群状态为Red，于是看日志得到如下的异常：

Caused by: org.elasticsearch.transport.RemoteTransportException: [es3][10.19.1.2:9300][internal:cluster/nodes/indices/shard/store[n]]
Caused by: org.elasticsearch.common.breaker.CircuitBreakingException: [parent] Data too large, data for [<transport_request>] would be [6288830114/5.8gb], which is larger than the limit of [6087206502/5.6gb], real usage: [6288829536/5.8gb], new bytes reserved: [578/578b], usages [request=0/0b, fielddata=0/0b, in_flight_requests=149360/145.8kb, accounting=0/0b]

分析

我们查看磁盘使用率和JVM的设置都没有超过80%，但是为什么会出现这个异常了？但是我们查看操作系统的内存使用率，其中有一个数据节点内存使用率超过了85%。

因为ElastiSearch 7.3增加了 indices.breaker.total.use_real_memory配置，默认为true。默认的阈值是JVM堆内存的70%。

在判断parent level的熔断时把jvm实际使用的内存考虑在内，因为 real usage: [6288829536/5.8gb]>  [6087206502/5.6gb]，所以触

发了熔断。此时说明jvm堆内存使用率超过80%了，可以考虑扩容或者从使用上降低内存使用率。

解决

我并不想扩容节点，所以我直接调整阈值。

PUT _cluster/settings
{
 "persistent" : 
 {
    "indices.breaker.total.limit" : "95%" 
 } 
}

然后再次查询：

GET _cluster/settings

{
  "persistent" : {
    "indices" : {
      "breaker" : {
        "total" : {
          "limit" : "95%"
        }
      }
    },
    "xpack" : {
      "monitoring" : {
        "collection" : {
          "enabled" : "true"
        }
      }
    }
  },
  "transient" : {
    "cluster" : {
      "routing" : {
        "allocation" : {
          "enable" : "all"
        }
      },
      "max_shards_per_node" : "900000"
    }
  }
}