MariaDB a collaboré avec Qualcomm Datacenter Technologies pour repousser les limites des performances en tirant parti de l'architecture matérielle innovante basée sur ARM avec l'architecture de base de données unique de MariaDB. Dans le cadre du lancement du produit Qualcomm Centriq™ 2400 en novembre 2017, nous avons démontré la forte évolutivité en lecture de MariaDB sur cette puce. Depuis lors, les ingénieurs de MariaDB et Qualcomm ont travaillé pour améliorer l'évolutivité des opérations d'écriture que nous aimerions partager avec la communauté des développeurs aujourd'hui.
Nous sommes heureux d'annoncer un certain nombre d'améliorations des performances qui sont disponibles dans la version 10.3.4 récemment livrée. En tirant parti du processeur hautement parallélisé Qualcomm Centriq 2400 à 48 cœurs fonctionnant à 2,6 GHz avec 6 canaux de mémoire dans une architecture en anneau entièrement cohérente, notre intérêt est d'extraire l'optimisation des performances d'écriture dans un cas d'utilisation d'écriture à une seule ligne pour une application hautement threadée.
MariaDB utilise le logiciel de benchmark sysbench pour mesurer les performances. Dans ce blog, nous examinerons les 2 benchmarks suivants en utilisant sysbench 1.0 :
- Oltp_update_index :cela simule la mise à jour d'une valeur de ligne unique par un index de clé primaire où un index secondaire doit être mis à jour à la suite de la mise à jour.
- Oltp_update_nonindex :cela simule la mise à jour d'une valeur de ligne unique par un index de clé primaire lorsqu'il n'y a pas d'index secondaire. Cela nécessite évidemment moins de travail que oltp_update_index.
Ce que nous constatons, c'est qu'à mesure que le nombre de threads simultanés augmente, les performances sont jusqu'à 48 % plus rapides en 10.3 qu'en 10.2 sur le Centriq™ 2400 :
Les améliorations apportées suppriment les points de discorde et optimisent pour le chipset ARM64, en particulier :
- MDEV-15090 :Réduisez la surcharge liée à l'écriture d'enregistrements de journal d'annulation
- MDEV-15132 :Éviter d'accéder à la page TRX_SYS
- MDEV-15019 :InnoDB :stocker ReadView sur trx
- MDEV-14756 :Supprimer trx_sys_t::rw_trx_list
- MDEV-14482 :Conflit de ligne de cache sur ut_rnd_ulint_counter()
- MDEV-15158 :lors de la validation, ne pas écrire dans la page TRX_SYS
- MDEV-15104 :Supprimer trx_sys_t::rw_trx_ids et trx_sys_t::serialisation_list
- MDEV-14638 :Remplacer trx_sys_t::rw_trx_set par LF_HASH
- MDEV-14529 :rw-locks InnoDB :optimiser les barrières mémoire
- MDEV-14374 : code UT_DELAY :suppression de la barrière matérielle pour la plate-forme arm64 bits
- MDEV-14505 :Threads_running devient un goulot d'étranglement d'évolutivité
En résumé, cela signifie que MariaDB fonctionnera nettement mieux sous des niveaux élevés de mises à jour simultanées, améliorant les temps de réponse de vos applications lors des pics de charge.
Les améliorations apporteront également des avantages à d'autres architectures de puces, mais un gain beaucoup plus important est observé sur le Centriq™ 2400 en raison de sa conception capable de prendre en charge un nombre de threads beaucoup plus élevé. En utilisant des cœurs physiques par rapport à l'hyper-threading, un nombre inférieur de cœurs, le Centriq™ 2400 démontre un gain supplémentaire de 13 % par rapport à une plate-forme Broadwell de référence comparable.
Alors que les systèmes Centriq™ 2400 arrivent sur le marché cette année, nous sommes ravis de voir les charges de travail des clients tirer parti de l'évolutivité combinée à une consommation d'énergie réduite pour exécuter des charges de travail de base de données à grande échelle.
