Elasticsearch 7.x断路器 - 数据过大 - 故障排除

Question

问题：
自从升级从ES-5.4到ES-7.2后，我在尝试使用多线程的Java应用程序（使用elasticsearch-rest-high-level-client-7.2.0.jar Java客户端）向一个由2-4个节点组成的ES集群并发写入批量请求或者搜索请求时，开始出现“数据过大”的错误。

我的ES配置：

Elasticsearch version: 7.2

custom configuration in elasticsearch.yml:   
    thread_pool.search.queue_size = 20000  
    thread_pool.write.queue_size = 500

I use only the default 7.x circuit-breaker values, such as:  
    indices.breaker.total.limit = 95%  
    indices.breaker.total.use_real_memory = true  
    network.breaker.inflight_requests.limit = 100%  
    network.breaker.inflight_requests.overhead = 2  

elasticsearch.log中的错误：

    {
      "error": {
        "root_cause": [
          {
            "type": "circuit_breaking_exception",
            "reason": "[parent] Data too large, data for [<http_request>] would be [3144831050/2.9gb], which is larger than the limit of [3060164198/2.8gb], real usage: [3144829848/2.9gb], new bytes reserved: [1202/1.1kb]",
            "bytes_wanted": 3144831050,
            "bytes_limit": 3060164198,
            "durability": "PERMANENT"
          }
        ],
        "type": "circuit_breaking_exception",
        "reason": "[parent] Data too large, data for [<http_request>] would be [3144831050/2.9gb], which is larger than the limit of [3060164198/2.8gb], real usage: [3144829848/2.9gb], new bytes reserved: [1202/1.1kb]",
        "bytes_wanted": 3144831050,
        "bytes_limit": 3060164198,
        "durability": "PERMANENT"
      },
      "status": 429
    }

想法：
我很难确定问题的根源。
当使用堆大小为<=8gb（在<=16gb虚拟机上）的ES群集节点时，问题变得非常明显，因此，一个明显的解决方案是增加节点的内存。
但我觉得增加内存只是掩盖了问题。

问题：
我想了解什么情况可能导致这个错误？
我应该采取什么行动才能正确处理它？
(更改断路器值、更改es.yml配置、更改/限制我的ES请求)

- dorony

---

你有触发这个断路器的示例请求吗？通常是一些带有大量子桶聚合的聚合。 - Pierre Mallet

Answer 1

由于节点的堆栈非常满，并且被断路器捕获是很好的，因为它可以防止节点遇到OOM、变得陈旧和崩溃...

Elasticsearch 6.2.0引入了断路器并在7.0.0中进行了改进。通过从ES-5.4升级到ES-7.2版本，您可以直接运行此改进。 目前我看到3种解决方案：

1. 如果可能，请增加堆大小
2. 如果可行，请减少批量请求的大小
3. 扩展您的群集，因为分片消耗了大量堆栈，没有留下任何东西来处理大型请求。更多的节点将帮助群集在更多的节点之间分配分片和请求，从而导致所有节点上的AVG堆使用率降低。

作为一个丑陋的解决方法（不能解决问题），可以在阅读和理解影响后增加限制。

- ibexit

Answer 2

我花了一些时间研究ES如何实施新的熔断机制，并试图理解为什么我们突然出现了这些错误？

1. 熔断机制自第一个版本以来就存在。
2. 从5.4版本升级到7.2版本后，我们开始遇到与其相关的问题。
3. 在7.2版本中，ES引入了一种基于实际内存使用量进行熔断的新方法(原因和方式：https://www.elastic.co/blog/improving-node-resiliency-with-the-real-memory-circuit-breaker，代码：https://github.com/elastic/elasticsearch/pull/31767)。
4. 在我们将ES升级到7.2版时，我们将JDK从8更改为11。
5. 作为我们内部升级的一部分，我们更改了jvm.options默认配置，使用具有相当新支持的G1GC GC替换了官方建议的CMS GC。
6. 考虑到以上所有因素，我发现在7.4版本中修复了关于将熔断器与G1GC GC一起使用的问题：https://github.com/elastic/elasticsearch/pull/46169。

如何解决：

1. 将配置更改回CMS GC。
2. 或者，采用修复方法。修复该错误只需要更改一些配置，可以在您的部署中轻松更改和测试。

- dorony