web-dev-qa-db-fra.com

Disjoncteur Elasticsearch 7.x - Données trop volumineuses - Dépannage

Le problème:
Depuis la mise à niveau de ES-5.4 vers ES-7.2, j'ai commencé à recevoir des erreurs "données trop volumineuses", en essayant d'écrire des requêtes en masse simultanées (ou/et des requêtes de recherche) à partir de mon multi-thread Java (en utilisant le client elasticsearch-rest-high-level-client-7.2.0.jar Java) à un cluster ES de 2 à 4 nœuds.

Ma configuration 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

L'erreur de 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
    }

Pensées:
J'ai du mal à identifier la source du problème.
Lorsque vous utilisez des nœuds de cluster ES avec une taille de segment de <= 8 Go (sur une VM <= 16 Go), le problème devient très visible, donc, une solution évidente consiste à augmenter la mémoire des nœuds.
Mais je pense que l'augmentation de la mémoire ne fait que cacher le problème.

Questions:
J'aimerais comprendre quels scénarios auraient pu conduire à cette erreur?
et quelles mesures puis-je entreprendre pour le gérer correctement?
(modifier les valeurs du disjoncteur, modifier la configuration es.yml, modifier/limiter mes demandes ES)

elasticsearchelasticsearch-java-apielasticsearch-7
3
dorony

J'ai donc passé un certain temps à rechercher comment ES a mis en œuvre exactement le nouveau mécanisme de disjoncteur, et j'ai essayé de comprendre pourquoi nous obtenons soudainement ces erreurs?

  1. le mécanisme de disjoncteur existe depuis les toutes premières versions.
  2. nous avons commencé à rencontrer des problèmes lors du passage de la version 5.4 à 7.2
  3. dans la version 7.2, ES a introduit une nouvelle façon de calculer la coupure de circuit: la coupure de circuit basée sur l'utilisation réelle de la mémoire (pourquoi et comment: https://www.elastic.co/blog/improving-node-resiliency-with -le-disjoncteur-mémoire-réelle , code: https://github.com/elastic/elasticsearch/pull/31767 )
  4. Dans notre mise à niveau interne d'ES vers la version 7.2, nous avons changé le jdk de 8 à 11.
  5. également dans le cadre de notre mise à jour interne, nous avons changé la configuration par défaut de jvm.options, en remplaçant le GC CMS officiel recommandé par le GC G1GC qui a un support relativement nouveau par elasticsearch.
  6. compte tenu de tout ce qui précède, j'ai trouvé ce bug qui a été corrigé dans la version 7.4 concernant l'utilisation du disjoncteur avec le GC G1GC: https://github.com/elastic/elasticsearch/pull/46169

Comment réparer:

  1. changez la configuration en CMS GC.
  2. ou, prenez le correctif. le correctif du bogue est juste un changement de configuration qui peut être facilement modifié et testé dans notre déploiement.
1
dorony