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

Conseils pour fournir des performances de base de données MySQL - Deuxième partie

La gestion des performances des bases de données est un domaine dans lequel les entreprises se retrouvent souvent lorsque les administrateurs consacrent plus de temps que prévu.

Surveiller et réagir aux problèmes de performances de la base de données de production est l'une des tâches les plus critiques d'un poste d'administrateur de base de données. C'est un processus continu qui nécessite des soins constants. Les bases de données d'application et sous-jacentes évoluent généralement avec le temps; augmenter la taille, le nombre d'utilisateurs, la charge de travail, les changements de schéma qui accompagnent les changements de code.

Les requêtes de longue durée sont rarement inévitables dans une base de données MySQL. Dans certaines circonstances, une requête de longue durée peut être un événement nuisible. Si vous vous souciez de votre base de données, l'optimisation des performances des requêtes et la détection des requêtes de longue durée doivent être effectuées régulièrement.

Dans ce blog, nous allons examiner plus en détail la charge de travail réelle de la base de données, en particulier du côté des requêtes en cours d'exécution. Nous verrons comment suivre les requêtes, quel type d'informations nous pouvons trouver dans les métadonnées MySQL, quels outils utiliser pour analyser ces requêtes.

Gérer les requêtes de longue durée

Commençons par vérifier les requêtes de longue durée. Tout d'abord, nous devons connaître la nature de la requête, s'il s'agit d'une requête longue ou courte. Certaines opérations analytiques et par lots sont censées être des requêtes de longue durée, nous pouvons donc les ignorer pour le moment. De plus, selon la taille de la table, la modification de la structure de la table avec la commande ALTER peut être une opération de longue haleine (en particulier dans les clusters MySQL Galera).

  • Verrou de table :la table est verrouillée par un verrou global ou un verrou de table explicite lorsque la requête tente d'y accéder.
  • Requête inefficace :utilisez des colonnes non indexées lors de la recherche ou de la jointure, MySQL prend donc plus de temps pour répondre à la condition.
  • Interblocage :une requête attend pour accéder aux mêmes lignes qui sont verrouillées par une autre requête.
  • L'ensemble de données ne tient pas dans la RAM :si les données de votre ensemble de travail tiennent dans ce cache, les requêtes SELECT seront généralement relativement rapides.
  • Ressources matérielles sous-optimales - Cela peut être des disques lents, une reconstruction RAID, un réseau saturé, etc.

Si vous constatez qu'une requête prend plus de temps que d'habitude à s'exécuter, examinez-la.

Utiliser la liste des processus d'affichage de MySQL

​MYSQL> SHOW PROCESSLIST;

C'est généralement la première chose que vous exécutez en cas de problèmes de performances. SHOW PROCESSLIST est une commande mysql interne qui vous montre quels threads sont en cours d'exécution. Vous pouvez également voir ces informations à partir de la table information_schema.PROCESSLIST ou de la commande mysqladmin process list. Si vous disposez du privilège PROCESS, vous pouvez voir tous les threads. Vous pouvez voir des informations telles que l'identifiant de la requête, le temps d'exécution, qui l'exécute, l'hôte client, etc. Les informations sont légèrement méfiantes en fonction de la saveur et de la distribution MySQL (Oracle, MariaDB, Percona)

SHOW PROCESSLIST;

+----+-----------------+-----------+------+---------+------+------------------------+------------------+----------+

| Id | User            | Host | db | Command | Time | State                  | Info | Progress |

+----+-----------------+-----------+------+---------+------+------------------------+------------------+----------+

|  2 | event_scheduler | localhost | NULL | Daemon  | 2693 | Waiting on empty queue | NULL   | 0.000 |

|  4 | root            | localhost | NULL | Query   | 0 | Table lock   | SHOW PROCESSLIST | 0.000 |

+----+-----------------+-----------+------+---------+------+------------------------+------------------+----------+

nous pouvons immédiatement voir la requête offensante dès la sortie. Dans l'exemple ci-dessus, il pourrait s'agir d'un verrou de table. Mais à quelle fréquence regardons-nous ces processus ? Ceci n'est utile que si vous êtes au courant de la transaction de longue durée. Sinon, vous ne le sauriez pas jusqu'à ce que quelque chose se produise - comme les connexions s'accumulent ou le serveur devient plus lent que d'habitude.

Utilisation de MySQL Pt-query-digest

Si vous souhaitez voir plus d'informations sur une charge de travail particulière, utilisez pt-query-digest. Le pt-query-digest est un outil Linux de Percona pour analyser les requêtes MySQL. Cela fait partie de la boîte à outils Percona que vous pouvez trouver ici. Il prend en charge les distributions Linux 64 bits les plus populaires telles que Debian, Ubuntu et Redhat.

Pour l'installer, vous devez configurer les référentiels Percona, puis installer le package perona-toolkit.

Installez Percona Toolkit à l'aide de votre gestionnaire de packages :

Debian ou Ubuntu :

sudo apt-get install percona-toolkit

RHEL ou CentOS :

sudo yum install percona-toolkit

Pt-query-digest accepte les données de la liste des processus, du journal général, du journal binaire, du journal lent ou de tcpdump En plus de cela, il est possible d'interroger la liste des processus MySQL à un intervalle défini - un processus cela peut être gourmand en ressources et loin d'être idéal, mais peut toujours être utilisé comme alternative.

La source la plus courante pour pt-query-digest est un journal de requêtes lent. Vous pouvez contrôler la quantité de données qui y sera envoyée avec le paramètre log_slow_verbosity.

Il y a un certain nombre de choses qui peuvent rendre l'exécution d'une requête plus longue :

  • microtime - requêtes avec une précision de l'ordre de la microseconde.
  • query_plan - informations sur le plan d'exécution de la requête.
  • innodb  – Statistiques InnoDB.
  • minimal – Équivaut à activer uniquement le microtime.
  • standard - Équivalent à l'activation de microtime, innodb.
  • full – Équivalent à toutes les autres valeurs combinées OR sans les options de profilage et profiling_use_getrusage.
  • profilage :permet le profilage de toutes les requêtes dans toutes les connexions.
  • profiling_use_getrusage - Active l'utilisation de la fonction getrusage.

source :documentation Percona

Pour être complet, utilisez log_slow_verbosity=full, ce qui est un cas courant.

Journal des requêtes lentes

Le journal des requêtes lentes peut être utilisé pour trouver des requêtes qui prennent beaucoup de temps à s'exécuter et sont donc candidates à l'optimisation. Le journal des requêtes lentes capture les requêtes lentes (instructions SQL dont l'exécution prend plus de long_query_time secondes) ou les requêtes qui n'utilisent pas d'index pour les recherches (log_queries_not_using_indexes). Cette fonctionnalité n'est pas activée par défaut et pour l'activer, définissez simplement les lignes suivantes et redémarrez le serveur MySQL :

[mysqld]
slow_query_log=1
log_queries_not_using_indexes=1
long_query_time=0.1

Le journal des requêtes lentes peut être utilisé pour trouver des requêtes qui prennent beaucoup de temps à s'exécuter et sont donc candidates à l'optimisation. Cependant, l'examen d'un journal de requêtes long et lent peut être une tâche fastidieuse. Il existe des outils pour analyser les fichiers journaux des requêtes lentes MySQL et résumer leur contenu comme mysqldumpslow, pt-query-digest.

Schéma de performances

Performance Schema est un excellent outil disponible pour surveiller les composants internes du serveur MySQL et les détails d'exécution à un niveau inférieur. Il avait une mauvaise réputation dans une première version (5.6) car son activation provoquait souvent des problèmes de performances, mais les versions récentes ne nuisent pas aux performances. Les tableaux suivants dans Performance Schema peuvent être utilisés pour rechercher des requêtes lentes :

  • events_statements_current
  • events_statements_history
  • events_statements_history_long
  • events_statements_summary_by_digest
  • events_statements_summary_by_user_by_event_name
  • events_statements_summary_by_host_by_event_name

MySQL 5.7.7 et versions ultérieures incluent le schéma sys, un ensemble d'objets qui aide les administrateurs de base de données et les développeurs à interpréter les données collectées par le schéma de performances sous une forme plus facilement compréhensible. Les objets de schéma Sys peuvent être utilisés pour des cas d'utilisation typiques de réglage et de diagnostic.

Suivi du réseau

Que se passe-t-il si nous n'avons pas accès au journal des requêtes ou aux journaux des applications directes ? Dans ce cas, nous pourrions utiliser une combinaison de tcpdump et pt-query digest qui pourrait aider à capturer les requêtes.

$ tcpdump -s 65535 -x -nn -q -tttt -i any port 3306 > mysql.tcp.txt

Une fois le processus de capture terminé, nous pouvons procéder au traitement des données :

$ pt-query-digest --limit=100% --type tcpdump mysql.tcp.txt > ptqd_tcp.out

Moniteur de requête ClusterControl

ClusterControl Query Monitor est un module dans un contrôle de cluster qui fournit des informations combinées sur l'activité de la base de données. Il peut collecter des informations à partir de plusieurs sources, telles que la liste des processus d'affichage ou le journal des requêtes lentes, et les présenter de manière pré-agrégée.

La surveillance SQL est divisée en trois sections.

Requêtes principales

présente les informations sur les requêtes qui consomment une part importante des ressources.

Exécuter des requêtes

il s'agit d'une liste de processus d'informations combinées à partir de tous les nœuds du cluster de base de données en une seule vue. Vous pouvez l'utiliser pour tuer les requêtes qui affectent vos opérations de base de données.

Requêtes aberrantes

présente la liste des requêtes dont le temps d'exécution est supérieur à la moyenne.

Conclusion

C'est tout pour la deuxième partie. Ce blog n'est pas destiné à être un guide exhaustif sur la façon d'améliorer les performances de la base de données, mais il donne, espérons-le, une image plus claire de ce qui peut devenir essentiel et de certains des paramètres de base qui peuvent être configurés. N'hésitez pas à nous faire savoir si nous avons oublié des éléments importants dans les commentaires ci-dessous.