FBMonLogger fait désormais partie de HQbird Standard !

FBMonLogger est un outil permettant d’analyser les sorties des tables de monitoring dans Firebird et de détecter les problèmes liés aux requêtes SQL lentes, aux transactions mal conçues (transactions de longue durée, transactions avec un niveau d’isolation incorrect, etc.) et d’identifier les applications problématiques.

FBMonLogger peut se connecter à une base de données Firebird présentant des problèmes de performance et identifier la cause de la lenteur : s’agit-il d’une connexion utilisateur, d’une requête SQL lente ou d’une transaction de longue durée ?

FBMonLogger prend en charge Firebird 2.1, 2.5 et 3.0 - pour les versions plus anciennes de Firebird ou InterBase, veuillez utiliser FBScanner.

FBMonLogger peut vous montrer :

Les connexions les plus actives en termes d’opérations d’E/S, de lectures non indexées et indexées
Les instructions SQL les plus actives en termes d’opérations d’E/S, de lectures non indexées et indexées
Les transactions problématiques : transactions de longue durée, transactions avec un niveau d’isolation erroné, transactions en lecture/écriture, et les informations associées : quand elles ont démarré, quelles applications les ont lancées, depuis quelle adresse IP, etc.
Les connexions et instructions avec les actions de garbage collection les plus intensives
Le ratio lecture/écriture, le ratio INSERT/UPDATE/DELETE, et plus encore.

Après la connexion à la base de données où vous souhaitez détecter des problèmes de performance, plusieurs instantanés des tables de monitoring doivent être pris - cliquez sur « Get Snapshot » pour prendre un instantané.

Statistiques de performance agrégées pour les connexions utilisateurs

Sur le premier écran, nous pouvons voir les statistiques agrégées pour les connexions à la base de données et identifier les connexions présentant les plus gros problèmes :

Lectures séquentielles / Lectures indexées

« Lectures séquentielles / Lectures indexées » nous montre le ratio total entre les lectures séquentielles (non indexées) et les lectures indexées dans l’application. En général, le nombre de lectures non indexées devrait être faible, donc un pourcentage élevé de lectures séquentielles est un signe que de nombreuses requêtes SQL ont des plans d’exécution NATURAL, et elles pourraient être la cause d’un temps de réponse lent.

Cliquer sur un enregistrement dans « TOP connexions : lectures séquentielles/indexées » vous amènera à l’onglet « Connexions », où vous pourrez voir plus de détails sur la connexion, puis passer à l’onglet « Transactions » ou « Instructions », où vous verrez les transactions et instructions liées à la connexion sélectionnée (si la case « Link to selected attachment » est cochée, sinon toutes les transactions/instructions pour toutes les connexions seront affichées).

Détails d’écriture

« Détails d’écriture » vous donne un aperçu des opérations d’écriture : le ratio entre INSERT/UPDATE/DELETE parmi toutes les connexions à la base de données. Dans le tableau des principaux rédacteurs, vous pouvez voir les connexions avec le plus grand nombre d’opérations d’écriture. Cela est utile pour identifier les applications ou modules logiciels qui effectuent un nombre excessif de mises à jour ou de suppressions (qui sont les opérations les plus dangereuses en termes de garbage collection).

Détails du garbage collection

Que signifient les opérations de garbage collection ?

Purge - le moteur supprime les versions antérieures, seule la version principale reste dans la base de données.
Expunge - la version principale et toutes les versions antérieures ont été supprimées.
Backout - supprime uniquement la version principale (en raison d’un rollback).

En général, nous pouvons associer purge à l’opération UPDATE, expunge à DELETE, et backout au rollback d’un INSERT ou UPDATE. De nombreux backouts peuvent indiquer un problème de gestion des transactions dans l’application.

Utilisation de la mémoire

Le graphique « Utilisation de la mémoire » nous montre la mémoire totale utilisée par toutes les connexions actives actuellement, ainsi que le pic de mémoire allouée pour celles-ci dans le passé.

La liste des principales connexions par utilisation de la mémoire nous montre les plus gros consommateurs de mémoire parmi vos connexions. Cela est utile pour trouver les applications ou modules logiciels avec une utilisation excessive de la mémoire.

Statistiques de performance agrégées pour les instructions

Dans le deuxième onglet, vous pouvez trouver les statistiques de performance agrégées pour les instructions. Ces statistiques reflètent mieux la situation momentanée dans la base de données - puisque les tables de monitoring collectent des informations depuis le début de la vie de chaque objet, les instructions que vous voyez ici sont celles qui étaient en cours d’exécution au moment où l’instantané a été pris.

Lectures séquentielles / Lectures indexées

Dans cette liste, nous pouvons voir les principales instructions qui effectuent de nombreuses lectures séquentielles depuis la base de données. En général, ces instructions nécessitent un ajustement SQL - soit par l’optimisation des index, soit par la refonte de la requête SQL.

Pour optimiser la requête, vérifiez son plan d’exécution : il est généralement possible d’améliorer la vitesse de la requête en éliminant NATURAL des plans avec de nouveaux index ou une refonte de la requête. Cliquez sur l’instruction dans cette liste pour ouvrir l’onglet « Instructions », où vous trouverez plus de détails sur l’instruction sélectionnée et pourrez passer à la transaction ou la connexion associée.

Lectures/écritures de pages

Ces graphiques et listes montrent des informations succinctes sur les principales instructions qui effectuent de nombreuses lectures - cela signifie qu’elles consomment des E/S importantes et peuvent affecter les performances des autres requêtes. Les instructions SQL avec des valeurs de pointe doivent être soigneusement vérifiées pour des performances optimales.

Détails d’écriture pour les instructions

Sur ce graphique, vous pouvez voir ce que les instructions SQL d’écriture faisaient au moment où l’instantané des tables de monitoring a été pris, et identifier les UPDATE et DELETE qui ont effectué de nombreuses modifications dans la base de données.

Détails du garbage collection pour les instructions

Sur ce graphique, nous pouvons voir combien d’opérations de garbage collection ont été effectuées par les instructions en cours d’exécution au moment de l’instantané.

Utilisation de la mémoire pour les instructions

Contrairement aux statistiques agrégées d’utilisation de la mémoire pour les connexions, l’utilisation de la mémoire des instructions peut nous montrer la liste des instructions exactes qui consomment beaucoup de mémoire à ce moment.

Connexions

Le troisième onglet est « Connexions ». Vous pouvez ouvrir cet onglet directement en cliquant sur l’un des enregistrements dans « Statistiques de performance agrégées ».

Connexions affiche la liste des utilisateurs connectés à la base de données Firebird, avec de nombreux détails utiles : USER et ROLE de la connexion, heure de début et ID de la connexion, si le garbage collection est activé pour la connexion, le nom du processus distant qui a établi la connexion, et plusieurs compteurs de performance cumulés pour la connexion : nombre de lectures séquentielles [effectuées par la connexion depuis son démarrage], nombre de lectures indexées, nombre d’insertions, de mises à jour et de suppressions, ainsi que les backouts, purges et expunges d’enregistrements.

Par défaut, certaines colonnes de la connexion sont désactivées pour n’afficher que les informations les plus importantes.

Bien sûr, à chaque fois que vous cliquez sur une connexion, vous pouvez passer aux transactions qui s’y exécutent, puis aux instructions. Il y a une case à cocher dans le coin supérieur gauche des onglets Transactions et Instructions, qui contrôle ce comportement - lorsqu’elle est cochée, seules les transactions et instructions marquées par l’ID de connexion sélectionné seront affichées.

Transactions

L’onglet « Transactions » affiche les transactions actives au moment où l’instantané a été pris. Si la case « Link to selected attachment » est activée, seules les transactions pour la connexion sélectionnée seront affichées, sinon toutes les transactions sont affichées.

L’une des caractéristiques les plus importantes est la durée de vie des transactions : puisque Firebird est conçu pour fonctionner avec des transactions d’écriture courtes, il est important de les garder aussi courtes que possible. FBMonLogger met en évidence les transactions avec des modes d’isolation et des paramètres lecture-écriture qui maintiennent la transaction active la plus ancienne et provoquent ainsi une accumulation excessive de versions d’enregistrements non nettoyées. Si vous voyez une telle transaction et qu’elle a démarré il y a un certain temps, cela signifie qu’elle peut être responsable de versions d’enregistrements excessives.

Triez sur la colonne « started at » et recherchez les anciennes transactions marquées en rouge : toutes les transactions en écriture et les instantanés en lecture seule bloquent la transaction active la plus ancienne et provoquent une rétention excessive des versions d’enregistrements. Identifiez où ces transactions ont démarré (clic droit et sélectionnez « View parent attachment ») et corrigez votre code pour valider cette transaction plus tôt.

Instructions

L’onglet « Instructions » affiche les instructions actives au moment de l’instantané : si vous avez besoin de capturer toutes les instructions, FBPerfMon ou FBScanner doivent être utilisés (tous ces outils font partie d’IBSurgeon Optimization Pack).

Si « Link to selected attachment » est activé, seules les instructions pour la connexion spécifique seront affichées, sinon toutes les instructions actives sont dans la liste.

Certaines instructions n’ont pas d’ID de transaction associé (=0) : ces requêtes sont préparées mais non exécutées.