Les mauvaises performances des requêtes sont le problème le plus courant auquel les DBA doivent faire face. Il existe de nombreuses façons de collecter, de traiter et d'analyser les données liées aux performances des requêtes. Nous avons abordé l'un des outils les plus populaires, pt-query-digest, dans certains de nos précédents articles de blog :
Devenez une série de blogs MySQL DBA
- Analyse de votre charge de travail SQL à l'aide de pt-query-digest
- Analyse approfondie de la charge de travail SQL à l'aide de pt-query-digest
Cependant, lorsque vous utilisez ClusterControl, cela n'est pas toujours nécessaire. Vous pouvez utiliser les données disponibles dans ClusterControl pour résoudre votre problème. Dans cet article de blog, nous verrons comment ClusterControl peut vous aider à résoudre les problèmes liés aux performances des requêtes.
Il peut arriver qu'une requête ne puisse pas se terminer en temps voulu. La requête peut être bloquée en raison de certains problèmes de verrouillage, elle peut ne pas être optimale ou ne pas être indexée correctement ou elle peut être trop lourde à terminer dans un laps de temps raisonnable. Gardez à l'esprit que quelques jointures non indexées peuvent facilement analyser des milliards de lignes si vous avez une grande base de données de production. Quoi qu'il en soit, la requête utilise probablement certaines des ressources - que ce soit le processeur ou les E/S pour une requête non optimisée ou même simplement des verrous de ligne. Ces ressources sont également nécessaires pour d'autres requêtes et cela peut sérieusement ralentir les choses. L'une des tâches très simples mais importantes serait d'identifier la requête incriminée et de l'arrêter.
C'est assez facile à faire depuis l'interface ClusterControl. Accédez à l'onglet Query Monitor -> section Running Queries - vous devriez voir une sortie similaire à la capture d'écran ci-dessous.
Comme vous pouvez le voir, nous avons une pile de requêtes bloquées. Habituellement, la requête incriminée est celle qui prend beaucoup de temps, vous voudrez peut-être la tuer. Vous voudrez peut-être aussi l'étudier plus avant pour vous assurer de choisir le bon. Dans notre cas, nous voyons clairement un SELECT … FOR UPDATE qui joint deux tables et qui est dans l'état "Envoi de données", ce qui signifie qu'il traite les données pendant les 90 dernières secondes.
Un autre type de question auquel un administrateur de base de données peut devoir répondre est :quelles requêtes prennent le plus de temps à s'exécuter ? C'est une question courante, car de telles requêtes peuvent être un fruit à portée de main - elles peuvent être optimisables, et plus le temps d'exécution d'une requête donnée est responsable dans un mélange de requêtes complet, plus le gain de son optimisation est important. C'est une équation simple :si une requête est responsable de 50 % du temps d'exécution total, la rendre 10 fois plus rapide donnera de bien meilleurs résultats que d'optimiser une requête qui ne représente que 1 % du temps d'exécution total.
ClusterControl peut vous aider à répondre à ces questions, mais nous devons d'abord nous assurer que le moniteur de requête est activé. Vous pouvez basculer le Query Monitor sur ON sous la page Query Monitor. De plus, vous pouvez configurer l'option "Long Query Time" et "Log queries not using indexes" sous Paramètres en fonction de votre charge de travail :
Le moniteur de requêtes dans ClusterControl fonctionne en deux modes, selon que vous disposez ou non du schéma de performances avec les données requises sur les requêtes en cours d'exécution. S'il est disponible (et cela est vrai par défaut dans MySQL 5.6 et versions ultérieures), le schéma de performances sera utilisé pour collecter les données de requête, minimisant ainsi l'impact sur le système. Sinon, le journal des requêtes lentes sera utilisé et tous les paramètres visibles dans la capture d'écran ci-dessus seront utilisés. Celles-ci sont assez bien expliquées dans l'interface utilisateur, il n'est donc pas nécessaire de le faire ici. Lorsque le moniteur de requêtes utilise le schéma de performances, ces paramètres ne sont pas utilisés (sauf pour activer/désactiver le moniteur de requêtes pour activer/désactiver la collecte de données).
Lorsque vous avez confirmé que Query Monitor est activé dans ClusterControl, vous pouvez accéder à Query Monitor -> Top Requêtes, où un écran similaire à celui ci-dessous vous sera présenté :
Ce que vous pouvez voir ici est une liste des requêtes les plus coûteuses (en termes de temps d'exécution) qui ont frappé notre cluster. Chacun d'eux a quelques détails supplémentaires - combien de fois il a été exécuté, combien de lignes ont été examinées ou envoyées au client, comment le temps d'exécution a varié, combien de temps le cluster a passé à exécuter un type de requête donné. Les requêtes sont regroupées par type de requête et schéma.
Vous serez peut-être surpris de découvrir que l'endroit principal où le temps d'exécution est passé est une requête "COMMIT". En fait, c'est assez typique pour les requêtes OLTP rapides exécutées sur le cluster Galera. Commettre une transaction est un processus coûteux car la certification doit avoir lieu. Cela fait de COMMIT l'une des requêtes les plus chronophages du mélange de requêtes.
Lorsque vous cliquez sur une requête, vous pouvez voir la requête complète, le temps d'exécution maximum, le nombre d'occurrences, quelques conseils d'optimisation généraux et une sortie EXPLAIN pour celle-ci - très utile pour identifier si quelque chose ne va pas. Dans notre exemple, nous avons coché un SELECT … FOR UPDATE avec un nombre élevé de lignes examinées. Comme prévu, cette requête est un exemple de SQL terrible - un JOIN qui n'utilise aucun index. Vous pouvez voir sur la sortie EXPLAIN qu'aucun index n'est utilisé, pas un seul n'a même été considéré comme pouvant être utilisé. Pas étonnant que cette requête ait sérieusement impacté les performances de notre cluster.
Une autre façon d'avoir un aperçu des performances des requêtes consiste à regarder Query Monitor -> Query Outliers. Il s'agit essentiellement d'une liste de requêtes dont les performances diffèrent considérablement de leur moyenne.
Comme vous pouvez le voir dans la capture d'écran ci-dessus, la deuxième requête a pris 0,01116 s (le temps est affiché en millisecondes) où le temps d'exécution moyen pour cette requête est beaucoup plus faible (0,000142 s). Nous avons également des informations statistiques supplémentaires sur l'écart type et le temps d'exécution maximal des requêtes. Une telle liste de requêtes peut sembler peu utile - ce n'est pas vraiment vrai. Lorsque vous voyez une requête sur cette liste, cela signifie que quelque chose était différent de l'habituel - la requête ne s'est pas terminée en temps normal. Cela peut être une indication de certains problèmes de performances sur votre système et un signal que vous devriez étudier d'autres mesures et vérifier si quelque chose d'autre s'est produit à ce moment-là.
Les gens ont tendance à se concentrer sur l'obtention de performances maximales, oubliant qu'il ne suffit pas d'avoir un débit élevé - il doit également être cohérent. Les utilisateurs aiment que les performances soient stables - vous pourrez peut-être extraire plus de transactions par seconde de votre système, mais si cela signifie que certaines transactions commenceront à se bloquer pendant quelques secondes, cela n'en vaut pas la peine. L'examen de l'histogramme de requête dans ClusterControl vous aide à identifier ces problèmes de cohérence dans votre combinaison de requêtes.
Bonne surveillance des requêtes !
PS. :Pour démarrer avec ClusterControl, cliquez ici !
