Courrier Fetch: fragments d'échec
pourquoi j'obtiens ces avertissements après avoir ajouté plus de données à mon elasticsearch? Et les avertissements sont différents chaque fois que je regarde le tableau de bord.
"Courrier Fetch: 30 à 60 éclats échoué."
Plus de détails:
c'est un noeud unique sur un CentOS 7.1
/ etc/elasticsearch / elasticsearch.yml
index.number_of_shards: 3
index.number_of_replicas: 1
bootstrap.mlockall: true
threadpool.bulk.queue_size: 1000
indices.fielddata.cache.size: 50%
threadpool.index.queue_size: 400
index.refresh_interval: 30s
index.number_of_shards: 5
index.number_of_replicas: 1
/usr/share/elasticsearch/bin/elasticsearch.in.sh
ES_HEAP_SIZE=3G
#I use this Garbage Collector instead of the default one.
JAVA_OPTS="$JAVA_OPTS -XX:+UseG1GC"
statut de la grappe
{
"cluster_name" : "my_cluster",
"status" : "yellow",
"timed_out" : false,
"number_of_nodes" : 1,
"number_of_data_nodes" : 1,
"active_primary_shards" : 61,
"active_shards" : 61,
"relocating_shards" : 0,
"initializing_shards" : 0,
"unassigned_shards" : 61
}
détails de la grappe
{
"cluster_name" : "my_cluster",
"nodes" : {
"some weird number" : {
"name" : "ES 1",
"transport_address" : "inet[localhost/127.0.0.1:9300]",
"host" : "some host",
"ip" : "150.244.58.112",
"version" : "1.4.4",
"build" : "c88f77f",
"http_address" : "inet[localhost/127.0.0.1:9200]",
"process" : {
"refresh_interval_in_millis" : 1000,
"id" : 7854,
"max_file_descriptors" : 65535,
"mlockall" : false
}
}
}
}
je suis curieux au sujet de la "mlockall" : false parce que sur le yml j'ai écrit bootstrap.mlockall: vrai
journaux
un bon nombre de lignes de la forme:
org.elasticsearch.common.util.concurrent.EsRejectedExecutionException: rejected execution (queue capacity 1000) on org.elasticsearch.search.action.SearchServiceTransportAction@a9a34f5
6 réponses
C'est probablement une indication qu'il y a un problème avec votre cluster santé. Sans en savoir plus sur votre cluster, il n'y a pas beaucoup plus à dire.
pour moi tuning la recherche threadpool queue_size résolu le problème. J'ai essayé un certain nombre d'autres choses et c'est celui qui a résolu.
j'ai ajouté ceci à mon elasticsearch.yml
threadpool.search.queue_size: 10000
puis redémarré elasticsearch.
Raisonnement... (à partir de la doc)
un noeud contient plusieurs pools de threads afin d'améliorer la façon dont les threads la consommation de mémoire est gérée à l'intérieur d'un noeud. Beaucoup de ces piscines aussi avoir des files d'attente associées avec eux, ce qui permet aux requêtes pendantes d'être tenu au lieu de jeté.
et pour la recherche en particulier...
pour les opérations de comptage / recherche. Par défaut fixe avec une taille de int((# des processeurs disponibles * 3) / 2) + 1, file d'attente de 1000.
Pour plus d'informations vous pouvez vous référer à la elasticsearch docs ici...
j'ai eu du mal à trouver cette information alors j'espère que cela aidera les autres!
en utilisant Elasticsearch 5.4 thread_pool a un underscore it it.
thread_pool.search.queue_size: 10000
voir la documentation à Elasticsearch Thread Pool documentation du module
je suis d'accord avec l'opinion de @Philip, mais il est nécessaire de redémarrer elasticsearch au moins sur Elasticsearch > = 1.5.2, parce que vous pouvez dynamiquement définir threadpool.search.queue_size.
curl -XPUT http://your_es:9200/_cluster/settings
{
"transient":{
"threadpool.search.queue_size":10000
}
}
à partir de Elasticsearch >= version 5, il n'est pas possible pour mettre à jour les paramètres du cluster pour thread_pool.rechercher.queue_size utilise l'API _cluster/settings. Dans mon cas, la mise à jour du fichier YML du noeud ElasticSearch n'est pas non plus une option car si le noeud échoue, le code de mise à l'échelle automatique amènera d'autres noeuds ES avec les paramètres YML par défaut.
j'ai un cluster avec 3 noeuds et ayant 400 fragments primaires actifs avec 7 fils actifs pour la taille de la file d'attente de 1000. Augmentation du nombre de noeuds à 5 avec une configuration similaire a résolu le problème car les requêtes sont distribuées horizontalement à d'autres noeuds disponibles.
j'ai eu cette erreur quand ma requête manquait une citation finale:
field:"value
Dans mon ElasticSearch logs je vois ces exceptions:
Caused by: org.elasticsearch.index.query.QueryShardException:
Failed to parse query [field:"value]
...
Caused by: org.apache.lucene.queryparser.classic.ParseException:
Cannot parse 'field:"value': Lexical error at line 1, column 13.
Encountered: <EOF> after : "\"value"