elasticsearch 熔断器

Elasticsearch 含多种熔断器用来避免由于操做引发来的OutOfMemoryError（内存溢出错误）. 每一个熔断器指定可使用多少内存的限制。 另外，还有一个父级别的熔断器，指定能够在全部断路器上使用的总内存量。

parent circuit breaker（父熔断器）

父熔断器能够经过以下配置：

indices.breaker.total.limit: 70%
indices.breaker.total.use_real_memory: true

1. 父级断路器是否应考虑实际内存使用状况（true）或仅考虑子级断路器保留的数量（false）。默认为true。
2. 整个父级断点器的启动限制，若是indices.breaker.total.use_real_memory: false 默认为JVM堆的70％ of the JVM heap., 不然为95% of the JVM heap.

Field data circuit breaker（ 列数据熔断器）

列数据断路器，Elasticsearch系统会估计有多少数据被加载到内存中。 它能够避免由于列字段加载（缓存）增加过多带来的异常。 默认状况下，该限制配置为最大JVM堆的60％。

能够配置如下参数：
index.breaker.fielddata.limit

fieldData断点器的限制，默认为JVM堆的60（7.*版本: 40％)

indices.breaker.fielddata.overhead

全部列数据乘以一个常量获得最终的值。 默认为1.03

Request circuit breaker(请求熔断器)

请求断路器容许Elasticsearch防止每一个请求数据结构（例如，用于在请求期间计算聚合的内存）超过必定量的内存。

indices.breaker.request.limit

request熔断器的限制，默认为JVM堆的60%

indices.breaker.request.overhead

全部请求乘以一个常量获得最终的值。 默认为1

In flight requests circuit breaker（请求中的熔断器）

请求中的熔断器，容许Elasticsearch限制在传输或HTTP级别上的全部当前活动的传入请求的内存使用超过节点上的必定量的内存。 内存使用是基于请求自己的内容长度。

network.breaker.inflight_requests.limit

(inflight_requests)请求中熔断器，默认为100％的JVM堆。 这意味着受限于父母断路器配置的极限。

network.breaker.inflight_requests.overhead

全部(inflight_requests)请求中估算的常数乘以肯定最终估计。 默认为1(7.*版本:2)

Accounting requests circuit breaker

找不到中文翻译，这个熔断器容许Elasticsearch限制内存中保存的内容的使用量，这些内容在请求完成时未释放，
包括像Lucene段内存这样的东西。

indices.breaker.accounting.limit

accounting断路器的限制，默认为JVM堆的100％这意味着它受到父断路器配置的限制的约束。

indices.breaker.accounting.overhead

全部 accounting 估计相乘的常数，以肯定最终估计。默认为1

Script compilation circuit breaker（脚本编译熔断器）

与之前的基于内存的断路器略有不一样，脚本编译断路器在一段时间内限制了内联脚本编译的数量。

script.max_compilations_rate

限制容许编译的特定时间间隔内的惟一动态脚本数。默认为75 / 5m，即每5分钟75个。

事故原由：

开发同窗在排查 nginx 日志中 uuid 为 undefined 的请求，时间选择了一年。而咱们一天的数据早已经超过1亿多，整个请求把把5.5G 的数据加载到内存中直接把 es 撑炸了。
kibana 返回：

Data too large, data for [xxx] would be larger than limit

解决方案：

• 把 index cache 释放掉 curl -XPOST 'index1_alias,index2/_cache/clear'
• 能够把Request circuit breaker limit 调小些

curl -XPUT /_cluster/settings \
-H 'Content-type: application/json'
-d '{

  "persistent" : {
    "indices.breaker.request.limit" : "45%" 
  }
}
'