¿Qué factores afectarán el rendimiento del servidor de base de datos MySQL?
La banda ancha de Internet también tendrá un impacto.
La red es una parte importante de la infraestructura de la base de datos. Sin embargo, las pruebas comparativas de rendimiento generalmente se realizan en una computadora local donde el cliente y el servidor están uno al lado del otro. Esto se hace para simplificar la estructura y excluir múltiples variables (la parte de la red), pero también ignoramos el impacto de la red en el rendimiento. Para grupos de productos como MySQL Group Replication, la creación de redes es aún más importante. Este artículo cubrirá la configuración de red. Estas configuraciones son simples y triviales, pero son los pilares para comprender mejor los efectos de configuraciones de red complejas.
Para la instalación utilizaré dos servidores bare metal conectados a través de una red dedicada de 10 Gb. Usaré el comando ethtool-s eth1 speed1000duplex full autoneg off para cambiar la velocidad de la interfaz de red y simular una red de 1 Gb.
Ejecutaré un punto de referencia simple: sysbench oltp_read_only --mysql-ssl=on --mysql-host=172.16.0.1 --tables=20 --table-size=10000000 --mysql-user = sbtest - --mysql-password=sbtest --threads=$i --time=300 --report-interval=1 --rand-type=pareto
El número de subprocesos en ejecución varía de 1 a 2048. Todos los datos caben en la memoria: innodb_buffer_pool_size es lo suficientemente grande. Por lo tanto, la carga de trabajo consume mucha CPU en la memoria: no hay sobrecarga de E/S. SO: Ubuntu 16.04
N1 Benchmark - Ancho de banda de red En el primer experimento, compararé una red de 1 Gb con una red de 10 Gb. Está claro que el rendimiento de la red de 1Gb es el cuello de botella aquí, y si pasamos a una red de 10Gb podemos mejorar significativamente nuestros resultados. Para demostrar que la red de 1Gb es el cuello de botella, podemos comprobar el gráfico de tráfico de red en PMM (herramienta de código abierto de percona para monitorización y gestión de bases de datos):
Podemos ver que obtenemos 116 MiB/s (o 928 Mb/s), que está muy cerca del ancho de banda de la red. Pero ¿qué podemos hacer si nuestra infraestructura de red está limitada a 1Gb?
N2 Benchmark -- Compresión de protocolo Hay una característica en el protocolo MySQL que permite ver la compresión de los intercambios de red entre el cliente y el servidor: -- Veamos cómo afecta a nuestros resultados.
Este es un resultado interesante. La compresión de protocolos en realidad ayuda a mejorar los resultados cuando utilizamos todo el ancho de banda de red disponible.
Pero este no es el caso de las redes 10G. Los recursos de CPU necesarios para la compresión/descompresión son un factor limitante; con la compresión, el rendimiento es en realidad la mitad de lo que sería sin compresión. Ahora hablemos del cifrado de protocolos y de cómo el uso de SSL afecta los resultados.
N3 Benchmark - Cifrado de red
Para redes de 1 Gb, el cifrado SSL muestra cierta pérdida (alrededor del 10% de un solo subproceso), pero aparte de eso, nuevamente nos encontramos con problemas de límite de ancho de banda. También vemos escalabilidad con una gran cantidad de subprocesos, lo que es aún más evidente en las redes de 10 Gb. En una red 10G, el protocolo SSL no escala después de usar 32 subprocesos. De hecho, esto parece ser un problema de escalabilidad con OpenSSL 1.0 que MySQL utiliza actualmente. En nuestros experimentos, descubrimos que OpenSSL 1.1.1 proporciona una mejor escalabilidad, pero lograr esto requiere una compilación especial de MySQL a partir del código fuente vinculado a OpenSSL 1.1.1. Como no tenemos binarios de producción, no los muestro aquí.
Conclusión
1. El rendimiento y la utilización de la red afectarán el rendimiento de las aplicaciones generales.
2. Compruebe si ha alcanzado el límite de ancho de banda de la red.
3. Si estás limitado por el ancho de banda de la red, la compresión del protocolo puede mejorar los resultados, pero si no, puede empeorar la situación.
4.El cifrado SSL tiene cierta penalización (alrededor del 10 %) cuando se utiliza una pequeña cantidad de subprocesos, pero no se adapta a cargas de trabajo elevadas y simultáneas. 5.