Dans cet article, nous allons discuter de sysbench, la norme actuelle pour le benchmarking MySQL. Nous allons jeter un œil aux bases de l'utilisation de sysbench et comment pouvons-nous utiliser sysbench pour en savoir plus sur MySQL et le second est l'aspect le plus important pour nous. Nous utiliserons pratiquement sysbench comme un outil pour générer du trafic dont nous savons beaucoup de choses car sysbench conservera des informations sur le trafic généré chaque seconde.

Test MySQL SysBench 

Sysbench est un outil de benchmark multi-thread basé sur luaJIT, c'est la norme actuelle pour les benchmarks MySQL, il doit pouvoir se connecter à la base de données.

Installation de Sysbench

Tout d'abord, nous devons installer le sysbench, j'installe sysbench sur un autre serveur afin que nous puissions tester l'impact réel de la charge sur notre serveur MySQL.

curl -s https://packagecloud.io/install/repositories/akopytov/sysbench/script.rpm.sh | sudo bashyum -y install sysbench

Cela étant, il est très facile d'installer sysbench, il est préférable de permettre à sysbench d'interagir avec le serveur MySQL au niveau du pare-feu, car il s'agit d'un environnement de test. J'ai désactivé le pare-feu sur les deux hôtes pour éviter toute difficulté.

Environnement prêt pour SysBench :

Pour ce test, je crée la base de données sbtest et l'utilisateur sbtest_user et j'accorderai tous les PRIVILÈGES à sbtest_user sur la base de données sbtest.

en utilisant la racine ;

mysql> créer une base de données sbtestmysql> créer un utilisateur sbtest_user identifié par 'password';mysql> accorder tout sur sbtest.* à `sbtest_user`@`%`;mysql> afficher les autorisations pour sbtest_user;+------- -------------------------------------------------- +| Grants for [email protected]%                                |+---------------------------------------- -----------------+| ACCORDER L'UTILISATION SUR *.* À `sbtest_user`@`%`                 || ACCORDER TOUS LES PRIVILÈGES SUR `sbtest`.* À `sbtest_user`@`%` |+------------------------------- --------------------------+

Performance de MySQL avec SysBench

Configuration de référence :

L'étape de préparation de sysbench crée les tables avec les données qui seront utilisées dans le benchmark. Dans cet exemple, nous exécutons la commande prepare. Il y a quelques paramètres avec MySQL au début, ce seront les paramètres de connexion. Les autres paramètres sont des paramètres du test oltp_read_write.lua et nous spécifions le test lui-même qui est oltp_read_write.lua et que nous exécutons la commande prepare. L'option commençant par MySQL spécifie la connexion MySQL, le nom d'hôte et le port auquel se connecter, le nom d'utilisateur et le mot de passe avec lesquels se connecter, et le schéma par défaut pour la connexion. Les tables et les paramètres table_size sont les propriétés du test oltp_read_write.lua.

Cela signifie que l'étape de préparation créera 16 tables avec 10 000 règles dans chacune d'elles. L'étape suivante consiste à exécuter le benchmark.

Pour exécuter généralement tous les paramètres sont passés qui passeront à préparés et quelques autres que nous avons examinés maintenant, ceux-ci sont spécifiques à l'exécution réelle du benchmark. Le "TEMPS" Le paramètre spécifie le délai d'exécution du benchmark, zéro signifie un temps illimité, le benchmark s'exécutera jusqu'à ce que nous appuyions sur control + c. C'est ainsi que nous utiliserons sysbench dans le laboratoire et c'est ainsi que les gens l'utilisent généralement dans l'apprentissage et non dans une configuration d'analyse comparative.

Nous voulons simplement libérer du trafic sur quelque chose que nous allons examiner et nous pouvons l'arrêter avec control+c une fois que nous avons terminé l'examen.

L'"intervalle de rapport" les paramètres spécifient la fréquence à laquelle sysbench a imprimé des statistiques. Typiquement, ceci est mis à 1 comme dans notre exemple où l'on fait en sorte que sysbench imprime la ligne pour chaque seconde. Même dans les configurations de benchmarking, ce paramètre est largement utilisé car imaginez si nous avons un benchmark d'une heure et que nous n'avons que des statistiques agrégées à la fin, cela ne dit rien sur la distribution des données comme la performance sur le serveur au fil du temps . Le "fil" L'option spécifie le nombre de threads client ou de connexions MySQL à utiliser dans sysbench. Le nombre de threads du client aura également un effet sur le nombre de threads du serveur pouvant être utilisés. Le "taux" Le paramètre spécifie le taux d'arrivée des transactions sysbench comme moyen de répondre réellement à la charge causée par le benchmark. Si les transactions peuvent continuer, elles sont mises en file d'attente, c'est encore une fois quelque chose qui est généralement utilisé dans ce type de configuration que nous allons utiliser maintenant dans un type de configuration d'apprentissage.

Depuis l'hôte sysbench :

Préparer un ensemble de données :

Sur la machine virtuelle de benchmarking, nous allons exécuter la commande sysbench prepare pour créer une base de données pour nos benchmarks.

Ici, nous pouvons voir que nous utilisons le sbtest_user comme nom d'utilisateur, le mot de passe est mot de passe et nous nous connectons à 192.168.66.5 DB en tant que serveur de base de données.

sysbench \--db-driver=mysql \--mysql-user=sbtest_user \--mysql_password=password \--mysql-db=sbtest \--mysql-host=192.168.66.5 \--mysql-port =3306 \--tables=16 \--table-size=10000 \/usr/share/sysbench/oltp_read_write.lua preparesysbench 1.0.20 (à l'aide de LuaJIT 2.1.0-beta2 fourni)Création de la table 'sbtest1'...Insertion 10000 enregistrements dans 'sbtest1'Création d'un index secondaire sur 'sbtest1'......Création de la table 'sbtest16'...Insertion de 10000 enregistrements dans 'sbtest16'Création d'un index secondaire sur 'sbtest16'..

Vous avez la base de données sbtest ici, changeons le schéma par défaut en base de données sbtest, vérifions quelles tables avons-nous.

Nous avons spécifié que le benchmark devait créer seize tables et il a créé 16 tables, nous pouvons le voir ici

mysql> affiche les tables ;+-----------------+| Tables_in_sbtest +------------------------------+| sbtest1          || sbtest2          |...| sbtest16         |+------------------+16 lignes dans l'ensemble (0,01 s)

Vérifions quelques enregistrements d'une table.

mysql> select * from sbtest1 limit 6;

nous allons faire un benchmark. Ce benchmark aura une ligne de sortie pour chaque seconde car nous définissons un rapport l'intervalle est égal à un et il a quatre threads client car nous définissons des threads égaux à quatre.

--events=N                      limite pour le nombre total d'événements [0]--time=N                        limite pour le temps d'exécution total en secondes [10]

Ces deux paramètres ci-dessus (événements et heure) régissent la durée de fonctionnement de SysBench. Il peut soit exécuter un certain nombre de requêtes, soit continuer à fonctionner pendant une durée prédéfinie.

Sur l'hôte sysbench :

sysbench \--db-driver=mysql \--mysql-user=sbtest_user \--mysql_password=password \--mysql-db=sbtest \--mysql-host=192.168.66.5 \--mysql-port =3306 \--tables=16 \--table-size=10000 \--threads=4 \--time=0 \--events=0 \--report-interval=1 \ /usr/share/sysbench/ oltp_read_write.lua runWARNING :Les limites d'événement et de temps sont désactivées, l'exécution d'un testsysbench 1.0.20 sans fin (à l'aide de LuaJIT 2.1.0-beta2 fourni) )Initializing random number generator from current timeInitializing worker threads...Threads started![ 1s ] thds:4 tps:62.79 qps:1320.63 (r/w/o:933.91/257.15/129.57) lat (ms,95%):80.03 err/s :0,00 reconn/s :0,00[ 2s ] thds :4 tps :77,01 qps :1530,26 (r/w/o :1065,18/312,05/153,03) lat (ms,95 %) :61,08 err/s :0,00 reconn /s :0,00[ 3s ] thds :4 tps :74,03 qps :1463,67 (r/w/o :1025,47/289,13/149,07) lat (ms,95 %) :70,55 err/s :0,00 reconn/s :0,00[ 4s ] thds :4 tps :69,99 qps :1414. 84 (r/w/o :991,89/282,97/139,98) lat (ms,95 %) :65,65 err/s :0,00 reconn/s :0,00[ 5s ] thds :4 tps :74,02 qps :1488,34 (r/w/ o :1048.24/292.07/148.03) lat (ms,95%) :74.46 err/s :0.00 reconn/s :0.00[ 6s ] thds :4 tps :72.99 qps :1444.89 (r/w/o :1003.92/294.98/ 145.99) lat (ms,95%) :70.55 err/s :0.00 reconn/s :0.00[ 7s ] thds :4 tps :63.00 qps :1271.04 (r/w/o :890.03/255.01/126.00) lat (ms, 95%) :87,56 err/s :0,00 reconn/s :0,00[ 8s ] thds :4 tps :72,99 qps :1439,82 (r/w/o :1008,87/284,96/145,98) lat (ms,95 %) :73,13 err /s :0,00 reconn/s :0,00[ 9s ] thds :4 tps :74,00 qps :1488,01 (r/w/o :1038,01/302,00/148,00) lat (ms,95 %) :73,13 err/s :0,00 reconn/ s : 0,00

nous pouvons donc voir qu'il effectue environ 70 à 80 transactions par seconde sur ma machine, ce qui se traduit par environ plus d'un millier de requêtes par seconde. Cela s'exécute dans VirtualBox sur un ordinateur portable.

À partir de ces requêtes, nous pouvons voir combien d'entre elles sont des lectures, combien d'entre elles sont des écritures, combien d'entre elles sont autres quelle est la latence du 95e centile pour la transaction (r/w/o :1038.01/302.00/148.00), comment nombre d'erreurs par seconde (err/s :0,00 ) que nous avons et combien de connexions par seconde (reconn/s :0,00) nous avons. Parce que nous spécifions que le temps est égal à zéro, cela fonctionnera jusqu'à ce que nous appuyions sur ctrl + c.

Vérifions la liste des processus d'affichage sur l'hôte de la base de données.

mysql> affiche la liste des processus ;+----+-----------------+------------------ --+--------+---------+-------+-------------------- --------+--------------------------------------------------+| identifiant | Utilisateur            | Hébergeur               | db     | Commande | Heure | État                     | Informations                                |+----+------------+--------------------+--- -----+---------+-------+-------------------------- --+--------------------------------------------------+| 5 | planificateur_d'événements | localhost          | NULL   | Démon | 23200 | Attente sur file d'attente vide     | NULL                                 || 11 | racine            | localhost          | NULL   | Dormir   | 18438 | | NULL                                || 19 | racine            | localhost          | sbtest | Requête   | 0 | démarrage                   | afficher la liste des processus                     || 23 | racine            | localhost          | NULL   | Dormir   | 4098 | | NULL                                || 30 | sbtest_user     | 192.168.66.6:37298 | sbtest | Dormir   | 0 | | NULL                                || 31 | sbtest_user     | 192.168.66.6:37300 | sbtest | Exécuter | 0 | en attente de validation du gestionnaire | S'ENGAGER                              || 32 | sbtest_user     | 192.168.66.6:37302 | sbtest | Dormir   | 0 | | NULL                                || 33 | sbtest_user     | 192.168.66.6:37304 | sbtest | Exécuter | 0 | Tables d'ouverture             | SELECT c FROM sbtest13 WHERE id=4978 |+----+-----------------+----------------- ---+--------+---------+-------+------------------- ---------+--------------------------------------------------+ 

 8 lignes dans le jeu (0.00 sec)
 

 Le serveur de base de données était pratiquement toujours occupé. J'ai vu que le temps d'exécution ne change pratiquement jamais de zéro, et il était très facile d'attraper le serveur de base de données en action comme lorsqu'il exécute "SELECT c FROM sbtest13 WHERE id=4978". Et définitivement, nous avons quatre connexions de la machine de benchmarking
 

 
 

 
 

 
 

 
 

 
 

 Par défaut, SysBench tentera d'exécuter les requêtes aussi rapidement que possible. Pour simuler un trafic plus lent, cette option peut être utilisée. Vous pouvez définir ici combien de transactions doivent être exécutées par seconde.
 
--rate=N                        taux moyen de transactions. 0 pour un tarif illimité [0]
 
Sur l'hôte sysbench
 
[[email protected] ~]# sysbench \--db-driver=mysql \--mysql-user=sbtest_user \--mysql_password=password \--mysql-db=sbtest \--mysql-host=192.168.66.5 \--mysql-port=3306 \--tables=16 \--table-size=10000 \--threads=4 \--time=0 \--events=0 \--report-interval=1 \--rate=40 \/usr/share/sysbench/oltp_read_write.lua runWARNING :les limites d'événement et de temps sont désactivées, l'exécution d'un testsysbench 1.0.20 sans fin (à l'aide de LuaJIT 2.1.0-beta2 fourni)Exécution du test avec les éléments suivants options :Nombre de threads :4Taux de transaction cible :40/secRapport des résultats intermédiaires toutes les 1 seconde(s)Initialisation du générateur de nombres aléatoires à partir de l'heure actuelleInitializing worker threads...Threads started![ 1s ] thds :4 tps :42.87 /w/o :600.20/171.49/86.74) lat (ms,95%) :73.13 err/s :0.00 reconn/s :0.00[ 1s ] longueur de la file d'attente :0, simultanéité :1[ 2s ] thds :4 tps :41.01 qps :857,25 (r/w/o :609,17/164,05/84,02) lat (ms,95 %) :101,13 err/s :0,00 reconn/s :0,00[ 2s ] longueur de la file d'attente :0, simultanéité :3[ 3s ] thds :4 points :57.01 qps :1119.29 (r/w/o :778.20/228.06/113.03) lat (ms,95 %) :73.13 err/s :0.00 reconn/s :0.00[ 3s ] longueur de la file d'attente :0, simultanéité :2... [ 15s ] thds :4 tps :0,00 qps :0,00 (r/w/o :0,00/0,00/0,00) lat (ms,95 %) :0,00 err/s :0,00 reconn/s :0,00 [ 15s ] longueur de la file d'attente :[ 16s ] longueur de la file d'attente :179, simultanéité :4
 

 Le nouveau paramètre ici est donc –rate est égal à 40 ce qui signifie que nous aurons deux lignes par seconde deux lignes de sortie et non une. Étant donné que nous avons défini le taux d'arrivée des événements d'analyse comparative à 40 par seconde, nous verrons le TPS actuel.
 

 Il n'est pas garanti que ce soit 40/seconde, mais l'arrivée garantit qu'en moyenne, nous effectuons environ 40 transactions par seconde et nous pouvons surveiller la longueur de la file d'attente et la simultanéité sur la deuxième ligne. Si nous faisons une courte liste de processus, il est beaucoup plus facile d'attraper la base de données dans un état où certaines connexions attendent juste ici.
 

 Lorsqu'une session est occupée, vous pouvez voir que la transaction par seconde est nulle (tps :0,00).
 
mysql> affiche la liste des processus ;+----+-----------------+------------------ --+--------+---------+-------+-------------------- ----------------------------------------------------------------- -------------------------------------------------- -------+| identifiant | Utilisateur            | Hébergeur               | db     | Commande | Heure | État                  | Info | + ---- + ----------------- + -------------------- + --- -----+---------+-------+-----------------------+- -------------------------------------------------- -------------------------------------------------- -+| 5 | planificateur_d'événements | localhost          | NULL   | Démon | 19162 | Attente sur file d'attente vide | NULL || 8 | racine            | localhost          | NULL   | Requête   | 0 | démarrage               | afficher la liste de processus                                                                              | || 21 | sbtest_user     | 192.168.66.6:49060 | sbtest | Exécuter | 33 | mise à jour               | MISE À JOUR sbtest8 SET k=k+1 WHERE id=5005                                                           || 22 | sbtest_user     | 192.168.66.6:49062 | sbtest | Exécuter | 22 | mise à jour               | MISE À JOUR sbtest14 SET c='54592761471-89397085016-24424731626-29460127219-18466786462-73074657089-48925 | 23 | sbtest_user     | 192.168.66.6:49064 | sbtest | Exécuter | 21 | mise à jour               | MISE À JOUR sbtest10 SET c='68520795048-46094139936-88850487689-12482054639-29231339380-71050139550-93403 || 24 | sbtest_user     | 192.168.66.6:49066 | sbtest | Exécuter | 31 | mise à jour               | DELETE FROM sbtest14 WHERE id=4994                                                                |+----+-----------------+------ --+--------+---------+-------+-------------------- ----------------------------------------------------------------- -------------------------------------------------- -------+10 lignes dans l'ensemble (0,00 s)
 

 Nous pouvons voir que cela dort pendant quelques secondes, c'était pratiquement impossible dans le scénario précédent d'obtenir quelque chose comme ça.
 

 
 

 
 

 
 
Trafic intense en écriture avec rapport de fin :
 

 Exécutons une charge de travail lourde en écriture (mais pas en écriture seule) et, par exemple, testons les performances du sous-système d'E/S, comme je l'ai mentionné time=300 puis le benchmark fonctionnera pendant 300sec et il nous donnera un rapport final pour l'analyser.
 
[[email protected] ~]#   sysbench \--db-driver=mysql \--mysql-user=sbtest_user \--mysql_password=password \--mysql-db=sbtest \--mysql-host=192.168.66.5 \--mysql-port=3306 \--tables=16 \--table-size=10000 \--threads=8 \--time=300 \--events=0 \--report-interval=1 \--rate=40 \/usr/share/sysbench/oltp_read_write.lua runsysbench 1.0.20 (en utilisant le LuaJIT 2.1.0-beta2 fourni) Exécution du test avec les options suivantes :Nombre de threads :8Taux de transaction cible :40/secRapport résultats intermédiaires toutes les 1 seconde(s)Initializing random number generator from current timeInitializing worker threads...Threads started![ 1s ] thds:8 tps:39.87 qps:810.27 (r/w/o:570.08/159.46/80.73) lat ( ms,95 %) :82,96 err/s :0,00 reconn/s :0,00[ 1s ] longueur de la file d'attente :0, simultanéité :1[ 2s ] thds :8 tps :43,02 qps :847,39 (r/w/o :590,27/172,08 /85.04) lat (ms,95%) :125.52 err/s :0.00 reconn/s :0.00[ 2s ] longueur de file d'attente :0, simultanéité :0...[ 350s ] thds :8 tps :0.00 qps :0.00 (r /sans :0,00/0,00/0,00) lat (ms,95 %) :0,00 erreur/s :0,00 Reconn / s:0,00 [350S] Longueur de file d'attente:6545, concurrence:1SQL Statistiques:Requêtes effectuées:Lire:78624 Écriture:22385 Autre:11205 Total:112214 Transactions:5589 (15,94 par seconde) Quéries:112214 (320,02 par rapport Sec.) Erreurs ignorées:27 (0,08 par sec.) Reconnecte:0 (0,00 par sec.) Statistiques générales:Temps total:350,6412S Nombre total d'événements:5589latence (MS):Min:12,45 AVG:74639.59 Max:213244.02 95e centile :                  100000.00         somme :                            417160677.24 Équité des fils de discussion :   événements (avg/stddev) :           698.6250/196.36    temps d'exécution (avg/stddev) :   52145.0847/15557.93
 

 
 
ANALYSE DU RAPPORT :
 

 Ceci est très utile pour vérifier que le rapport final ne vous donnera que des moyennes. Des résultats intermédiaires permettront de suivre la performance seconde par seconde. Le rapport final peut ressembler à ci-dessus. Vous trouverez ici des informations sur les requêtes exécutées, les transactions exécutées, le nombre d'erreurs survenues, la perte de connexion, le débit et le temps total écoulé. Vous pouvez également vérifier les métriques de latence et la distribution des requêtes sur les threads.