Skip navigation links
16.8 Limitaciones conocidas de MySQL Cluster »
Section Navigation      [Toggle]

16.7.2. Entender el impacto de interconexiones de nodos

El proceso ndbd tiene un número de constructores simples que se usan para acceder a los datos en MySQL Cluster. Hemos creado un benchmark sencillo para comprobar el rendimiento de cada uno de ellos y los efectos en el rendimiento de varias interconexiones.

Hay cuatro métodos de acceso:

  • Acceso por clave primaria

    Este es el acceso simple a un registro a través de su clave primaria. Es el caso más sencillo en que sólo se accede a un registro a la vez, que significa que el coste total de preparar un número de mensajes TCP/IP y un número de costes para cambio de contexto se envían mediante esta simple petición. En el caaso en que se envían accesos a varias claves primarias en un proceso batch estos accesos comparten el coste de preparar los mensajes TPC/IP necesarios y los cambios de contexto. Si los mensajes TCP/IP son para destinaciones distintas, se debe preparar mensajes adicionales.

  • Acceso por clave única

    Son similares a los anteriores, con la excepción que los accesos por clave única se ejecutan como lecturas en una tabla índice seguidos por su acceso por clave primaria a la tabla. Sin embargo, sólo se envía una petición desde el servidor MySQL, y la lectura de la tabla índice es tratada por ndbd. Estas peticiones también se benefician del uso de batch.

  • Escaneo de toda la tabla

    Cuando no existen índices para la búsqueda en una tabla, se realiza un escaneo completo. Se envía como petición úncia al proceso ndbd , que divide el escaneo de tabla en un conjunto de escaneos paralelos en todos los procesos ndbd del proceso. En futuras versiones de MySQL Cluster, un nodo SQL será capaz de filtrar algunos de estos escaneos.

  • Escaneo de rangos usando índices ordenados

    Cuando se usa un índice ordenado, realiza un escaneo igual que lo hace un escaneo de tabla completo, excepto que escanea sólo los registros en el rango usados por la consulta transmitidas por el MySQL server (nodo SQL).

Para chequear el rendimiento base de estos métodos de acceso hemos desarrollado un conjunto de benchmarks. Uno de ellos testReadPerf, testea accesos simple y en batch por clave primaria y única. Este benchmark también mide el coste de preparar los escaneos de rango ejecutando escaneos que retornan un único registro. Hay una variante de este benchmark que usa un escaneo de rango para recibir un batch de registros.

De este modo, podemos determinar el coste de accesos de clave única y accesos de escaneo de registro simple, así como medir el impacto del medio de comunicación usdo, en métodos de acceso base.

En nuestros tests, ejecutamos los benchmarks para transporters normales usando sockets TCP/IP sockets y una configuración similar usando sockets SCI. Las figuras posteriores son pequeños accesos de 20 registros por acceso. Las diferencias entre accesos seriales y mediante batch se decrementan en un factor de 3 a 4 usando registros de 2 kB. SCI Sockets no se testearon con registros de 2 kB. Los tests se realizaron en un cluster con 2 nodos de datos en 2 máquinas de CPU dual equipadas con procesadores AMD MP1900+ . 

Tipo de acceso:         	TCP/IP sockets           SCI Socket
Acceso Serial clave primaria:   400 microsegundos         160 microsegundos
Acceso Batched clave primaria    28 microsegundos          22 microsegundos
Acceso Serial indice unico:     500 microsegundos         250 microsegundos
Acceso Batched indice unico:     70 microsegundos          36 microsegundos
Acceso Indexado igualdad:      1250 microsegundos         750 microsegundos
Índice rango:                    24 microsegundos          12 microsegundos

También realizamos otro conjunto de tests para chequear el rendimiento de los SCI Sockets vis-à-vis contra el SCI transporter, y ambos comparados con el TCP/IP transporter. Todos estos tests usaron acceso por clave primaria de forma serial o multi-flujo, o multi-flujo y batch.

Los tests mostraron que los sockets SCI eran 100% más rápido que TCP/IP. El transporter SCI era más rápido en la mayoría de casos comparado con los sockets SCI. Un caso notable ocurrión con muchos flujos en el programa de test, que mostró que el tramporter SCI no funcionaba muy bien usado por el proceso mysqld.

Nuestra conclusión global fue que, para la mayoría de benchmarks, usando sockets SCI mejoraba el rendimiento aproximadamente 100% sobre TCP/IP, excepto en raros casos cuando el rendimiento de la configuración no es un tema importante. Esto puede ocurrir cuando los filtros de escaneo toman la mayoría del tiempo de proceso o cuando los procesos batchs muy grandes de accesos por clave primaria se realizan. En tal caso, el proceso de la CPU en los procesos ndbd es la mayor parte del proceso.

Usar el transporter SCI en lugar de SCI Sockets sólo es de interés en comunicación entre procesos ndbd. Usar el SCI transporter también es sólo de interés si una CPU puede dedicarse al proceso ndbd ya que el SCI transporter se asegura que su proceso nunca estará en espera. Es importante asegurar que la prioridad del proceso ndbd está configurada de tal modo que el proceso no pierde prioridad debido a ejecutarse durante un periodo de tiempo extendido, como puede pasar por bloqueo de procesos por la CPU en Linux 2.6. Si tal configuración es posible, entonces el proceso ndbd se beneficiará de un 10-70% comparado con usar SCI sockets. (Las diferencias más grandes se verán al realizar actualizaciones y probablemente en escaneos paralelos también

Hay otras implementaciones de socket para clusters de máquinas, incluyendo Myrinet, Gigabit Ethernet, Infiniband y la interfaz VIA . Hemos testeado MySQL Cluster hasta ahora sólo con SCI sockets.También incluímos documentación acerca de cómo preparar SCI sockets usando TCP/IP ordinario para MySQL Cluster.

Ésta es una traducción del manual de referencia de MySQL, que puede encontrarse en dev.mysql.com. El manual de referencia original de MySQL está escrito en inglés, y esta traducción no necesariamente está tan actualizada como la versión original. Para cualquier sugerencia sobre la traducción y para señalar errores de cualquier tipo, no dude en dirigirse a mysql-es@vespito.com.