web-dev-qa-db-ja.com

Elasticsearch 7.x回路ブレーカー-データが大きすぎる-トラブルシューティング

問題:
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クラスタノードを<= 8gbのヒープサイズで(<= 16gbのvmで)使用すると、問題が非常にわかりやすくなるため、1つの明らかな解決策はノードのメモリを増やすことです。
しかし、メモリを増やすことは問題を隠すだけだと感じています。

質問:
このエラーの原因となったシナリオを教えてください。
それを適切に処理するためにどのようなアクションを実行できますか?
(サーキットブレーカー値の変更、es.yml設定の変更、ESリクエストの変更/制限)

3
dorony

そこで、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のデフォルト構成を変更し、公式の推奨CMS GCをG1GC GCに切り替えました。これには、elasticsearchによるかなり新しいサポートがあります。
  6. 上記すべてを考慮して、G1GC GCと一緒にサーキットブレーカーを使用することに関して、バージョン7.4で修正されたこのバグを見つけました: https://github.com/elastic/elasticsearch/pull/46169

直し方:

  1. 構成をCMS GCに戻します。
  2. または、修正を行います。バグの修正は、私たちのデプロイメントで簡単に変更およびテストできる構成変更です。
1
dorony