Evaluación de la escala de replicación grupal para cargas de trabajo Bound I/O

En esta publicación, quiero evaluar las capacidades de Group Replication Scaling en los casos en que aumentamos la cantidad de nodos y las conexiones de los usuarios. Si bien esta instalación es idéntica a la de mi publicación «Evaluación de las capacidades de escalado de replicación de grupo en MySQL», en este caso, estoy usando una carga de trabajo enlazada de E/S.

Para esta prueba, implementaré servidores bare metal de múltiples nodos, donde cada nodo y cliente están dedicados a un servidor individual y conectados entre sí mediante una red de 10 Gb.

Además, utilizo la configuración de replicación de grupo de 3 y 5 nodos. En ambos casos, la carga se dirige solo a UN nodo, pero espero que con cinco nodos haya una sobrecarga adicional debido a la replicación.

Especificaciones de hardware:

Para el punto de referencia, utilicé la base de datos sysbench-tpcc 1000W preparada como:

Las configuraciones sin procesar, los scripts y los resultados están disponibles en nuestro sitio web GitHub. La carga de trabajo está ligada a IO, es decir, los datos (alrededor de 100 GB) exceden innodb_buffer_pool (incluso 25 GB).

Para la versión de MySQL, usé MySQL 8.0.19.

Resultados

Repasemos los resultados que tuve. Primero, echemos un vistazo a cómo cambia el rendimiento cuando aumentamos los subprocesos de usuario de 1 a 256 por cada tres nodos.

Escalado de replicación de grupo

Es interesante ver como los resultados se vuelven inestables cuando aumentamos el número de filamentos. Para más detalles, dibuje el gráfico con las escalas individuales para cada juego de filamentos:

Como podemos ver, hay muchas variaciones para los filamentos que comienzan con 64. Verificamos los filamentos 64 y 128 con una resolución de 1 segundo.

Parece que los procesos cíclicos están en progreso, con caídas periódicas a 0, que pueden vincularse a este error.

3 nudos contra 5 nudos

Ahora echemos un vistazo al rendimiento en cinco nodos (en comparación con los nodos 3):

No parece haber una gran diferencia, y solo cuando hay resultados estables con 8-16 filamentos podemos ver una disminución de cinco nudos. Para los filamentos 64 a 256, cuando prevalece la variación, es difícil notar la diferencia.

Tratamiento de tarifa de entrada sostenida

Dado que hay caídas ocasionales en los cables altos, quería verificar cómo manejará el clúster la tasa de entrada sostenida, que es aproximadamente el 75 % del rendimiento promedio. Para esto, probaré en 64 subprocesos con una tasa de entrada de 3100 transacciones por segundo (el rendimiento promedio para tres nodos con 64 subprocesos es de 4100 tps).

Primero, veamos cómo el sistema administra el rendimiento.

Podemos ver que la mayor parte del tiempo, el rendimiento es de 3100 tps, pero todavía hay caídas y saltos intermitentes con el retorno a la tasa de entrada normal. Ahora, más interesante: ¿cómo afecta la latencia?

Si bien, nuevamente, la mayor parte del tiempo, el sistema muestra alrededor de 25 ms, el 95 % del tiempo de respuesta, durante las caídas, salta a 1400 ms, lo que obviamente resulta en una aplicación y una experiencia de usuario deficientes.

Conclusiones

Según mis hallazgos, parece que en el caso de las cargas de trabajo de E/S, Group Replication también maneja bastante bien los nodos adicionales en esta carga de trabajo, pero varios subprocesos siguen siendo problemáticos. Estoy abierto a sugerencias sobre cómo puede mejorar el rendimiento de múltiples subprocesos, así que deje sus comentarios a continuación.

Author: Ing. Luis

A lo largo de conocer Windows y otros sistemas operativos me eh encontrado con diversos tipos de error, ahora brindo soluciones según mi experiencia-

Deja un comentario