Benchmark OLTP Sysbench

Le benchmark de l'application Sysbench OLTP s'exécute sur une base de données MySQL exécutant le moteur de stockage InnoDB. Le travail du moteur de stockage consiste à gérer l'interface entre la base de données sur disque et les applications lisant et écrivant des données vers et depuis le moteur de stockage. Le moteur de stockage gère à son tour les threads d'E/S et les journaux, et il conserve un cache en mémoire pour minimiser l'accès au disque. Le tableau ci-dessous donne un aperçu simpliste du moteur.

Le benchmark de l'application Sysbench OLTP s'exécute sur une base de données MySQL exécutant le moteur de stockage InnoDB. Le travail du moteur de stockage consiste à gérer l'interface entre la base de données sur disque et les applications lisant et écrivant des données vers et depuis le moteur de stockage. Le moteur de stockage gère à son tour les threads d'E/S et les journaux, et il conserve un cache en mémoire pour minimiser l'accès au disque. Le tableau ci-dessous donne un aperçu simpliste du moteur.

Étant donné que le moteur InnoDB conserve un cache en mémoire appelé pool de mémoire tampon, les performances seront directement affectées par le rapport entre la taille de l'ensemble de travail et la taille du pool de mémoire tampon. En d'autres termes, si le pool de mémoire tampon est suffisamment grand pour contenir le jeu de travail ou si le jeu de travail est suffisamment petit pour tenir dans le pool de mémoire tampon, la plupart des opérations ne seront jamais liées aux E/S. Cependant, si la base de données est trop volumineuse pour tenir dans la mémoire, les performances d'E/S dicteront les temps de réponse et le débit transactionnels. Nous caractérisons les performances du lecteur dans cette situation où la base de données ne rentre pas dans la mémoire, ce qui entraîne une augmentation du trafic IO du moteur de stockage InnoDB.

Plusieurs threads (le nombre dépend de la configuration de la base de données pour les applications hautes performances et varie de 32 à 128) lisent les données de manière aléatoire à partir du magasin de sauvegarde avec une taille de bloc de 16 Ko. Ces lectures sont liées aux requêtes de base de données demandant des données au magasin de sauvegarde. Au fur et à mesure que les lectures sont traitées, elles sont automatiquement mises en cache dans le pool de mémoire tampon. Au fur et à mesure que le pool de mémoire tampon se remplit, InnoDB utilise une politique LRU (moins récemment utilisé) pour expulser les anciennes pages afin de faire de la place pour les données les plus récentes.

Les écritures de base de données sont d'abord dirigées vers le journal des transactions et vers le pool de mémoire tampon. Le journal des transactions est un tampon circulaire écrit séquentiellement qui est mis à jour pour chaque transaction d'écriture. Selon la configuration de MySQL, cette mise à jour peut entraîner une écriture immédiate sur le disque, ou elle peut persister temporairement dans la RAM en tant que tampon qui est finalement vidé sur le disque par le système de fichiers. La taille de ce tampon de journal varie, mais est généralement d'environ 256 Mo. Les paramètres recommandés pour la conformité ACID exigent que les écritures de journal atteignent le disque à chaque validation de base de données. Ces écritures ont une longueur de 4K.

Le journal ne fait que des écritures "physiologiques" où le delta entre les données précédentes et les nouvelles données est écrit. Pour les données d'origine, InnoDB écrit dans le pool de mémoire tampon de la RAM, qui doit également être vidé de manière asynchrone. Le processus d'écriture des données dans le système de fichiers est configurable et se produit en arrière-plan. Les écritures sont également 16K. Les écritures sont en fait des doubles écritures où le moteur écrit d'abord les données dans un emplacement intermédiaire appelé tampon de double écriture. Le moteur copie ensuite ces données dans son emplacement final dans le système de fichiers. Cela est nécessaire pour éviter le problème de "page déchirée" où une page de base de données de 16 Ko est partiellement écrite sur le disque en raison d'une coupure de courant ou d'un autre événement catastrophique.

Origines du Benchmark Sysbench

Nous avons introduit la configuration de test Sysbench dans notre laboratoire après plusieurs conversations avec micron sur la façon dont ils simulent les environnements d'application MySQL du monde réel pour les tests et les mesures SSD. Ils ont développé une méthodologie de test autour de Sysbench après avoir constaté que les benchmarks de stockage synthétique fournissaient rarement une vue complète du comportement d'un lecteur lorsqu'il était soumis à une charge de travail d'application particulière. Le test Sysbench permet à Micron de simuler un environnement qui représente le plus fidèlement une charge de travail de base de données MySQL standard, qui prévaut dans des applications telles que Facebook, Craigslist et Booking.com

Nous avons travaillé en étroite collaboration avec Moussa Ba, qui a aidé à co-rédiger cet article. Moussa est ingénieur logiciel au sein de l'équipe de développement PCIe de Micron, où son travail comprend l'optimisation des applications et des logiciels système pour les périphériques IO hautes performances.

Benchmark OLTP Sysbench

Sysbench est une référence de performances système qui inclut un profil de test de traitement des transactions en ligne (OLTP). Le test OLTP n'est pas une approximation d'un test OLTP, mais plutôt une véritable référence basée sur une base de données qui effectue des requêtes transactionnelles sur une instance de MySQL dans un environnement CentOS.

La première étape de la configuration du benchmark consiste à créer la base de données elle-même, ce qui se fait en spécifiant le nombre de tables dans la base de données ainsi que le nombre de lignes par table. Dans notre test, nous avons défini 100 tables de 10 millions de lignes chacune, ce qui a donné une base de données de 1 milliard d'entrées. Cette base de données faisait 260 Go.

Sysbench a deux modes de fonctionnement : un mode par défaut qui lit et écrit dans la base de données et un mode lecture seule. Le mode L/E par défaut exécutera les types de requêtes suivants : 5 requêtes SELECT, 2 requêtes UPDATE, 1 requête DELETE et 1 INSERT. En regardant le nombre d'E/S, le rapport lecture/écriture observé est d'environ 75 % de lectures et 25 % d'écritures.

Environnement de test Sysbench

Les solutions de stockage sont testées avec le benchmark Sysbench OLTP dans le Laboratoire de test d'entreprise StorageReview utilisant des serveurs autonomes. Nous utilisons actuellement des PowerEdge R730 standard de Dell pour afficher à la fois des performances réalistes et un rapport prix/performance solide, en ne modifiant que l'adaptateur de stockage ou l'interface réseau pour connecter notre R730 à différents produits de stockage. Le PowerEdge R730 a fait ses preuves pour offrir une grande compatibilité avec les appareils tiers, ce qui en fait une excellente plate-forme de référence pour cet environnement de test diversifié. Le R730 s'appuie également sur la puissante architecture de classe Haswell d'Intel, qui nous donne la puissance de calcul nécessaire pour optimiser correctement une large gamme d'offres de stockage et maximiser leur potentiel de performances.

Environnement de référence Sysbench de première génération

Lenovo Think Server RD630 – Plate-forme de test SATA/SAS/PCIe

• 2594-ABU Modèle le plus vendu
• Deux processeurs Intel E5-2650 (2.0 GHz, 8 cœurs, 20 Mo de cache)
• 128 Go de RAM (8 Go x 16 DDR3, 64 Go par processeur)
• 100 Go de microns SSD RealSSD P400e (via LSI 9207-8i) Lecteur de démarrage
• 960 Go Micron M500 (via 9207-8i) Stockage de base de données pré-construit
• CentOS 6.3 64 bits
• Percona XtraDB 5.5.30-rel30.1
  • Tableaux de base de données : 100
  • Taille de la base de données : 10,000,000 XNUMX XNUMX
  • Threads de base de données : 32
  • Mémoire tampon : 24 Go

​​Environnement de référence Sysbench de deuxième génération

Dell PowerEdge R730 – Plate-forme de test SATA/SAS/PCIe

• Deux processeurs Intel E5-2690 v3 (2.6 GHz, 12 cœurs, 30 Mo de cache)
• 256 Go de RAM (16 Go x 16 DDR4, 128 Go par processeur)
• SSD de démarrage de 100 Go, SSD de stockage de base de données de 480 Go
• 2 adaptateurs Mellanox ConnectX-3 InfiniBand
• 2 x HBA FC double port Emulex 16 Go
• 2 x Carte réseau Emulex 10GbE à deux ports
• CentOS 6.6 64 bits
• Percona XtraDB 5.5.30-rel30.1
  • Tableaux de base de données : 100
  • Taille de la base de données : 10,000,000 XNUMX XNUMX
  • Threads de base de données : 32
  • Mémoire tampon : 24 Go

Grappe à 730 nœuds Virtualized Sysbench Dell PowerEdge R4

• Huit processeurs Intel E5-2690 v3 pour 249 GHz en cluster (deux par nœud, 2.6 GHz, 12 cœurs, 30 Mo de cache)
• 1 To de RAM (256 Go par nœud, 16 Go x 16 DDR4, 128 Go par processeur)
• Démarrage de la carte SD (Lexar 16 Go)
• 4 x adaptateur Mellanox ConnectX-3 InfiniBand (vSwitch pour vMotion et réseau VM)
• 4 x HBA FC double port Emulex 16 Go
• 4 x Carte réseau Emulex 10GbE à deux ports
• VMware ESXi vSphere 6.0/Enterprise Plus 8-CPU

L'objectif principal de cette plate-forme est de mettre en évidence les performances du stockage d'entreprise dans un environnement et une charge de travail d'entreprise réels, au lieu de s'appuyer sur des charges de travail synthétiques ou pseudo-synthétiques. Les générateurs de charge de travail synthétiques sont excellents pour montrer les performances des périphériques de stockage avec un modèle d'E/S synthétique continu, mais ils ne prennent en compte aucune des autres variables extérieures qui éclairent le fonctionnement réel des périphériques dans les environnements de production. Les générateurs de charge de travail synthétiques ont l'avantage d'afficher un modèle d'E/S propre à maintes reprises, mais ils ne reproduiront jamais un véritable environnement de production. L'introduction de performances applicatives en plus des produits de stockage commence à montrer à quel point le stockage interagit avec ses pilotes, le système d'exploitation local, l'application testée, la pile réseau, la commutation réseau et les serveurs externes. Ce sont des variables qu'un générateur de charge de travail synthétique ne peut tout simplement pas prendre en compte, et elles sont également d'un ordre de grandeur plus gourmandes en ressources et en infrastructure en termes d'équipement requis pour exécuter ce benchmark particulier.

Résultats de performances globales de Sysbench

Nous testons une large gamme de solutions de stockage avec le benchmark Sysbench OLTP qui répondent aux exigences minimales de l'environnement de test. Pour être éligible aux tests, le périphérique de stockage doit avoir une capacité utilisable supérieure à 260 Go et être conçu pour fonctionner dans des conditions d'entreprise stressantes. Les périphériques de stockage connectés localement tels que les SSD SAS, SATA et PCIe sont testés sur un serveur bare metal avec une instance Sysbench. Les nouvelles plates-formes SAN et hyperconvergées exécutent simultanément 4, 8, 12 ou 16 machines virtuelles pour montrer dans quelle mesure plusieurs charges de travail fonctionnent en même temps sur chacune. Cette méthodologie de test permet de démystifier les comparaisons de performances entre les nouveaux systèmes hyperconvergés et les baies de stockage SAN traditionnelles.

Résultats des performances de Sysbench hyperconvergé / SAN virtualisé (agrégat de 16 machines virtuelles)

Résultats des performances de Sysbench hyperconvergé / SAN virtualisé (agrégat de 12 machines virtuelles)

Résultats des performances de Sysbench hyperconvergé / SAN virtualisé (agrégat de 8 machines virtuelles)

Résultats des performances de Sysbench hyperconvergé / SAN virtualisé (agrégat de 4 VM)

Accélérateur d'application PCIe / Résultats de performances de Sysbench RAID multi-SSD/HDD

Résultats SAS/SATA SSD individuels