Mysql
 sql >> Base de données >  >> RDS >> Mysql

Surveillance efficace de MySQL avec les tableaux de bord SCUMM :partie 3

Nous avons discuté dans nos blogs précédents des tableaux de bord liés à MySQL. Nous avons mis en évidence les éléments dont un administrateur de base de données peut bénéficier en étudiant les graphiques, en particulier lors de l'exécution de ses routines quotidiennes à partir des diagnostics, des rapports de métriques et de la planification des capacités. Dans ce blog, nous discuterons des métriques InnoDB et du schéma de performances MySQL, qui sont très importants, en particulier pour surveiller les transactions InnoDB, les E/S disque/cpu/mémoire, l'optimisation de vos requêtes ou le réglage des performances du serveur.

Ce blog aborde le sujet profond des performances, étant donné qu'InnoDB nécessiterait une couverture étendue si nous nous attaquions à ses composants internes. Le schéma de performances est également complet car il couvre le noyau et les parties centrales de MySQL et des moteurs de stockage.

Commençons par parcourir les graphiques.

Métriques MySQL InnoDB

Ce tableau de bord est idéal pour tout administrateur de bases de données ou toute personne chargée des opérations MySQL, car il offre une très bonne vue sur le moteur de stockage InnoDB. Il y a certains graphiques ici qu'un utilisateur doit prendre en compte pour activer, car ce n'est pas dans toutes les situations que les variables sont correctement définies dans la configuration MySQL.

  • Âge du point de contrôle Innodb

    Selon le manuel, le point de contrôle est défini comme suit :"Au fur et à mesure que des modifications sont apportées aux pages de données qui sont mises en cache dans le pool de tampons , ces modifications sont écrites dans les fichiers de données quelque temps plus tard, un processus connu sous le nom de flushing . Le point de contrôle est un enregistrement des dernières modifications (représentées par un LSN valeur) qui ont été écrites avec succès dans les fichiers de données ”. Ce graphique est utile lorsque vous souhaitez déterminer comment votre serveur exécute les données de point de contrôle sur votre disque. Cela peut être une bonne référence si votre journal des transactions (journal redo ou ib_logfile0) est trop volumineux. Ce graphique est également un bon indicateur si vous devez ajuster des variables telles que innodb_log_file_size,, innodb_log_buffer_size, innodb_max_dirty_pages_pct ou innodb_adaptive_flushing_method. Plus l'âge du point de contrôle est proche de l'âge maximum du point de contrôle, plus les journaux sont remplis et InnoDB effectuera plus d'E/S afin de conserver de l'espace libre dans les journaux. Le mécanisme de point de contrôle diffère dans des détails subtils entre les saveurs basées sur Percona XtraDB, MariaDB et la version d'Oracle, vous pouvez également trouver des différences dans sa mise en œuvre entre les versions de MySQL.

  • Transactions InnoDB

    Chaque fois qu'une transaction importante est en cours sur votre serveur MySQL, ce graphique est une bonne référence. Il comptera les transactions qui ont été créées à un moment précis, et la longueur de l'historique (ou est en fait la longueur de la liste d'historique trouvée dans SHOW ENGINE INNODB STATUS) est le nombre de pages dans le journal d'annulation. Les tendances que vous verrez ici sont une bonne ressource pour vérifier si cela pourrait signifier, par exemple, que la purge est retardée en raison d'un taux d'insertion très élevé de rechargement des données ou en raison d'une transaction de longue durée, ou si la purge peut simplement ne suit pas en raison d'un nombre élevé d'E/S de disque dans le volume où réside votre $DATADIR.

  • Opérations de ligne Innodb

    Pour certaines tâches DBA, vous souhaiterez peut-être déterminer le nombre de suppressions, d'insertions, de lectures et de lignes mises à jour. Ensuite, ce graphique est ce que vous pouvez utiliser pour les vérifier.

  • Innodb Row Lock Time

    Ce graphique est une bonne ressource à consulter lorsque vous remarquez que votre application rencontre de nombreuses occurrences pour « Verrouillage du délai d'attente dépassé ; essayez de redémarrer la transaction ”. Cela peut également vous aider à déterminer si vous pourriez avoir une indication pour l'utilisation de mauvaises requêtes sur la gestion des verrous. C'est également une bonne référence à prendre en compte lors de l'optimisation de vos requêtes impliquant le verrouillage de lignes. Si le temps d'attente est trop long, vous devez vérifier le journal des requêtes lentes ou exécuter un pt-query-digest et voir quelles sont ces requêtes suspectes qui causent ce gonflement dans le graphique.

  • E/S InnoDB

    Chaque fois que vous souhaitez déterminer la quantité de lectures de données InnoDB, de vidages de disque, d'écritures et d'écritures de journal, ce graphique contient ce que vous devez examiner. Vous pouvez utiliser ce graphique pour déterminer si vos variables InnoDB sont bien réglées pour gérer vos besoins spécifiques. Par exemple, si vous avez un cache de module de sauvegarde de batterie mais que vous n'obtenez pas une grande partie de ses performances optimales, vous pouvez vous fier à ce graphique pour déterminer si vos fsyncs() sont plus élevés que prévu. Changer ensuite la variable innodb_flush_method et utiliser O_DSYNC peut résoudre le problème.

  • Utilisation horaire du fichier journal InnoDB

    Ce graphique montre uniquement le nombre d'octets écrits dans les fichiers journaux de rétablissement InnoDB et la croissance de vos fichiers journaux InnoDB en fonction de la plage horaire de 24 heures de la date actuelle.

  • Performances de journalisation InnoDB

    Ce graphique est étroitement lié au graphique horaire d'utilisation du fichier journal InnoDB. Vous devez utiliser ce graphique chaque fois que vous avez besoin de déterminer la taille de votre innodb_log_file_size. Vous pouvez déterminer le nombre d'octets écrits dans les fichiers de journalisation InnoDB et l'efficacité avec laquelle votre MySQL vide les données de la mémoire sur le disque. Chaque fois que vous rencontrez un faible besoin d'utiliser votre espace de journalisation, cela indiquerait que vous devez augmenter la taille de votre fichier innodb_log_file. Dans ce cas, ce graphique vous indiquerait que vous devez le faire. Cependant, pour en savoir plus sur la quantité dont vous avez besoin pour votre innodb_log_file, il peut être plus judicieux de vérifier le LSN (Log Sequence Number) dans SHOW ENGINE INNODB STATUS. Percona a un bon blog lié à cela qui est une bonne source à consulter.

  • Interblocages InnoDB

    Dans certaines situations où votre client d'application rencontre souvent des blocages ou si vous devez regarder à quel point votre MySQL rencontre des blocages, ce graphique sert à cela. Les interblocages indiquent que votre conception SQL est médiocre, ce qui entraîne la création par vos transactions d'une condition de concurrence provoquant des interblocages.

  • Condition déroulante de l'index

    Un petit mot de prudence en regardant ce graphique. Tout d'abord, vous devez déterminer que votre variable globale MySQL innodb_monitor_enable est définie sur la valeur correcte qui est module_icp. Sinon, vous rencontrerez un "Aucun point de données" comme indiqué ci-dessous :

    L'objectif du graphique, s'il a des points de données définis comme ce que j'ai dans les exemples de sorties, fournira à un administrateur de base de données un aperçu de la façon dont vos requêtes bénéficient de Index Condition Pushdown ou ICP en abrégé. ICP est une excellente fonctionnalité de MySQL qui offre une optimisation de vos requêtes. Au lieu que MySQL lise les lignes complètes filtrées dans vos requêtes WHERE lors de la récupération, il ajoutera plus de vérifications après vos index secondaires. Cela ajoute plus de granularité et fait gagner du temps, sinon le moteur doit lire les lignes de la table complète à la place lorsqu'il est basé uniquement sur l'index filtré et qu'aucun ICP n'est utilisé. Cela évite de lire les lignes complètes correspondant à vos tuples d'index qui correspondent à vos index secondaires.

    Permettez-moi de développer un peu ce graphique, disons que j'ai une table nommée :

    mysql> show create table a\G
*************************** 1. row ***************************
       Table: a
Create Table: CREATE TABLE `a` (
  `id` int(11) NOT NULL,
  `age` int(11) NOT NULL,
  KEY `id` (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1
1 row in set (0.00 sec)

    Et a quelques petites données :

    mysql> select * from a;
+----+-----+
| id | age |
+----+-----+
|  1 |   1 |
|  2 |   1 |
|  3 |   1 |
|  3 |  41 |
|  4 |  41 |
|  5 |   4 |
|  4 |   4 |
|  4 |   4 |
+----+-----+
8 rows in set (0.00 sec)

    Lorsque ICP est activé, les résultats sont plus efficaces et réalisables :

    mysql> explain extended select * from a where id>2 and id<4 and age=41;
+----+-------------+-------+------------+-------+---------------+------+---------+------+------+----------+------------------------------------+
| id | select_type | table | partitions | type  | possible_keys | key  | key_len | ref  | rows | filtered | Extra                              |
+----+-------------+-------+------------+-------+---------------+------+---------+------+------+----------+------------------------------------+
|  1 | SIMPLE      | a     | NULL       | range | id            | id   | 4       | NULL |    2 |    12.50 | Using index condition; Using where |
+----+-------------+-------+------------+-------+---------------+------+---------+------+------+----------+------------------------------------+
1 row in set, 2 warnings (0.00 sec)

    Que sans ICP,

    mysql> set optimizer_switch='index_condition_pushdown=off';
Query OK, 0 rows affected (0.00 sec)

mysql> explain extended select * from a where id>2 and id<4 and age=41;
+----+-------------+-------+------------+-------+---------------+------+---------+------+------+----------+-------------+
| id | select_type | table | partitions | type  | possible_keys | key  | key_len | ref  | rows | filtered | Extra       |
+----+-------------+-------+------------+-------+---------------+------+---------+------+------+----------+-------------+
|  1 | SIMPLE      | a     | NULL       | range | id            | id   | 4       | NULL |    2 |    12.50 | Using where |
+----+-------------+-------+------------+-------+---------------+------+---------+------+------+----------+-------------+
1 row in set, 2 warnings (0.00 sec)

    Ceci est un exemple simple d'ICP, et comment ce graphique peut bénéficier à un administrateur de base de données.

  • Contenu du pool de tampons InnoDB

    Lorsque vous travaillez avec MySQL et que vous utilisez le moteur InnoDB, ce graphique est l'une des valeurs les plus courantes (innodb_buffer_pool*) que vous devez régler pour optimiser les performances de MySQL. S'exprimant spécifiquement sur le contenu de son pool de mémoire tampon, il affiche les tendances des pages modifiées par rapport au contenu total du pool de mémoire tampon. Le contenu total du pool de mémoire tampon inclut les pages propres à côté des pages modifiées. En déterminant l'efficacité avec laquelle votre MySQL gère le pool de mémoire tampon, ce graphique remplit son objectif.

  • Pages du pool de tampons InnoDB

    Ce graphique est utile lorsque vous souhaitez vérifier l'efficacité de MySQL avec votre pool de mémoire tampon InnoDB. Vous pouvez utiliser ce graphique, par exemple, si votre trafic quotidien ne remplit pas le innodb_buffer_pool_size assigné, cela pourrait indiquer que certaines parties d'une application ne sont pas utiles ou ne servent à rien ou si vous définissez le innodb_buffer_pool_size très élevé ce qui peut être bon pour réduire la valeur et récupérer de l'espace dans votre mémoire.

  • E/S du pool de tampons InnoDB

    Lorsque vous devez vérifier le nombre de pages créées et écrites sur les tables InnoDB ou les pages lues dans le pool de mémoire tampon InnoDB par des opérations sur les tables InnoDB.

  • Demandes de pool de tampons InnoDB

    Lorsque vous souhaitez déterminer l'efficacité avec laquelle vos requêtes accèdent au pool de mémoire tampon InnoDB, ce graphique est utile. Ce graphique montrera les tendances basées sur les points de données sur les performances de votre serveur MySQL lorsque le moteur InnoDB doit fréquemment accéder au disque (l'indication que le pool de mémoire tampon n'a pas encore préchauffé), la fréquence à laquelle les demandes de pool de mémoire tampon traitaient les demandes de lecture et d'écriture. demandes.

  • Lecture anticipée InnoDB

    Lorsque la variable innodb_random_read_ahead est définie sur ON, ajoutez ce graphique en tant que tendance précieuse à examiner dans le cadre de votre routine DBA. Il montre les tendances sur la façon dont votre moteur de stockage MySQL InnoDB gère le pool de mémoire tampon par le thread d'arrière-plan de lecture anticipée, comment il gère ceux qui sont ensuite expulsés sans avoir été consultés par des requêtes et comment InnoDB lance la lecture anticipée aléatoire lorsqu'une requête analyse une grande partie d'un tableau mais dans un ordre aléatoire.

  • Tampon de modification InnoDB

    Lorsque Percona Server 5.7 est en cours d'exécution, ce graphique est utile pour surveiller dans quelle mesure InnoDB a alloué la mise en mémoire tampon des modifications. Ces modifications incluent les insertions, mises à jour et suppressions spécifiées par la variable innodb_change_buffering. La mise en mémoire tampon des modifications permet d'accélérer les requêtes, en évitant d'importantes E/S d'accès aléatoire qui seraient nécessaires pour lire les pages d'index secondaires à partir du disque.

  • Activité du tampon de modification d'InnoDB

    Ceci est lié au graphique InnoDB Change Buffer, mais dissèque les informations en points de données plus viables. Ceux-ci fournissent plus d'informations pour surveiller la façon dont InnoDB gère la mise en mémoire tampon des modifications. Ceci est utile dans une tâche DBA particulière pour déterminer si votre innodb_change_buffer_max_size est défini sur une valeur trop élevée, car la mise en mémoire tampon des modifications partage la même mémoire que le pool de mémoire tampon InnoDB, ce qui réduit la mémoire disponible pour les pages de données en cache. Vous devrez peut-être envisager de désactiver la mise en mémoire tampon des modifications si le jeu de travail tient presque dans le pool de mémoire tampon ou si vos tables ont relativement peu d'index secondaires. N'oubliez pas que la mise en mémoire tampon des modifications n'impose pas de temps système supplémentaire, car elle ne s'applique qu'aux pages qui ne se trouvent pas dans le pool de mémoire tampon. Ce graphique est également utile si vous devez déterminer l'utilité des fusions si vous devez comparer votre application en fonction de certaines demandes pour des scénarios particuliers. Supposons que vous ayez des insertions en masse, vous devez définir innodb_change_buffering=insert et déterminer si le fait d'avoir les valeurs définies dans votre pool de mémoire tampon et innodb_change_buffer_max_size n'a pas d'impact sur les E/S du disque, en particulier lors de la récupération ou de l'arrêt lent (nécessaire si vous souhaitez effectuer une basculement avec faible exigence de temps d'arrêt). En outre, ce graphique peut vous servir à évaluer certains scénarios, car la fusion du tampon de modifications peut prendre plusieurs heures lorsqu'il existe de nombreux index secondaires à mettre à jour et de nombreuses lignes affectées. Pendant ce temps, les E/S disque augmentent, ce qui peut entraîner un ralentissement significatif des requêtes liées au disque.

Schéma des performances MySQL

Le schéma de performances MySQL est un sujet compliqué. C'est long et difficile, mais je vais discuter uniquement des informations spécifiques aux graphiques que nous avons dans SCUMM. Vous devez également tenir compte de certaines variables et vous assurer qu'elles sont correctement définies. Assurez-vous d'avoir votre variable innodb_monitor_enable =all et userstat=1 pour voir les points de données dans vos graphiques. Notez que lorsque j'utilise le mot "événement" ici, cela ne signifie pas que cela est lié à MySQL Event Scheduler. Je parle d'événements spécifiques tels que MySQL analyse une requête, MySQL lit ou écrit dans un fichier journal relais/binaire, etc.

Continuons avec les graphiques alors.

  • E/S du fichier de schéma de performances (événements)

    Ce graphique récupère les points de données liés à tous les événements survenus dans MySQL qui auraient pu être instrumentés pour créer plusieurs instances de l'objet instrumenté (par exemple, lectures de journaux binaires ou lectures de fichiers de données InnoDB). Chaque ligne résume les événements pour un nom d'événement donné. Par exemple, s'il existe un instrument pour un mutex créé pour chaque connexion, il peut y avoir de nombreuses instances de cet événement instrumenté car il existe plusieurs connexions. La ligne récapitulative de l'instrument récapitule toutes ces instances. Vous pouvez consulter ces événements dans le manuel MySQL pour les tableaux récapitulatifs des schémas de performances pour plus d'informations.

  • E/S du fichier de schéma de performances (chargement)

    Ce graphique est identique au graphique "Performance Schema File IO (Events)" sauf qu'il est instrumenté en fonction de la charge.

  • E/S du fichier de schéma de performances (octets)

    Ce graphique est identique au graphique "Performance Schema File IO (Events)", sauf qu'il est instrumenté en fonction de la taille en octets. Par exemple, combien de temps un événement spécifique a-t-il pris lorsque MySQL a déclenché l'événement wait/io/file/innodb/innodb_data_file.

  • Attentes du schéma de performances (événements)

    Ce graphique contient le graphique de données pour toutes les attentes passées sur un événement spécifique. Vous pouvez consulter les tableaux récapitulatifs des événements d'attente dans le manuel pour plus d'informations.

  • Le schéma de performances attend (chargement)

    Identique au graphique "Performance Schema Waits (Events)", mais cette fois, il montre les tendances de la charge.

  • Opérations d'accès à l'index (chargement)

    Ce graphique est une agrégation de tous les événements d'attente d'E/S d'index de table regroupés par index(s) d'une table, tels que générés par l'instrument wait/io/table/sql/handler. Vous pouvez consulter le manuel MySQL sur la table de schéma de performance table_io_waits_summary_by_index_usage pour plus d'informations.

  • Opérations d'accès au tableau (chargement)

    Graphique "Identique aux opérations d'accès à l'index (chargement)", il s'agit d'une agrégation de tous les événements d'attente d'E/S de table groupe par table, tels que générés par l'instrument wait/io/table/sql/handler. Ceci est très utile pour les DBA. Par exemple, vous souhaitez suivre la vitesse d'accès (récupération) ou de mise à jour (insertion, suppression, mise à jour) d'une table spécifique. Vous pouvez consulter le manuel MySQL à propos de la table de schéma de performances table_io_waits_summary_by_table pour plus d'informations.

  • Schéma de performances SQL et verrous externes (événements)

    Ce graphique est une agrégation (compte du nombre de fois où cela s'est produit) de tous les événements d'attente de verrouillage de table, tels que générés par l'instrument wait/lock/table/sql/handler qui est groupé par table. Le verrou SQL ici dans le graphique signifie des verrous internes. Ces verrous internes sont en lecture normale, en lecture avec des verrous partagés, en lecture haute priorité, en lecture sans insertion, en écriture autorisée en écriture, en écriture simultanée avec insertion, en écriture différée, en écriture basse priorité, en écriture normale. Alors que les verrous externes sont en lecture externe et en écriture externe. Dans n'importe quelle tâche DBA, cela est très utile si vous devez tracer et rechercher des verrous sur une table particulière, quel que soit son type. Vous pouvez consulter le tableau table_lock_waits_summary_by_table pour plus d'informations.

  • Schéma de performance SQL et verrous externes (secondes)

    Identique au graphique « Performance Schema SQL &External Locks (Events) », mais spécifié en secondes. Si vous souhaitez rechercher les verrous de votre table en fonction des secondes pendant lesquelles les verrous ont été maintenus, ce graphique est votre bonne ressource.

Conclusion

Les métriques InnoDB et le schéma de performances MySQL sont parmi les parties les plus approfondies et les plus compliquées du domaine MySQL, en particulier lorsqu'il n'y a pas de visualisation pour faciliter l'interprétation. Ainsi, passer à une trace manuelle et à des enquêtes peut prendre une partie de votre temps et de votre travail acharné. Les tableaux de bord SCUMM offrent un moyen très efficace et pratique de les gérer et de réduire la charge supplémentaire sur toute tâche de routine DBA.

Dans ce blog, vous avez appris à utiliser les tableaux de bord pour InnoDB et Performance Schema pour améliorer les performances de la base de données. Ces tableaux de bord peuvent vous permettre d'analyser plus efficacement les performances.