Cette page décrit Calíope 1.5, la version que je construis en ce moment. La 1.4 est sur l'App Store pour Mac, iPad, iPhone, Apple Watch, Apple TV et Apple Vision Pro. Le changelog indique dans quelle version chaque fonction est arrivée.
Ajoute un bouton « Ouvrir dans Calíope » à chaque sujet. Ne fonctionne qu'avec l'app installée.
Ce que le serveur a noté de lui-même sur les requêtes ayant dépassé son seuil, pour tous ses clients.
Où le trouver : Espace de travail › Outils › Requêtes lentes
Voici ce que le serveur a noté de lui-même : les requêtes qui ont dépassé son seuil, venant de tous ses clients et pas seulement de Calíope. Le journal des requêtes de l'app est autre chose —ce que vous avez exécuté d'ici— et il a son propre outil.
La barre propose jusqu'à trois vues, et lesquelles existent dépend du serveur : Réglages, toujours ; Entrées, une ligne par exécution, seulement si le moteur conserve les exécutions individuelles et laisse un client les lire ; Par instruction, le résumé groupé par forme de requête, seulement si le moteur le publie. Une vue que le serveur ne peut pas remplir n'est pas dessinée en grisé : elle n'est pas dessinée.
MySQLMariaDBAurora
La famille MySQL donne les deux : mysql.slow_log conserve les exécutions —avec leur heure, leur utilisateur et le texte littéral— et performance_schema conserve le résumé par forme.
PostgreSQL
PostgreSQL ne conserve aucune exécution lisible par un client : son journal part dans un fichier de la machine du serveur. Ce qu'il publie, c'est l'agrégat, via pg_stat_statements, donc vous verrez ici Par instruction et non Entrées.
SQL Server
SQL Server n'a pas de journal des requêtes lentes : ni seuil ni exécutions enregistrées. Ce qu'il tient, toujours et sans rien activer, c'est le décompte de chaque plan de son cache, et c'est ce que vous verrez dans Par instruction. Entrées n'apparaît pas.
Pour voir une ligne entière —le texte complet et tout ce que le serveur a noté— double-cliquez dessus sur le Mac ou touchez-la sur l'iPad. Depuis sa fiche, la requête se copie ou part vers l'éditeur.
Le sélecteur de droite dit combien de lignes sont demandées : cinquante pour voir ce qui se passe maintenant, mille pour examiner la journée entière. L'actualisation automatique relit toutes les dix secondes, et la barre indique à quelle heure ce que vous voyez a été lu.
Activer le journal, déplacer le seuil et choisir où il écrit — là où le serveur permet de le faire d'ici.
Où le trouver : Requêtes lentes › Réglages
Les cartes du haut disent ce que le serveur répond à cet instant : s'il enregistre, avec quel seuil et où il écrit. En dessous apparaît l'une de deux choses : les contrôles pour le changer, ou une note qui dit où cela se change vraiment. Jamais des contrôles grisés, qui ne distinguent pas « pas ici » de « c'est cassé ».
Le seuil se tape ou se déplace avec les boutons moins et plus, et s'envoie avec Appliquer. Un seuil négatif est refusé ici même : aucune requête ne dure moins que rien, et le serveur le ramènerait à zéro sans rien dire — toute requête deviendrait alors lente et le journal grossirait sans frein.
MySQLMariaDBAurora
Le seuil est en secondes (long_query_time), et la destination se choisit entre la table mysql.slow_log, le fichier du serveur, ou les deux (log_output). Seul ce qui va dans la table est lisible depuis un client.
Deux choses qui surprennent : un changement fait d'ici ne survit pas à un redémarrage du serveur —pour cela il va dans son fichier de configuration— et n'atteint pas les connexions déjà ouvertes, celle de Calíope comprise : les sessions vivantes continuent de mesurer avec l'ancienne valeur jusqu'à leur recyclage.
Aurora
Sur Amazon Aurora ces réglages ne vivent pas dans le serveur mais dans le groupe de paramètres du cluster, donc vous verrez ici la note au lieu des contrôles. Vider le journal reste possible : le serveur le fait lui-même avec mysql.rds_rotate_slow_log.
PostgreSQL
Le seuil est en millisecondes (log_min_duration_statement), et un changement fait d'ici persiste : il s'écrit avec ALTER SYSTEM et le serveur recharge sa configuration.
Mais certaines origines l'emportent sans le dire. Si la valeur vient de la ligne de commande avec laquelle le serveur a démarré, ou d'un réglage propre à cette base, à ce rôle ou à cette session, l'écriture est acceptée, le fichier reçoit la nouvelle valeur et celle qui s'applique reste l'ancienne. C'est pourquoi la première variable de la liste du bas est l'origine du seuil : c'est elle qui dit où il faut le changer. Quand l'origine est de celles-là, vous verrez ici la note et non les contrôles.
La destination ne se choisit pas : PostgreSQL écrit toujours dans son propre journal, un fichier de la machine du serveur.
SQL Server
Dans SQL Server, il n'y a rien à régler : le cache des plans compte toujours, et il n'a ni seuil ni destination à choisir. C'est pourquoi la carte du seuil n'apparaît pas et vous verrez la note au lieu des contrôles. Ce qui est lu vit dans la mémoire du serveur : il se perd au redémarrage, et un plan qui quitte le cache emporte ses chiffres. Avec optimize for ad hoc workloads activé, une requête isolée n'entre qu'à sa deuxième exécution.
La liste de la fin regroupe les variables que ce serveur publie autour du journal, avec les noms qu'il leur donne. Elles sont informatives : elles changent là où leurs réglages se changent, pas ici.
Mots-clés : seuil, long_query_time, log_min_duration_statement, log_output, ALTER SYSTEM, parameter group
Il groupe par forme de requête, pas par exécution : il dit ce qui coûte sa journée au serveur.
Où le trouver : Requêtes lentes › Par instruction
Par instruction ne liste pas des exécutions : il groupe par la forme de la requête. Les littéraux sont remplacés par un marqueur, donc mille requêtes qui ne diffèrent que par la valeur cherchée font une ligne, avec ses appels, son temps total et son temps moyen. C'est la réponse à « qu'est-ce qui coûte sa journée à ce serveur ? », qui n'est presque jamais la requête la plus lente.
MySQLMariaDBAurora
C'est performance_schema qui le publie, et les littéraux sortent en ?. Sur MariaDB il naît désactivé : si cette vue dit qu'il n'y a pas de résumé, ce n'est pas qu'il n'y a pas de requêtes lentes — c'est que performance_schema est à OFF. Il ne s'active pas serveur en marche : cela va dans son fichier de configuration et il faut le redémarrer.
PostgreSQL
C'est pg_stat_statements qui le publie, et les littéraux sortent en $1. Il faut deux choses, toutes deux hors de l'app : la bibliothèque préchargée dans shared_preload_libraries, ce qui exige de redémarrer le serveur, et l'extension créée dans cette base, une fois par base :
CREATE EXTENSION pg_stat_statements;
Si l'extension est créée et la bibliothèque non chargée, la vue existe et ne collecte rien. Ce sont deux états distincts, et l'outil dit lequel.
SQL Server
Il vient de sys.dm_exec_query_stats, regroupé par query_hash, qui est la forme de la requête. Le texte affiché est celui d'une de ses exécutions, avec ses littéraux, pas une forme avec des marqueurs. Le lire demande l'autorisation VIEW SERVER STATE ; sans elle, la vue affiche l'erreur du serveur. Réinitialiser les statistiques n'apparaît pas : vider ce résumé serait DBCC FREEPROCCACHE, qui jette les plans de tout le serveur, et cela ne se fait pas d'ici.
Le résumé est celui du serveur entier, donc les privilèges comptent : là où votre utilisateur ne peut pas lire les requêtes des autres, le serveur renvoie la ligne sans le texte. Quand cela arrive, c'est dit ici avec le nombre —combien de formes de plus vous ne pouvez pas lire—, ce qui est très différent d'une liste vide.
Réinitialiser les statistiques remet ces compteurs à zéro pour tout le serveur, pas pour votre session : cela touche quiconque regarde le même résumé, et c'est irréversible.
Mots-clés : résumé, par instruction, performance_schema, pg_stat_statements, normalisée, privilèges
Le journal dit quelle requête est lente ; pour savoir pourquoi, on l'envoie à l'éditeur et on la profile là-bas.
Où le trouver : Requêtes lentes › clic droit › Envoyer à l'éditeur
Le journal dit quelle requête est lente. Pour savoir pourquoi, la requête doit être réexécutée, et c'est votre décision — pas celle d'une liste qui s'actualise toutes les dix secondes.
Depuis une ligne, par son menu contextuel ou en ouvrant sa fiche, Envoyer à l'éditeur dépose la requête dans l'Éditeur SQL, dans un onglet, sans l'exécuter. Là, vous décidez quoi en faire.
MySQLMariaDBAurora
L'exécuter et appuyer sur Profiler pour voir la répartition par phase, ou demander son plan au moteur avec EXPLAIN visuel.
PostgreSQLSQL Server
Demander son plan au moteur avec EXPLAIN visuel. Profiler, la répartition par phase, appartient à la famille MySQL et n'apparaît pas ici dans l'éditeur.
Avant d'exécuter ce qu'apporte une ligne, rappelez-vous que le texte est celui qu'a exécuté un autre client, avec ses paramètres et contre la base qu'il avait ouverte.
MySQLMariaDBAuroraPostgreSQL
Et du résumé par instruction, ce qui arrive est la forme normalisée, avec des marqueurs au lieu des valeurs : il faut mettre vos propres valeurs avant de l'exécuter.
SQL Server
Du résumé par instruction, ce qui arrive est le texte d'une de ses exécutions, avec les valeurs de celle-ci : la ligne représente toutes celles de la même forme.
Mots-clés : profiler, profileur, éditeur, explain, plan, envoyer à l'éditeur