Cette page décrit Calíope 1.5, la version que nous construisons en ce moment. La 1.4 est terminée et en cours d'examen par Apple, et la boutique propose aujourd'hui la 1.3 sur le Mac et la 1.2 sur iPad. 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.
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.
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.
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 : l'exécuter et appuyer sur Profiler pour voir la répartition par phase, ou demander son plan au moteur avec EXPLAIN visuel.
Deux précautions avant d'exécuter ce qu'apporte une ligne. Le texte est celui qu'a exécuté un autre client, avec ses paramètres et contre la base qu'il avait ouverte. 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.
Mots-clés : profiler, profileur, éditeur, explain, plan, envoyer à l'éditeur