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%" 
  }
}
'