IBAnalyst : ce que vous pouvez voir dans la vue Résumé

Dmitry Kuzmenko, dernière mise à jour 31-03-2014

Résumé

Ce document est consacré à l’explication des informations présentes sur la page « Vue résumé » d’IBAnalyst, et à la manière d’interpréter ces informations pour vos propres statistiques de base de données. Nous avons également ajouté plusieurs exemples de statistiques au package d’installation pour faciliter l’étude de tous les détails des statistiques InterBase. Ils se trouvent dans le répertoire Examples de l’installation d’IBAnalyst.

Si vous ne savez pas ce qu’est la transaction la plus ancienne, le snapshot le plus ancien, la transaction active et la suivante, veuillez lire avant l’article de Craig Stunz « Understanding Transactions Lifetime » :

http://blogs.teamb.com/craigstuntz/articles/UnderstandingTransactionLifetimes.aspx

Numéros de transactions

Si vous avez lu l’article Understanding Transaction Lifetimes, vous avez peut-être encore des questions sur les numéros OIT/OST/OAT. Voici une brève description :


Numéro	Se maintient, …	Avance, …
Transaction la plus ancienne	lorsque la transaction avec ce numéro a été annulée (rollback), et qu’il y avait beaucoup de modifications de données, ou lorsque la connexion client a été perdue	lorsque le balayage (sweep) automatique ou manuel réussit.
Snapshot le plus ancien	lorsqu’un snapshot (ou lecture validée en écriture avant IB 7.1) est actif pendant une longue période (il a mémorisé le snapshot actif le plus ancien comme son OST local)	lorsqu’une nouvelle transaction démarre, si la transaction détenant l’OST est terminée
Transaction active la plus ancienne	lorsque la transaction avec ce numéro est active pendant une longue période	lorsqu’une nouvelle transaction démarre, si la transaction détenant l’OAT est terminée
Suivante	jamais	lorsqu’une nouvelle transaction démarre

note : La transaction la plus ancienne ici est la même que la Transaction la Plus Ancienne Intéressante (OIT), mentionnée dans de nombreux autres articles.

Statistiques fines avec les paramètres standard

Commençons IBAnalyst et ouvrons (avec le menu Statistics/Load statistics from file) le fichier !allok.txt.

IBAnalyst ne signale pas seulement la date de création de la base de données, mais reconnaît également la date/heure actuelle du serveur si les statistiques ont été prises via l’API Services, ou la date/heure du fichier s’il s’agit d’un fichier de statistiques chargé.

C’est pourquoi nous suggérons de ne pas modifier les fichiers de statistiques, car dans ce cas, IBAnalyst calculera incorrectement le nombre moyen de transactions par jour. La ligne Transactions par jour ici montre environ ~12500 transactions par jour et que cette base de données « vit » depuis sa création ou sa restauration depuis 8 jours.

Les transactions la plus ancienne, snapshot le plus ancien, active la plus ancienne et suivante sont ici dans un état parfait ; nous vous souhaitons d’avoir toujours des statistiques qui ressemblent à cela.

De nombreuses transactions actives

Ensuite, ouvrons le fichier !lotofactive.txt (vous pouvez revenir à l’image !allok à tout moment pour comparer les exemples suivants avec elle).

Ici, la ligne Transactions actives est marquée en rouge, car il y a une grande différence entre la transaction active la plus ancienne et la transaction suivante. Cela signifie qu’une transaction au moment où les statistiques ont été prises est encore active, et qu’après son démarrage, 55 000 transactions ont déjà démarré (elles peuvent être dans n’importe quel état - actives, validées, annulées). Étant donné que le nombre moyen de transactions par jour est d’environ ~12500, IBAnalyst vous montre un avertissement indiquant qu’une transaction vit encore depuis 4,4 jours. Cela peut arriver lorsque :

une application est toujours en cours d’exécution et a au moins une transaction ouverte - certains utilisateurs laissent peut-être l’application fonctionner pendant une longue période
l’application fonctionne pendant une longue période et perd les handles de transactions - c’est-à-dire que votre code (ou les composants/bibliothèques que vous utilisez) démarre dynamiquement des transactions et, dans certaines circonstances, « oublie » de les terminer par un rollback ou un commit.
votre application n’utilise pas de transactions explicites (BDE), laissant la gestion des transactions aux composants utilisés. En conséquence, la durée de vie des transactions n’est pas contrôlée par l’application, et vous pouvez être sûr que la plupart des transactions Next-OAT sont réellement actives.
votre application utilise un pilote ou des composants qui permettent une « transaction par défaut ». Si votre code ne contrôle pas cette transaction, elle peut s’exécuter très longtemps.

Malheureusement, les statistiques ne montrent pas le nombre réel de transactions actuellement actives. Cela ne peut être visualisé que dans InterBase 7.x en utilisant IBConsole, IB Performance Monitor ou via une requête directe à la table système temporaire tmp$transactions. Dans Firebird 1.5, vous pouvez appeler isc_database_info avec le paramètre isc_info_active_transactions.

Balayage (Sweep)

Ouvrons maintenant !needsweep.txt.

Le balayage est un processus de maintenance interne à InterBase. Le balayage parcourt tous les enregistrements de la base de données et tente de nettoyer toutes les versions de garbage, puis essaie de faire avancer le numéro de la transaction la plus ancienne. Dans une base de données nouvellement créée, l’intervalle de balayage par défaut est de 20000. Lorsque la différence entre les transactions (voir le tableau ci-dessous) devient supérieure à l’intervalle de balayage, le balayage s’exécutera automatiquement. Ainsi, vous pouvez observer une dégradation périodique des performances sur votre base de données. Par exemple, vos applications fonctionnent correctement le lundi et le mardi, mais le mercredi, les utilisateurs signalent des problèmes de performance pendant quelques heures, puis les performances redeviennent normales.

Si vous observez un comportement similaire, il s’agit d’un balayage automatique.


Version du serveur	Quand le balayage s’exécute
InterBase 7.x	(Active la plus ancienne - Plus ancienne) > Intervalle de balayage
InterBase 4.x, 5.x, 6.x, Firebird antérieur à 1.5.2, Yaffil	(Snapshot le plus ancien - Plus ancienne) > Intervalle de balayage

Tableau 1. Conditions d’exécution du balayage automatique

note : IBAnalyst affiche automatiquement les informations correctes sur l’écart de balayage pour toutes les versions. IBAnalyst ne peut détecter la différence entre les implémentations de serveurs que par l’ODS, par exemple, InterBase 7.x a ODS 11.x, les autres serveurs modernes ont ODS 10.x. Si vous travaillez uniquement avec des bases de données InterBase 7.x (ODS 11), vous pouvez activer l’option appropriée dans la boîte de dialogue Options.

Lorsque votre base de données a un intervalle de balayage <> 0, IBAnalyst marque essentiellement cette ligne en jaune (vous avertissant qu’un balayage automatique peut démarrer à tout moment imprévisible). Généralement, 60 % de toutes les applications ont des problèmes avec le balayage automatique. Le moyen le plus simple d’éviter ce problème est de définir l’intervalle de balayage sur 0, ce qui désactive le balayage automatique. Mais si une application effectue beaucoup de modifications puis les annule, la transaction la plus ancienne se figera et n’avancera pas jusqu’à ce qu’un balayage soit exécuté. Étant donné que l’état effectif des transactions est calculé de la transaction la plus ancienne à la transaction suivante, cette distance augmentera et les performances chuteront. Pour éviter cela, vous devez exécuter le balayage manuellement (gfix -sweep). Sur cette image, vous pouvez voir le comportement lorsque l’intervalle de balayage est 0 et qu’une grande transaction a été annulée :

Ici, la valeur de l’écart de balayage montre qu’une grande transaction (ayant effectué beaucoup de modifications) a été annulée il y a environ 4,5 jours. Nous vous recommandons d’exécuter le balayage manuellement chaque jour.

Bien sûr, pour ces 60 % d’applications mentionnées, il est peut-être préférable de définir l’intervalle de balayage supérieur ou inférieur à 20000, mais cela dépend de nombreux facteurs (le nombre de transactions quotidiennes en est un, par exemple) et ne peut être compris que de manière expérimentale. Donc, si vous définissez l’intervalle de balayage sur 0, vous pouvez être sûr que le balayage ne s’exécutera pas automatiquement à un moment imprévisible.

La même image peut être observée pour le fichier !rollback.txt.

note : Si le balayage s’exécute automatiquement, pour une grande base de données ou une base de données avec beaucoup de versions d’enregistrements garbage, les transactions Snapshot, Active et Suivante peuvent avancer pendant que le balayage travaille, et le balayage peut redémarrer au démarrage de la transaction la plus proche.

Quand le balayage ne peut pas faire son travail

Il existe de nombreux cas où le balayage ne peut pas faire avancer la transaction la plus ancienne. Bien sûr, le balayage essaie d’abord de faire son travail, c’est-à-dire vérifier tous les enregistrements de la base de données et collecter les versions d’enregistrements inutiles. Mais il s’exécutera encore et encore sans succès si

il y a eu un problème lors de l’exécution du balayage : le serveur a été arrêté pendant le balayage, ou il y a eu une erreur lors du nettoyage des versions d’enregistrements garbage. De plus, vous pouvez voir cette image lorsque :

les statistiques ont été prises pendant que le balayage travaillait
le balayage s’exécute et essaie de collecter le garbage pour une table qui est constamment mise à jour. Cela peut durer jusqu’à la fin des mises à jour.
le balayage est bloqué sur des verrous de pages, car de nombreux utilisateurs travaillent avec les données.

En général, le balayage n’a pas de chances de se terminer pendant une charge élevée de la base de données. Habituellement, lorsque les performances se dégradent au point de rendre le travail normal impossible, l’administrateur de base de données redémarre le serveur, et le balayage s’exécute à la première connexion utilisateur. Comme il y aura un certain temps avant que les autres utilisateurs se connectent, le balayage aura le temps de terminer son travail.

Étant donné qu’InterBase 7.1/7.5 calcule l’écart de balayage différemment des versions précédentes, l’autre situation où le balayage ne peut pas faire son travail est lorsqu’une application a une transaction snapshot de longue durée :

Voici deux avertissements - un (jaune) concernant un snapshot de longue durée, et un autre (rouge) concernant l’intervalle de balayage et l’écart de balayage.

Snapshot de longue durée

L’image précédente indique un snapshot de longue durée dans InterBase 7.1/7.5. Si l’intervalle de balayage avait été défini sur 0, il n’y aurait pas d’avertissements rouges, seulement des jaunes. Une image similaire indiquera une transaction snapshot de longue durée dans les autres versions d’InterBase, Firebird et Yaffil :

Comme vous le voyez ici, l’écart de balayage est calculé par la différence entre le snapshot le plus ancien et la transaction la plus ancienne (pour ODS 10, versions pré-IB7.x). Il n’y a donc pas d’avertissement de balayage (sauf l’intervalle de balayage par défaut).

Mais ce ne sont pas seulement les transactions snapshot qui affectent l’état des transactions de cette manière. Toutes les versions d’InterBase, Firebird et Yaffil, à l’exception d’InterBase 7.1/7.5, ont le comportement suivant, que nous avons nommé « artefact de lecture validée ».

Snapshots à nouveau et quand ReadCommitted fige le snapshot le plus ancien

Ouvrez !snapshot2.txt. :

Notez que la transaction la plus ancienne est supérieure au snapshot le plus ancien. Et l’écart de balayage a une valeur négative. Cela peut arriver dans deux cas. Le premier cas est lorsqu’il y a des transactions snapshot qui démarrent et se valident les unes après les autres. C’est-à-dire que cette image peut se produire avec des snapshots tout comme l’image précédente. Le cas suivant se produit uniquement sur les serveurs autres que IB 7.1/7.5 avec des transactions ReadCommitted (ou une combinaison de transactions ReadCommitted et Snapshot). Elles peuvent verrouiller le numéro du snapshot le plus ancien de la même manière que les transactions Snapshot. L’état actuel des transactions peut être émulé avec la séquence suivante :

démarrer la transaction 1, snapshot ou read_committed
démarrer/valider quelques transactions read_committed
démarrer la transaction 2, snapshot ou read_committed
démarrer/valider quelques transactions read_committed
valider la transaction 1

(bien sûr, nous parlons ici de transactions read_committed en écriture, pas en lecture seule).

À ce stade, la transaction 2 actuellement active (snapshot ou read committed), démarrée après le snapshot 1 (étape 3), maintiendra le numéro de snapshots comme snapshot le plus ancien (si vous travaillez avec IB 7.1/7.5, cela ne peut se produire que pour des transactions snapshot concurrentes. read_committed ou read_committed+snapshot ne produira pas cet effet). Comme il n’y a pas eu de gros rollbacks, la transaction la plus ancienne avance et devient supérieure au snapshot le plus ancien.

Maintenant, si vous avez une transaction read committed de longue durée, vous verrez une image comme celle-ci. Malheureusement, vous ne pouvez rien faire ici avec vos applications (sauf ajouter le paramètre « read » pour les transactions en lecture seule). Et bien sûr, le balayage ne s’exécutera pas automatiquement (s’il est défini <> 0) dans ce cas.

note : ce comportement sera corrigé dans Firebird 2.0

Vues absolue et relative

Par défaut, IBAnalyst remplit les lignes de transactions en fonction du pourcentage de leur valeur absolue. C’est-à-dire que 100 % va de 0 à la transaction suivante. Parfois, lorsque la base de données fonctionne depuis longtemps, vous pouvez voir les informations de transaction comme suit :

Bien qu’il y ait beaucoup de transactions, la différence entre le snapshot, l’active et la plus ancienne semble très petite (proche de 98 %). Pour clarifier la situation, ouvrez la boîte de dialogue Options, onglet Transactions, et cochez l’option « Barres % relatives (depuis la plus ancienne) » (vous ne pouvez pas cocher cette case si vous utilisez l’ancienne vue, sans barres graphiques). Après avoir appuyé sur le bouton OK, la vue des transactions changera pour

Vous voyez maintenant la différence des transactions en vue relative (100 % correspond à la transaction la plus ancienne (ou snapshot) jusqu’à la suivante, et non à partir de 0). Il est plus facile de comprendre la situation actuelle et de consulter les avertissements (le cas échéant).

Cette vue restera active jusqu’à ce que vous la désactiviez via la boîte de dialogue Options. Vous pouvez savoir quelle vue vous consultez grâce à la ligne Oldest Transaction ou Oldest snapshot - en vue relative, l’une de ces lignes n’est jamais remplie en vert. En vue absolue, elle est toujours remplie (partiellement, bien sûr).

Encore des questions ? Contactez-nous à [email protected]