En este blog, quiero evaluar las capacidades de Group Replication Scaling en los casos en que aumentamos la cantidad de nodos y las conexiones de los usuarios.
Para las pruebas, 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.
Especificaciones de hardware:
|
sistema | supermicro; SISTEMA–F619P2–RTN; v0123456789 (Otro) Servicio Etiqueta | S292592X0110239C Plataforma | linux Gratis | ubuntu 18.04.4 LTS (biónico) Núcleo | 5.3.0–42–genérico Arquitectura | UPC = 64–pequeño, sistema operativo = 64–pequeño enhebrar | NPTL 2.27 SELinux | No SELinux detectado virtualizado | No virtualización detectado # Procesador ###################################### ####### ################## ## Procesadores | físico = 2, centro = 40, virtual = 80, hiperprocesamiento = sí Modelos | 80 x Intel(R) Xeon(R) Oro 6230 UPC @ 2,10 GHz cachés | 80×28160 KB # Memoria ####################################### ###### ################### #### Total | 187,6G |
Para el punto de referencia, utilicé la base de datos sysbench-tpcc 1000W preparada como:
|
./tpcc.lua –mysql–anfitrión=172.16.0.11 –mysql–usuario=prueba –mysql–contraseña=prueba –mysql–base de datos=prueba –hora=300 –alambres=64 –reporte–intervalo=1 –mesas=10 –escala=100 –base de datos–conductor=mysql –usar_fk=0 –force_pk=1 –nivel_trx=RC Se preparan |
Las configuraciones sin procesar, los scripts y los resultados están disponibles en nuestro sitio web GitHub.
La carga de trabajo es «en memoria», lo que significa que los datos (alrededor de 100 GB) deben ingresarse en innodb_buffer_pool (también 100 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 en 3 nodos.
Es interesante ver cómo los resultados se vuelven inestables cuando aumentamos el número de filamentos. Para ver más detalle, dibuje el gráfico con las escalas individuales para cada juego de filamentos:
Como podemos ver, hay muchas variaciones para los filamentos a partir de 64. Verificamos los filamentos 64 y 128 con una resolución de 1 segundo.
Parece que están ocurriendo procesos cíclicos, con caídas periódicas a 0. Parece estar relacionado con este error.
3 nudos contra 5 nudos
Ahora comprobamos el rendimiento por debajo de 5 nudos (en comparación con 3 nudos)
No parece haber una gran diferencia; solo cuando hay resultados estables con 8-16 filamentos podemos ver una disminución para los nodos 5. Para los filamentos 64 a 256, cuando prevalece la variación, es difícil notar la diferencia.
Conclusiones
Según mis hallazgos, parece que Group Replication maneja bastante bien los nodos adicionales en esta carga de trabajo, pero varios subprocesos son problemáticos.
Estoy abierto a sugerencias sobre cómo puede mejorar el rendimiento de varios cables.
