ES实战-熔断器

场景

客户现场业务系统突然查询不到数据，看了下系统日志，看到如下日志打印：

Caused by: ElasticsearchStatusException[Elasticsearch exception [type=circuit_breaking_exception, reason=[parent] Data too large, data for [<http_request>] 
would be [1032639682/984.8mb], //  A
which is larger than 
the limit of [1032637056/972.7mb],// B
real usage: [1032637056/984. 7mb], //C
new bytes reserved: [2626/2.5kb],// D
usages [request=72/72b, fielddata=0/0b, in_flight_requests=2626/2.5kb, accounting=6830904/6. 5mb]] 

上面的异常报了几组数据值，我用A,B,C,D进行标注，解释如下：

A处的数为C+D的值；

B处的数就是上限，超过这个就报错。（缺省是它是ES最大内存的95%);

C处的数值是你的本机上ES进程已使用的内存大小;

D处的数值1150就是你本次操作（或者说执行当前的任务）所需要内存;

C + D = A > B，所以报错了。

异常原因

最终定位结论：ES分配内存使用达到设定的极限值，触发了es熔断请求，ES一旦内存使用达到设定的内存限值，则触发熔断机制，不再响应任何请求。
报错信息中的“Elasticsearch exception [type=circuit_breaking_exception]表明是触发了熔断器导致报错，且日志显示实际使用量[1032637056/984. 7mb]已经超过了限制[1032637056/972.7mb]，故触发熔断机制。

断路器（Circuit Breakers）

fielddata 大小是在数据加载 之后 检查的。
如果一个查询试图加载比可用内存更多的信息到 fielddata 中会发生什么？答案很丑陋：我们会碰到 OutOfMemoryException 。
Elasticsearch 包括一个 fielddata 断熔器 ，这个设计就是为了处理上述情况。 断熔器通过内部检查（字段的类型、基数、大小等等）来估算一个查询需要的内存。它然后检查要求加载的 fielddata 是否会导致 fielddata 的总量超过堆的配置比例。
如果估算查询的大小超出限制，就会 触发 断路器，查询会被中止并返回异常。这都发生在数据加载 之前 ，也就意味着不会引起 OutOfMemoryException 。

Elasticsearch 有一系列的断路器，它们都能保证内存不会超出限制：

indices.breaker.fielddata.limit
fielddata 断路器默认设置堆的 60% 作为 fielddata 大小的上限。

indices.breaker.request.limit
request 断路器估算需要完成其他请求部分的结构大小，例如创建一个聚合桶，默认限制是堆内存的 40%。

indices.breaker.total.limit
total 揉合 request 和 fielddata 断路器保证两者组合起来不会使用超过堆内存的 70%。


断路器的限制可以在文件 config/elasticsearch.yml 中指定，可以动态更新一个正在运行的集群：
PUT /_cluster/settings
{
     "persistent" : {
     "indices.breaker.fielddata.limit" : "40%"
     }
 }

关于给 fielddata 的大小加一个限制，从而确保旧的无用 fielddata 被回收的方法。 indices.fielddata.cache.size 和 indices.breaker.fielddata.limit 之间的关系非常重要。 如果断路器的限制低于缓存大小，没有数据会被回收。为了能正常工作，断路器的限制 必须 要比缓存大小要高。

断路器设置

断路器目的

ES通过断路器的设置，来保护集群内存不超过设定值，从而保证集群的稳定性。

Elasticsearch 包含多个断路器，用于防止操作导致 OutOfMemoryError。每个断路器指定它可以使用多少内存的限制。此外，还有一个父级断路器，用于指定可跨所有断路器使用的内存总量。

断路器种类

父断路器(parent circuit breaker)

可以使用以下设置配置父级断路器：
indices.breaker.total.use_real_memory
确定父断路器是否应考虑实际内存使用量 ( true) 或仅考虑子断路器保留的数量 ( false)。默认为true.
    
indices.breaker.total.limit
整个父断路器的启动限制。
如果indices.breaker.total.use_real_memory是 false ，则默认为 JVM 堆的 70%。
如果indices.breaker.total.use_real_memory 是true，则默认为 JVM 堆的 95%。

字段数据断路器(Field data circuit breaker)

字段数据断路器估计将字段加载到字段数据缓存中所需的堆内存。如果加载该字段会导致缓存超出预定义的内存限制，则断路器将停止操作并返回错误。

indices.breaker.fielddata.limit
字段数据断路器的限制。默认为 JVM 堆的 40%。

indices.breaker.fielddata.overhead
一个常数，与所有现场数据估计相乘以确定最终估计。默认为1.03.

请求断路器(Request circuit breaker)

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

indices.breaker.request.limit
请求断路器的限制，默认为 JVM 堆的 60%。request断路器估算需要完成其他请求部分的结构大小，例如创建一个聚合桶，默认限制是堆内存的 60%。它实际上是node level的一个统计值，统计的是这个结点上，各类查询聚合操作，需要申请的Bigarray的空间大小总和。 所以如果有一个聚合需要很大的空间，同时在执行的聚合可能也会被break掉。 

indices.breaker.request.overhead
所有请求估计乘以确定最终估计的常数。默认为1。

触发条件

如果一次查询加载的feilddata超过总内存，就会oom （ 内存溢出）
circuit breaker会估算query要加载的fielddata大小，如果超出总内存，就熔断请求，查询直接失败。

elasticsearch.yml：
indices.breaker.fielddata.limit：fielddata的内存限制，默认40%
indices.breaker.request.limit：执行聚合的内存限制，默认60%
indices.breaker.total.limit：综合上面两个，限制在70%以内

如何防止断路器报错

降低JVM的内存压力

高的 JVM 内存压力经常导致断路器错误。可能导致 JVM 使用率暴增的原因列举如下

原因 1：分片大小设置不合理，存在过多小分片。

因为每个分片都会有内存的使用。官方建议分片大小 30GB-50GB之间。

原因 2：复杂的检索或查询操作。

举例：wildcard 查询、设置很大分桶数的聚合操作都是非常“吃”内存的，要避免。

原因 3：存在映射“爆炸”现象

定义太多的字段或将字段嵌套得太深，会导致使用大量内存的

原因 4：存在大型批量请求

大型的批量索引或多重搜索请求会造成 JVM内存压力

原因 5：节点硬件资源受限

物理内存本身就很小，这种是“硬伤”，为避免后患，需要整个团队知悉并想办法协调解决。

避免在 text 类型字段上使用 fielddata

本质原因：需要对 text 字段进行聚合操作，默认 text 是做分词操作的，无法实现聚合和排序，只有 fielddata:true 开启后才可以。
但开启 fielddate:true 会使用大量的 JVM 内存。为了避免这种情况，建议 Elasticsearch 默认在文本字段上禁用 fielddata。官方建议：如果你已经启用了 fielddata， 并触发了  断路器，请考虑禁用它并使用关键字字段 keyword 代替。

蓝闪