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

Question

问题：
自从从 ES-5.4 升级到 ES-7.2 后，当我尝试从我的多线程 Java 应用程序（使用elasticsearch-rest-high-level-client-7.2.0.jarjava 客户端）写入并发批量请求（或/和搜索请求）时，我开始收到“数据太大”错误到 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 的 ES 集群节点（在 <=16gb vm 上）时，问题变得非常明显，因此，一个明显的解决方案是增加节点的内存。
但我觉得增加内存只能隐藏问题。

问题：
我想了解哪些情况会导致此错误？
我可以采取什么措施来正确处理它？
（更改断路器值，更改 es.yml 配置，更改/限制我的 ES 请求）

Answer 1

原因是节点的堆已经满了，被断路器捕获是很好的，因为它可以防止节点运行到 OOM 中，变得陈旧和崩溃......

Elasticsearch 6.2.0引入了断路器并在7.0.0 中对其进行了改进。随着从 ES-5.4 到 ES-7.2 的版本升级，您将直接体验到这一改进。

到目前为止，我看到了 3 个解决方案：

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

作为一种丑陋的解决方法（不解决问题），可以在阅读并理解其含义后增加限制：

Answer 2

所以我花了一些时间研究 ES 到底是如何实现新的断路器机制的，并试图理解为什么我们会突然出现这些错误？

1. 断路器机制自第一个版本以来就存在。
2. 从版本 5.4 迁移到 7.2 时，我们开始遇到相关问题
3. 在 7.2 版本中，ES 引入了一种计算熔断的新方法：基于实际内存使用情况的熔断（原因和方式：https ://www.elastic.co/blog/improving-node-resiliency-with-the-real -内存电路断路器，代码：https ://github.com/elastic/elasticsearch/pull/31767 ）
4. 在我们内部升级ES到7.2版本时，我们将jdk从8更改为11。
5. 另外，作为内部升级的一部分，我们更改了 jvm.options 默认配置，将官方推荐的 CMS GC 替换为 G1GC GC，后者由 Elasticsearch 提供了相当新的支持。
6. 考虑到上述所有内容，我发现这个错误在 7.4 版本中修复了有关断路器与 G1GC GC 一起使用的问题：https ://github.com/elastic/elasticsearch/pull/46169

怎么修：

1. 将配置更改回 CMS GC。
2. 或者，采取修复措施。该错误的修复只是一个配置更改，可以在您的部署中轻松更改和测试。