Node processors

Estoy teniendo algunos rechazos a la hora de lanzar un bulk contra un elàstic y se producen con más frecuencia desde que subimos de versión de una versión 6 a una 7, revisando settings y mappings de todo el clúster, de una versión anterior a la nueva, vemos que el processors en la versión 6 tiene un valor de 16, mientras que en la versión 7 tiene un valor de 1.

La query que he lanzado en ambos clusters antiguo y nuevo es: _cluster/settings?include_defaults

"processors" : "16",Old setting cluster default
"processors" : "1", New setting cluster default

Alguien sabe como poder cambiar este valor, si este valor se puede cambiar en caliente o si es un valor que se ha de cambiar al arrancar el elàstic?

Bienvenido Cristian!

Parece que Elasticsearch no detecta el número de CPUs bien en el nuevo cluster.
Todos los thread pools se basan en esto, entonces tienes razón en mirar este punto.

De hecho mejor que solo cambiar el parámetro deberías investigar porque no se detecta más de un core en el nuevo cluster.

Para cambiar el parámetro hace falta editar elasticsearch.yml con node.processors puesto al número de cores disponibles (Thread pools | Elasticsearch Guide [7.x] | Elastic).

1 Like

Muchas gracias por responder, pues tengo que revisar porqué no acaba de coger el número de CPUs disponibles.

Aquí el tema és que corremos el clúster de elastic a través de kubernetes, y este clúster dispone de varios nodos con diferentes roles y exactamente no sé en donde indicar este valor para processors.

Seguiré revisando para ver cómo lo puedo modificar.

Gracias

Ah mira, pensaba que puede ser esto cuando vi algunos threads aqui.

A ver si pueden ser util: Question about threadpools y Elasticsearch processor environment variable

Parece que por lo menos uno utiliza Elastic Cloud on Kuberetes (ECK - Elastic Cloud on Kubernetes [1.5] | Elastic) pero al final deberia ser la misma cosa en otros entornos de Kubernetes.

Suerte y si no lo consigues facilmente dejanos unos detalles para seguir mirandolo.

Hi,

I'm sorry to post in english here but i don't know spanish. I saw that Janko mentioned my posts so i wanted to share something here. We're managing a cluster on kubernetes as well, i also have a small elastic stack on kubernetes for testing purposes. I have tried this and processor count changed accordingly, but since it is a small cluster i couldnt do any proper testing on it with continuous data flow.

Here's the snippet added on stack yaml file under elasticsearch:

#        resources:
#          requests:
#            memory: 768Mi
#            cpu: 2
#          limits:
#            memory: 1Gi
#            cpu: 4

after adding these to the stack yaml i could see the number that is set above next to the processor count in elasticsearch(kibana dev tools to be exact). If you can test that out and give feedback it will be much appreciated.

2 Likes

Hola nyquillus

Sí, al final es como tenemos configurado en los yamls, y ya se detectan correctamente el número de procesadores.

"processors": "6",

El clúster que tenemos montado tiene los siguientes roles y nodos.

15 nodos de todo el clúster.

3 nodos máster
3 nodos con rol cliente
9 nodos de datos

Las peticiones entrantes del cliente llegan a través de los nodos cliente. Por algún motivo el número de procesadores del clúster se basa en el número de procesadores establecidos en el yml de los nodos cliente.

Por otra parte.

Una vez que el clúster ha detectado correctamente el número de procesadores, el thread_pool ha cambiado como era de esperar, sin embargo para el write el tamaño de la cola queue_size coloca automáticamente un valor de 200, ¿se puede ampliar este tamaño de la cola a 10000 como en las últimas versiones de elastic?

Versión de elastic que utilizamos v7.6.2:

    "write": {
    "queue_size": "200",
    "size": "6"

Hemos visto que en las versiones 7.10.1 el tamaño de esta cola por defecto es de 10000

La pregunta es, ¿Podemos subir el tamaño de la cola de 200 (por defecto) a 10000 en nuestra versión 7.6.2 como en las últimas versiones de elastic? Sí es que sí, necesitaríamos ajustar algún parámetro adicional?

Muchas gracias

Hi Cristian,

I'm not sure about previous versions but I'm using 7.7.0 version. And in 7.7.0 you can add something like this under the elasticsearch environment:

thread_pool.write.queue_size=<value>

As far as I know, 200 is the default value for write queue size. At least it is the default value for my cluster. Some thread pools can be configured and some have absolute values.

You can also change the size of specific thread pools by adding something like below to the elasticsearch environments again:

thread_pool.write.size=<value>

But as i said before, I'm not entirely sure about version 7.6. But it seems to work in 7.7.0.

2 Likes

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.

Siento la demora, no vi las respuestas antes

Lamentablemente sin subir a versiones mas recientes esto normalmente causa problemas.
A partir de la versión 7.7 hemos cambiado mucho que usa heap de la JVM (Disminuye de forma significativa tu uso de memoria heap de Elasticsearch | Elastic Blog) y por esto podíamos cambiar la configuración de las colas.

Otra cosa en la misma versión cambiábamos el garbage colector de la JVM a G1GC (Garbage First Garbage Collector Tuning) en los releases bundled con JAVA. Esto significa un poco más de uso de la CPU durante casi todo el tiempo, pero no vemos paradas enteras durante el garbage collection como con el anterior CMS.

Así os puede servir probar una versión más reciente de Elasticsearch.