Elasticsearch 7.x 断路器 - 数据太大 - 故障排除答案

【问题标题】：Elasticsearch 7.x circuit breaker - data too large - troubleshootElasticsearch 7.x 断路器 - 数据太大 - 故障排除
【发布时间】：2020-10-14 23:25:21
【问题描述】：

问题：
自从从 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
    }

想法：
我很难确定问题的根源。
当使用但我觉得增加内存只会隐藏问题。

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

【问题讨论】：

您有触发此断路器的示例请求吗？通常它的一些聚合具有巨大的子桶聚合。

标签： elasticsearch elasticsearch-java-api elasticsearch-7

【解决方案1】：

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

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

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

尽可能增加堆大小
如果可行，减少批量请求的大小
在分片消耗大量堆时横向扩展您的集群，没有任何东西可以处理大请求。更多节点将有助于集群在更多节点之间分配分片和请求，从而降低所有节点上的 AVG 堆使用率。

作为一种丑陋的解决方法（不解决问题），可以增加限制after reading and understanding the implications：

【讨论】：

【解决方案2】：

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

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

如何解决：

将配置改回 CMS GC。
或者，进行修复。该错误的修复只是一个配置更改，可以在您的部署中轻松更改和测试。

【讨论】：