Explicación por qué el rendimiento de Elastic con un(1) nodo de datos es mejor que dos?


(Alex Zuñiga) #1

Saludos a toda esta comunidad de Elastic, tengo una grande incertidumbre la cual espero poder resolver con la ayuda de sus conocimientos, y la cual paso a exponer a continuación. Tengan en cuenta que hago esta consulta porque recién empiezo con Elastic.

Bien, tengo un clúster Elastic con 3 nodos, todos con diferentes características:

Nodo1 (solo maestro):

  • Procesador Intel® Core™2 Duo CPU E7500 @ 2.93GHz × 2
  • RAM 4GB
  • 400GB Disco
  • Ubuntu 16.04 LTS de 64 bits

Nodo2 (solo datos):

  • Procesador Intel® Core™2 Duo CPU E7500 @ 2.93GHz × 2
  • RAM 4GB
  • 400GB Disco
  • Ubuntu 12.04 LTS de 32 bits

Nodo3 (solo datos):

  • Procesador Intel® Core™ i5 CPU M 430 @ 2.27GHz × 4
  • RAM 4GB
  • 50GB Disco(porque esta particionado)
  • Ubuntu 16.04 LTS de 64 bits

Cabe recalcar que el proyecto que estoy realizando es de la universidad pero no sé como explicar lo que a continuación detallo. El clúster funciona correctamente tanto en el indexado y las consultas que hago. Tengo almacenado cerca de 141 millones de documentos (bien balanceado en shards para ambos nodos de datos, con 5 shards primarios y 1 shard de replica para garantizar la disponibilidad), para la manipulación y carga de datos estoy utilizando una aplicación realizada en Nodejs, hasta ahí todo excelente. Mi docente me ha pedido que realice pruebas de rendimiento del clúster, con el objeto de comprobar que el clúster Elastic tiene mejor rendimiento bajo la premisa de "con más nodos, mejor tiempos de respuesta".
Al hacer las respectivas pruebas(hacia la misma URL de la app), tengo 3 casos.

  1. Con todos los nodos activos (Nodo1, Nodo2, Nodo3).
  2. Sólo con Nodo1 y Nodo2 activos.
  3. Sólo con Nodo1 y Nodo3 activos.

Una vez realizadas las pruebas utilizando JMeter con un solo hilo de ejecución, tengo las siguientes conclusiones:

  • Con todos los nodos en ejecución, obtengo tiempos de respuesta(19892 ms) un tanto altos(debido a la alta cantidad de datos, la dificultad de la consulta y los limitados recursos que dispongo, eso no es problema) pero las consultas funcionan correctamente.

  • Sólo con Nodo1 y Nodo2, la media de los tiempos de respuesta(55471 ms) son mucho más altos, comprobando así la premisa mencionada por mi docente.

  • PERO ES EN ESTE PUNTO DONDE NO CABE MI LÓGICA. Al hacer las pruebas sólo con Nodo1 y Nodo3, la media de tiempos de respuesta(14377 ms) son MENORES a los de las pruebas de los dos primeros casos.

AYUDA: Necesito saber porque sucede esto ?

Se supone, que los tiempos deberían ser parecidos como en el segundo caso, y mayores a los del primer caso, ya que como es conocido, al igual que el segundo caso solo esta trabajando UN sólo nodo de datos.

Manejo una hipótesis pero no creo que sea del todo cierta, y es que, este "fenómeno" podría darse debido a los recursos del Nodo3, en cuanto a procesador se refiere es "un tanto mejor", ya que es un i5 de 4 núcleos, pero no estoy seguro de poder explicar.

De antemano gracias.


(Gabriel Moskovicz) #2

Hola @pinky.floyano,

Muy bueno el detalle, y me queda claro el problema. Básicamente el took time varia bastante segùn los nodos disponibles. Aquí te detallo lo que pienso que sucede:

Caso 2- nodo1 y 2 unicamente

En este caso tienes un nodo que no es poderoso, haciendo consultas y demora casi 55 segundos. Esto es esperado seguramente por falta de cores.

Con todos los nodos

Aquí los shards están distribuidos, entonces los tiempos de respuesta podrían ser mas mejores ya que las consultas son distribuidas. Hasta Aquí todo tiene lógica.

Solo nodo1 y 3

Aquí lo que sucede es que hay casi el mismo tiempo de respuesta que con todos los nodos. Probablemente como tienes 5 shards lo que esta impactando Aquí son los Search Threads: https://www.elastic.co/guide/en/elasticsearch/reference/5.5/modules-threadpool.html. Por defecto ES crea int((# of available_processors * 3) / 2) + 1 threads para hacer búsquedas. Y cada shard va a ser una búsquedas distinta. Entonces cuantos mas cores, mas hilos de búsquedas para esto.

Puedes chequear cuantos cores cada nodo tiene con esto:

http://localhost:9200/_nodes?pretty&filter_path=nodes.*.os.available_processors,nodes.*.os.allocated_processors

Tambien puedes chequear cuantos threads crea para búsqueda en cada nodo así:

http://localhost:9200/_nodes?pretty&filter_path=nodes.*.thread_pool.search.min

Esto te data los cores de la maquina, y luego la cantidad de threads para cada nodo. Como cada shard se hace en paralelo, cuantos mas cores, mas hilos, y mas búsquedas concurrentes. Entonces menor el tiempo de ejecución. Si estas mas tranquilo chequeando los hilos, lo que puedes hacer es correr la prueba y guardar cada 1 segundo el resultado de:

http://localhost:9200/_nodes/hot_threads?threads=100

Esto te va a retornar los threads the están activos para ese momento. Ahi comprobar que según el nodo, la cantidad total de [search] que se pueden encontrar.

Saludos!

--Gabriel Moskovicz


(Alex Zuñiga) #3

Hola @gmoskovicz.
Gracias por la pronta respuesta, voy a verificar con las sugerencias que me diste para hacer un nuevo comentario acerca de los resultados. Analizando lo que me dices, no estaba tan lejos, aunque no sabía como explicarlo. Gracias una vez más.

Saludos.


(Gabriel Moskovicz) #4

Vale,

Saludos!


(Alex Zuñiga) #5

Hola @gmoskovicz.

Que software podría utilizar para hacer pruebas de rendimiento de mi clúster, es decir necesito saber cual es la capacidad real en cuanto a procesamiento tiene mi clúster. También, en cuestión de porcentajes necesito saber cuanto disminuye o aumenta, al quitar o agregar un nodo, respectivamente, ya sean estos de idénticas o diferentes caracteristicas. Son pruebas básicamente que tengo que realizar. Estoy consumiendo los datos de ES con una app hecha en Node.js. Que software me podrías recomendar para este tipo de pruebas ?

Saludos.


(Gabriel Moskovicz) #6

Hola Pinky,

Lamentablemente no tenemos un software especifico. Hay gente que utiliza su propio aplicativo que desarrollan, otros Jmeter, tambien Logstash para ver la carga, o sino https://github.com/elastic/rally . Pero no son simples de utilizar, asi que tienes que sentirte comodo con cualquiera de estos.

Saludos!
--Gabriel


(Alex Zuñiga) #7

Muchas gracias Gabriel.


(system) #8

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