elasticsearch - instalar - Courier Fetch: fragmentos fracasados

instalar kibana

Question

¿Por qué recibo estas advertencias después de agregar más datos a mi búsqueda de elastics? Y las advertencias son diferentes cada vez que navego por el tablero.

"Courier Fetch: 30 de 60 fragmentos fallaron".

Más detalles:

Es un nodo único en 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"

estado del cluster

{
  "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
}

detalles del grupo

{
  "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
      }
    }
  }
}

Tengo curiosidad por el "mlockall": false porque en el yml escribí bootstrap.mlockall: true

troncos

muchas lineas como

org.elasticsearch.common.util.concurrent.EsRejectedExecutionException: rejected execution (queue capacity 1000) on org.elasticsearch.search.action.SearchServiceTransportAction$23@a9a34f5

Answer 1

Es probable que esto sea una indicación de que hay un problema con la salud de su clúster. Sin saber más acerca de su grupo, no hay mucho más que decir.

Answer 2

Estoy de acuerdo con la opinión de @ Philip, pero es necesario reiniciar elasticsearch al menos en Elasticsearch> = 1.5.2, porque puedes establecer dinámicamente threadpool.search.queue_size .

curl -XPUT http://your_es:9200/_cluster/settings
{
    "transient":{
        "threadpool.search.queue_size":10000
    }
}

Answer 3

Para mí, ajustar la búsqueda de subprocesos queue_size resolvió el problema. Probé una serie de otras cosas y esta es la que lo resolvió.

Agregué esto a mi elasticsearch.yml

threadpool.search.queue_size: 10000

y luego reinicie elasticsearch.

Razonando ... (de los documentos)

Un nodo contiene varios grupos de subprocesos para mejorar la administración del consumo de memoria de subprocesos dentro de un nodo. Muchos de estos grupos también tienen colas asociadas, lo que permite retener las solicitudes pendientes en lugar de descartarlas.

y para buscar en particular ...

Para operaciones de conteo / búsqueda. El valor predeterminado es fijo con un tamaño de int ((# de available_processors * 3) / 2) + 1, queue_size of 1000.

Para más información puede consultar los documentos de elasticsearch aquí ...

Tuve problemas para encontrar esta información, así que espero que esto ayude a otros.

Answer 4

Recibí este error cuando a mi consulta le faltaba una cita de cierre:

field:"value

En mis registros de ElasticSearch veo estas excepciones:

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"

Answer 5

Usando Elasticsearch 5.4 thread_pool tiene un guión bajo.

thread_pool.search.queue_size: 10000

Consulte la documentación en el módulo del grupo de subprocesos de Elasticsearch.

Answer 6

desde Elasticsearch> = versión 5, no es posible actualizar la configuración del clúster para thread_pool.search.queue_size usando la API _cluster / settings. En mi caso, la actualización del archivo de ElasticSearch Node yml tampoco es una opción, ya que si el nodo falla, el código de escalado automático traerá otro nodo ES con la configuración predeterminada de yml.

Tengo un clúster con 3 nodos y con 400 fragmentos primarios activos con 7 subprocesos activos para un tamaño de cola de 1000. El número creciente de nodos a 5 con configuración similar ha resuelto el problema, ya que las consultas se distribuyen horizontalmente a más nodos disponibles.