Le processus ndbd
dispose de nombreuses
structures simples qui sont utilisées pour accéder aux
données du cluster MySQL. Voici quelques indicateurs de
performances pour mesurer les performances des commandes et les
effets des interconnexions sur les performances.
Il existe 4 méthodes d'accès :
Accès par clé primaire
C'est un accès simple à une ligne, via sa clé primaire. Dnas le cas le plus simple, une seule ligne est lue en même temps. Cela signifie que le coût total des messages TCP/IP et des changements de contexte sont pris en charge par celle seule opération. Dans un mode par lots, où les clés primaires sont distribuées par groupe de 32, chaque groupe va partager le coût des messages TCP/IP et les coûts de changement de contexte (si les messages sont destinés à différents noeuds, il faudra construire les messages nécessaires).
Accès par clé unique
Les accès par clé unique sont très similaires aux accès par clé primaire, hormis le fait qu'ils sont exécutés sous forme de lecture de l'index, suivi par un accès de clé primaire. Cependant, une seule requête est envoyée par le serveur MySQL, et la lecture de l'index est gérée par le processus ndbd. Par conséquent, ces requêtes gagnent à être réalisées en groupe.
Analyse complète de table
Lorsqu'aucun index n'existe pour une table, cette dernière est entièrement analysée. C'est une seule requête qui est envoyée au processus ndbd, qui la divise en analyses paralelles dans les noeuds du cluster. Dans les futures versions du cluster, MySQL sera capable de filtrer un peu mieux ces analyses.
Analyse d'intervalle avec un index
ordonné
Lorsqu'un index ordonné est utilisé, il va faire une analyse de la même manière qu'une analyse de table, mais il ne traitera que les lignes qui sont dans l'intervalle indiqué par la requête. Dans les futures versions, une optimisation spéciale aura lieu pour s'assurer que tous les attributs de l'index qui sont liés incluent les attributs de la clé, pour que seule une partie de l'index soit analysée, et non pas analysée en paralelle.
Pour vérifier les performances de base de ces méthodes d'accès, nous avons développé un jeu de tests. Un des test, testReadPerf, effectue des accès via clé primaire, clé unique, en batch ou non. Les tests mesurent aussi le coût des analyses par intervalles, en effectuant des tests qui retournent une seule ligne, et finalement, des variantes qui utilisent des analyses d'intervalle pour lire des groupes de lignes.
Dans cette manière, il est possible de mesurer le coût d'un accès à une clé, et le coût de l'analyse d'une ligne, puis de mesurer l'impact des médias de communication.
Nous avons exécuté ces tests avec des sockets TCP/IP classiques et des sockets SCI. Les chiffres indiqués ci-dessous correspondent à des petits accès de 20 lignes par accès aux données. La différence entre les accès de série et par groupe diminue d'un facteur de 3-4 lorsque les lignes font 2 ko. Les sockets SCI ne sont pas testées pour les lignes de 2ko. Les tests ont été effectués sur des clusters de 2 noeuds, avec des machines bi-processeurs, équipées de AMD 1900+.
type d'accès: Sockets TCP/IP Sockets SCI Serial pk access: 400 microsecondes 160 microsecondes Batched pk access: 28 microsecondes 22 microsecondes Serial uk access: 500 microsecondes 250 microsecondes Batched uk access: 70 microsecondes 36 microsecondes Indexed eq-bound: 1250 microsecondes 750 microsecondes Index range: 24 microsecondes 12 microsecondes
Nous avons aussi un autre jeu de test pour comparer les performances des sockets SCI, en utilisant le transport SCI ou le transport TCP/IP. Ces tests utilisent des accès par clé primaire, en série, multi-thread ou multi-thread en groupe, simultanément.
Presque tous les tests ont montrés que les sockets SCI sont
100% plus rapides que les sockets TCP/IP. Le transporteur SCI
était plus rapide dans la plupart des cas, comparés aux
sockets SCI. Un cas notable : les multi-threads ont montré que
le transporteur SCI pouvait se comporter de très mauvaise
manière, s'il est utilisé dans le processus
mysqld
.
Dans l'ensemble, notre conclusion est que pour les tests de
performances, les sockets SCI ont améliorés la vitesse de 100%
par rapport aux sockets TCP/IP, sauf sauf dans les rares cas où
les performances ne sont pas un problème comme lors des
analyses par filtres qui prennent beaucoup de temps, où lorsque
de très grands groupes de clé primaires sont en jeu. Dans ce
cas, le temps de calcul processeur de ndbd
prend une forte part du temps de calcul.
Utiliser le transporteur SCI au lieu des sockets SCI ne sert
vraiment qu'entre les processus ndbd
.
Utiliser le transporteur SCI ne sert que si un processeur peut
être dédié à un processus ndbd
, car le
transporteur SCI s'assure que le processus
ndbd
ne reste pas inactif. Il est aussi
important de s'assurer que le processus ndbd
a une priorité suffisament haute pour ne pas être rétrogradé
s'il fonctionne durant un long moment (comme cela se fait en
verrouillant les processus sur un processeur en Linux 2.6). Si
c'est possible, alors le processus ndbd
gagnera 10 à 70% de performances, par rapport aux sockets
SCI : les gains les plus importants interviennent lors des
modifications, et probablement sur les analyses paralelles).
Il y a d'autres implémentations de sockets optimisées pour les clusters, indiquées dans différents articles. Elles incluent les sockets optimisées pour Myrinet, Gigabit Ethernet, Infiniband et interfaces VIA. Nous n'avons testé le cluster MySQL qu'avec les sockets SCI, et nous incluons aussi la documentation ci-dessus sur comment configurer les sockets SCI en utilisant une configuration TCP/IP ordinaire sur un cluster MySQL.
This is a translation of the MySQL Reference Manual that can be found at dev.mysql.com. The original Reference Manual is in English, and this translation is not necessarily as up to date as the English version.