Utiliser le plugin MariaDB Query Response Time pour un suivi efficace des performances

J'utilise le plugin MariaDB Query Response Time pour réponse à la requête Rendre visibles les métriques par intervalle et identifier rapidement les goulots d'étranglement. Je peux ainsi voir en quelques secondes si des requêtes se retrouvent de manière répétée dans un « bucket » lent et en tirer les conclusions qui s'imposent Optimisations pour mon suivi.

Points centraux

Avant d'entrer dans les détails, je vais résumer brièvement les aspects les plus importants afin que tu puisses bien cerner les prochaines étapes. Je me concentrerai sur les avantages, la mise en œuvre, l'évaluation et l'intégration dans les outils existants, car c'est précisément là que réside le principal levier pour améliorer les performances. Les points clés suivants te fournissent les lignes directrices pour la mise en œuvre technique et l'utilisation quotidienne du plugin. Ils constituent un bon aide-mémoire pour les tâches récurrentes. Grâce à cet aperçu concis, je garde ma Priorités à l'œil et m'assure une Résultats.

• histogramme Au lieu de la moyenne : la répartition des durées met clairement en évidence les valeurs aberrantes.
• Simple Activation: de manière dynamique via INSTALL ou de manière statique via la configuration.
• Rapide Analyses: SHOW/FLUSH pour les fenêtres de mesure et les comparaisons.
• Sans couture Intégration: Données exploitables dans les tableaux de bord et les alertes.
• Clairement Définition des priorités: La proportion de requêtes lentes est directement visible.

Principe de base et architecture

À chaque requête, le plugin enregistre la durée d'exécution et la répartit entre des compartiments qui fonctionnent comme un histogramme fonctionner. Je consulte cette répartition et je vois immédiatement s'il y a beaucoup d'instructions inférieures à 1 ms ou si les tranches de quelques secondes prennent de l'ampleur. Deux éléments sont au cœur de ce concept : une partie « audit » qui effectue les mesures pendant l’exécution, et une partie « INFORMATION_SCHEMA » qui rend les données accessibles. Ainsi, je n’obtiens pas seulement des valeurs moyennes, mais une véritable Distribution sur toutes les classes de temps. C'est précisément cette vue d'ensemble qui m'aide à distinguer les valeurs aberrantes ponctuelles des problèmes systématiques et à planifier des mesures de manière ciblée.

Activation : dynamique et statique

J'active le Plugin en cours de fonctionnement avec INSTALL SONAME/INSTALL PLUGIN, puis je définis query_response_time_stats sur ON. Ces étapes lancent immédiatement la collecte des statistiques, sans redémarrer le serveur. Sinon, j'ajoute plugin_load_add dans la configuration afin que MariaDB charge le module au démarrage. Dans les configurations en cluster, je veille à ce que ce paramètre soit cohérent sur tous les nœuds concernés, afin que mes Valeurs mesurées restent comparables. Je m'assure ainsi de disposer de données cohérentes que je peux comparer de manière précise entre les environnements de test, de préproduction et de production.

Comprendre les données : histogramme des durées

Je récupère la répartition via INFORMATION_SCHEMA.QUERY_RESPONSE_TIME ou via SHOW QUERY_RESPONSE_TIME, puis j'analyse les Seaux . Chaque ligne indique une limite de temps maximale, le nombre de requêtes et la durée totale d'exécution pour cet intervalle. Cela me permet d'identifier la charge en millisecondes et de repérer les pics en secondes potentiels. Je vérifie régulièrement l'évolution de la Distribution après des modifications apportées aux index, aux caches ou aux configurations. Cette approche empêche que certaines valeurs moyennes ne masquent de réels problèmes de latence.

Utiliser efficacement les commandes SHOW et FLUSH

Je lance de nouvelles fenêtres de mesure avec FLUSH QUERY_RESPONSE_TIME afin de pouvoir effectuer des comparaisons « avant-après » précises. Ensuite, je consulte la répartition actuelle avec SHOW QUERY_RESPONSE_TIME et je vérifie si le nombre de compartiments rapides augmente. C’est notamment lors des tests de mise en production que cela me permet, en quelques minutes, de voir clairement si les modifications apportées aux requêtes sont efficaces. Je combine FLUSH avec des tâches récurrentes qui récupèrent les données et les stockent de manière centralisée. C’est ainsi que je maintiens mon Tendances à l'œil et repère les changements insidieux dégradations dès le début.

Intégration dans des outils de surveillance

J'intègre ces répartitions dans des tableaux de bord et je les combine avec des indicateurs relatifs au processeur, aux E/S et aux verrous. Pour des analyses plus approfondies, j'utilise également Surveillance du schéma de performances, afin d'examiner en détail les temps d'attente et les étapes. Cette combinaison me permet de déterminer si les latences élevées proviennent du stockage, des verrous ou de plans inefficaces. Je configure les alertes de manière à ce qu'un certain pourcentage doive être enregistré dans des segments lents avant que je ne reçoive une notification. Cela réduit Bruit et concentre mon réaction aux vrais problèmes.

Situations du quotidien et mesures concrètes

Après une mise en production, je commence par vérifier la répartition afin de voir si de larges pans de la charge sont devenus plus lents. Si je constate de nouveaux pics de l'ordre de quelques secondes, je lance une analyse approfondie ciblée sur les charges de travail concernées. Lors de l'optimisation des index, je vide les statistiques, je génère une charge et je vérifie si la proportion de « buckets » rapides augmente. Pour les plans de requêtes délicats, je jette également un œil dans le Optimizer Trace, pour comprendre les décisions stratégiques. C'est ainsi que je fais le lien entre Visibilité issu de la distribution, avec analyse des causes, sur Déclaration-niveau.

Bonnes pratiques pour des résultats mesurables

Je définis des plages de mesure fixes, par exemple quotidiennes avec un FLUSH nocturne, afin de pouvoir comparer les tendances de manière fiable. De plus, je dispose de mesures ponctuelles avant et après les modifications, ce qui me permet d'évaluer directement leurs effets. Dans les systèmes fortement sollicités, je vérifie le Overhead en bref, ce qui, dans la pratique, s'avère généralement modéré. J'intègre automatiquement l'analyse, j'exporte les segments et je les archive par tranches de temps. Cette routine permet de Transparence et me fait gagner du temps lors des audits ou des analyses rétrospectives.

Remédier rapidement aux sources d'erreurs

Si SHOW ou la table n'existent pas, je vérifie d'abord si je peux Plugin que je l'ai correctement chargé. Ensuite, je vérifie la valeur de `query_response_time_stats` ; si elle est définie sur `OFF`, MariaDB ne collecte pas de données. Si les droits font défaut, j'ajuste les privilèges pour l'installation ou le vidage. En cas de différences de version, je compare les variantes syntaxiques de INSTALL SONAME et INSTALL PLUGIN afin d'éviter tout conflit. Je conserve également mon Documentation à jour, afin que les vérifications récurrentes s'effectuent rapidement.

Comparer les indicateurs : tableau

J'utilise ce plugin en complément de Slow Query Log et de Performance Schema, car chaque source offre une perspective différente. Le tableau suivant m'aide à exploiter leurs atouts de manière ciblée et à éviter les fausses attentes. Pour obtenir des informations détaillées, je consulte mon Analyse du journal des requêtes lentes, tout en utilisant la répartition par compartiments pour établir des priorités. Lors de la planification, cela me permet de réduire les angles morts et d’identifier plus tôt les tendances. Cela conduit à clair Des décisions plus rapides et itérations.

Caractéristique	Plugin de temps de réponse des requêtes	Journal des requêtes lent	Schéma de performance
Granularité	Répartition selon Seaux (histogramme)	Quelques lents Déclarations	Réglages fins : Waits/Stages/Locks
Source des données	INFORMATION_SCHEMA/SHOW	Fichier journal ou tableau	Vues de performance internes
Aptitude	Vue d'ensemble, tendances, alertes	Causes au niveau des instructions	Analyse approfondie des causes profondes
Overhead	Faible, facile à contrôler	Moyenne, en fonction des seuils	Variable, en fonction de l'activation
Réinitialiser	VIDER LA MÉMOIRE CACHÉE DE QUERY_RESPONSE_TIME	Rotation des journaux/Troncature	En fonction du contexte
Fugueurs	Répartition en pourcentage visible	On distingue certaines pointes	Causes des temps d'attente identifiables

Rôle dans le suivi global

J'utilise la répartition par segments comme indicateur clé dans mes tableaux de bord, car elle reflète la Latence qui reflète bien le comportement de l'utilisateur. Si la proportion de « buckets » lents augmente, je renforce l'urgence de mon analyse. La corrélation avec les métriques du système m'indique si je dois m'attaquer aux problèmes liés au CPU, à la RAM, aux E/S ou aux verrous. Je vérifie également si les stratégies de mise en cache sont efficaces ou si une augmentation du volume de données nécessite la création de nouveaux index. À partir de cette vue d’ensemble, je déduis des mesures concrètes Actions plutôt que de me perdre dans les détails.

Personnaliser la conception du seau de manière ciblée

J'adapte la résolution des buckets à mes charges de travail. Si des détails de l'ordre de la sous-milliseconde me manquent, j'augmente la résolution à ce niveau. Si les requêtes sont plutôt mesurées en secondes, j'élargis les classes supérieures. L'important, c'est de trouver le bon compromis : davantage de buckets permettent d'obtenir une résolution plus fine Aperçus, mais elles augmentent légèrement la charge de mesure et le volume de données à exporter. Je vérifie mes variables actives à l'aide de la commande SHOW VARIABLES LIKE ‚query_response_time%‘ ; et je documente le choix effectué pour chaque environnement. Je déploie les modifications de manière coordonnée afin que les séries chronologiques restent comparables entre les nœuds et les environnements. Je lance toujours les changements de configuration par un FLUSH ciblé afin d’observer l’effet de la nouvelle résolution dans une nouvelle fenêtre de mesure.

Dans la pratique, je garde à l'esprit les questions suivantes : l'échelle par tranches couvre-t-elle mes SLO (par exemple, 95% en moins de 100 ms) ? Est-ce que j'identifie suffisamment clairement les classes présentant des valeurs aberrantes ? Les agrégations pour les tableaux de bord sont-elles stables (pas de changements fréquents d'échelle) ? C'est ainsi que je m'assure que l'histogramme sert de base aux décisions et n'est pas simplement un “ plus ” facultatif.

Déterminer les centiles à partir des tranches

Je déduis les valeurs p90/p95/p99 à partir de la distribution de l'histogramme, sans enregistrer chaque instruction dans le journal. Pour ce faire, je cumule les valeurs des compartiments par ordre croissant jusqu'à atteindre le pourcentage souhaité. J'utilise la limite du compartiment correspondante comme estimation prudente du centile. Cela me suffit pour la surveillance des SLO et Alertes. J'ajoute : en cas de forte concentration au bord du “ bucket ”, je prévois des limites plus étroites ou des classes supplémentaires afin d'éviter que les centiles ne « sautent ». Cette méthode est robuste, rapide et ne sollicite pratiquement pas le serveur – elle est donc idéale pour une surveillance continue.

Pour les calculs ponctuels, j'utilise de simples variables SQL afin de calculer des sommes cumulées sur INFORMATION_SCHEMA.QUERY_RESPONSE_TIME. Dans les environnements de production, je calcule les centiles dans mon système de métriques après avoir exporté les tranches, ce qui me permet d'effectuer des analyses historiques et comparatives.

Réplication, Galera et haute disponibilité

Dans le réseau de réplication, les histogrammes sont spécifique à un nœud. C'est voulu, car les charges de travail sur les nœuds primaires et secondaires diffèrent (charge d'écriture vs charge de lecture). Je conserve néanmoins la même configuration pour les plugins afin de pouvoir attribuer clairement les différences. Dans les configurations Galera, la répartition des buckets par nœud m’aide à mettre en évidence les points chauds dans les clusters de lecture et à ajuster l’équilibrage de charge. Après les basculements, je redéfinis les fenêtres de mesure et je les marque dans mes tableaux de bord afin d’interpréter correctement les variations. Important : les compteurs sont volatils ; après les redémarrages, je commence délibérément avec une nouvelle fenêtre, mais j’exporte les dernières valeurs avant les fenêtres de maintenance afin de minimiser les ruptures dans la série chronologique.

Exportation automatique et gestion des données

Pour analyser les tendances et réaliser des audits, j'exporte régulièrement les buckets. Je privilégie la requête issue d'INFORMATION_SCHEMA, car elle est lisible par machine. La tâche enregistre l'horodatage, le nœud, l'environnement et tous les buckets dans un pipeline de métriques ou dans une table dédiée. Je procède délibérément à la réinitialisation : soit je vide les buckets après l'exportation (analyse par fenêtre glissante), soit je collecte les données de manière cumulative et je calcule les différences en externe (modèle de compteur). Les deux variantes ont leur raison d'être – l'important est de choisir une approche par tableau de bord afin que les alertes restent cohérentes.

Pour les vérifications rapides dans des environnements de test, j'utilise de simples exportations au format CSV que j'analyse à l'aide d'outils standard. En production, je privilégie un processus d'exportation allégé et reproductible, avec une gestion claire des erreurs, afin de ne perdre aucune fenêtre de mesure.

Sécurité, droits et gouvernance

Pour INSTALLER/DÉSINSTALLER le plugin, j'ai besoin des privilèges appropriés (par exemple, INSTALL PLUGIN ou des droits d'administrateur). Des droits élevés sont également nécessaires pour la commande FLUSH QUERY_RESPONSE_TIME. Je considère qu’il est judicieux d’appliquer des restrictions à la lecture des données, car même les métriques peuvent permettre de tirer des conclusions sur les charges de travail. Dans les environnements réglementés, je consigne les modifications apportées à l'état et à la configuration du plugin. Je définis qui est autorisé à lancer des fenêtres de mesure et j'indique dans les tableaux de bord quand et par qui un FLUSH a été effectué. Ainsi, les analyses restent traçables et conformes aux exigences d'audit.

Limites et délimitation

Le plugin mesure la Côté serveur Temps d'exécution – la latence réseau et les tentatives de connexion du client ne sont pas prises en compte. Le texte de la requête, l'utilisateur, le schéma ou l'origine ne sont pas enregistrés ; pour cela, j'utilise en complément le Slow Query Log et le Performance Schema. Il n'y a pas de persistance : après un redémarrage, les compteurs sont remis à zéro, c'est pourquoi j'effectue régulièrement des exportations. Le plugin ne propose pas de filtrage granulaire (par exemple, uniquement les SELECT) ; je résous cela de manière opérationnelle à l’aide de fenêtres de mesure pendant une charge ciblée ou en corrélant les buckets avec les logs. En cas de QPS très élevés, je vérifie rapidement la surcharge à l’aide de mesures A/B ; dans la pratique, elle est faible, mais je ne mesure jamais “ à l’aveugle ”.

Diagnostic approfondi : obstacles typiques

Si la commande SHOW QUERY_RESPONSE_TIME n'est pas disponible, je vérifie si le nom du plugin est correct et si le module se trouve bien dans le répertoire plugin_dir. Je vérifie les modules chargés avec SHOW PLUGINS et je compare les chemins d’accès. Si la syntaxe diffère d’une version à l’autre, j’utilise la forme alternative de la commande INSTALL (avec SONAME) et je note la variante qui fonctionne dans la documentation interne. Si les valeurs de INFORMATION_SCHEMA ne correspondent pas à celles de SHOW, cela est généralement dû à un FLUSH intermédiaire ou à un chevauchement des fenêtres de mesure ; je répète alors la mesure de manière structurée. Si des erreurs de droits surviennent lors du FLUSH, je vérifie les privilèges spécifiques au lieu d’attribuer SUPER de manière générale.

Des tableaux de bord et des alertes qui sont vraiment utiles

Je représente les segments de manière cumulative et sous forme de pourcentages, et pas seulement en chiffres absolus. Cela permet de mettre en évidence les variations de la charge (augmentation du nombre total de requêtes) provenant de Décalages de latence découplées. Je formule les alertes dans un langage métier : “ >5% des requêtes supérieures à 500 ms pendant plus de 10 minutes ” au lieu de “ moyenne > 120 ms ”. De plus, j’utilise des alertes de tendance (augmentation de la proportion de requêtes lentes) et des stabilisateurs (hystérésis) afin d’éviter le « bruit » des alertes. Dans les environnements à plusieurs nœuds, j’agrège les données par rôle (Writer/Reader) et j’affiche en outre les principales sources de problèmes issues du schéma Log/Performance, afin que l’escalade puisse se faire directement avec un Plan d'action démarre.

Tests méthodologiques et mesure des frais généraux

Je teste systématiquement la surcharge : scénario de charge court sans plugin, puis avec le plugin chargé, puis avec les statistiques actives. Je mesure le débit, l'utilisation du processeur et la répartition de la latence. Je répète la même procédure en modifiant la résolution des buckets. Je documente les résultats pour ma propre plateforme, plutôt que de me fier à des affirmations générales. Cela me permet ainsi de valider le plugin même dans des systèmes strictement réglementés. Pour les fonctionnalités dont je n'ai besoin que ponctuellement (par exemple, des buckets plus étroits de l'ordre de la sous-milliseconde), j'en limite l'utilisation à des fenêtres de mesure courtes et clairement définies.

Guide pratique sur les modifications

Avant toute modification structurelle (index, paramètre, déploiement), je vide le cache, je définis une fenêtre temporelle et je collecte en parallèle les métriques du système. Une fois la modification effectuée, je répète exactement la même procédure. Ce qui est déterminant, c'est la Symétrie de la mesure : charge identique, même période, même agrégation. Je compare les pourcentages par tranche et je les évalue par rapport à mes SLO. Ce n’est que lorsque les tranches rapides augmentent de manière significative ou que les tranches lentes diminuent que je considère la mesure comme un succès. Si la répartition reste inchangée, je recourt à des outils plus avancés (Optimizer Trace, Performance Schema) ou j’ajuste mon hypothèse.

Résumé : Obtenir des réponses claires plus rapidement

Grâce au plugin « Query Response Time », je peux rapidement me faire une idée précise de la répartition des temps de réponse des requêtes. J'active le Module Ciblez, videz les fenêtres de mesure et comparez l'évolution avant et après les modifications. La combinaison avec le Slow Query Log, le Performance Schema et, le cas échéant, les analyses de l'optimiseur permet de cerner entièrement les causes. Au quotidien, je me concentre sur les « buckets » qui débordent et j'en déduis des mesures concrètes Mesures . Cela me permet de garantir une expérience utilisateur fluide et de maîtriser les coûts liés à ma base de données.