IBAnalyst : Comment obtenir les statistiques d'une base de données InterBase/Firebird de la bonne manière

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

Résumé

Ce document est consacré aux astuces et conseils pour collecter et analyser les statistiques des bases de données InterBase/Firebird, avec ou sans IBAnalyst.

Le bon moment, au bon endroit

Cela peut sembler étrange, mais le simple fait de prendre des statistiques via gstat ou l’API Services ne suffit pas. Les statistiques doivent être prises au bon moment pour montrer comment les applications affectent les données et les transactions dans la base de données. Le pire moment pour prendre des statistiques est

• Juste après une restauration
• Après une sauvegarde (gbak -b db.gdb) sans le commutateur -g
• Après un balayage manuel (gfix -sweep)

Il est également vrai que pendant le travail, il peut y avoir des moments où la base de données est dans un état correct, par exemple, lorsque les applications génèrent moins de charge sur la base de données que d’habitude (lancement des utilisateurs, pause déjeuner ou selon les horaires spécifiques des processus métier).

Comment détecter quand quelque chose ne va pas dans la base de données ?

Oui, vos applications peuvent être conçues si parfaitement qu’elles fonctionneront toujours correctement avec les transactions et les données, sans créer d’intervalles de balayage, de nombreuses transactions actives, de longues exécutions de snapshots, etc. En général, cela n’arrive pas. Du moins parce que certains développeurs testent leurs applications avec 2 à 3 utilisateurs simultanés au maximum. Ainsi, lorsqu’ils déploient leurs applications pour 15 utilisateurs simultanés ou plus, la base de données peut se comporter de manière imprévisible. Bien sûr, le mode multi-utilisateur peut fonctionner correctement, car la plupart des conflits multi-utilisateurs peuvent être testés avec 2 à 3 applications exécutées en parallèle. Mais ensuite, lorsque davantage d’applications simultanées s’exécutent, des problèmes de collecte des déchets peuvent survenir (au minimum). Et cela peut être détecté si vous prenez des statistiques aux bons moments.

Si vous ne rencontrez pas de problèmes de performance périodiques

Cela peut arriver lorsque vos applications sont correctement conçues, que la charge sur la base de données est faible, ou que votre matériel est moderne et très puissant (suffisant pour gérer le nombre actuel d’utilisateurs et les données).

Les informations les plus précieuses sont la charge des transactions et l’accumulation des versions. Cela ne peut être vu que si vous configurez une sauvegarde régulière des statistiques.

InterBase ne dispose pas de planificateur de tâches interne, vous êtes donc libre d’utiliser n’importe quel planificateur externe, comme le Planificateur de tâches standard (Windows) ou cron (Unix).

La meilleure configuration est de prendre des statistiques de transactions toutes les heures. Cela peut être fait en exécutant

gstat -h db.gdb >db_stat_.txt

où

db.gdb est le nom de votre base de données,

db_stat_.txt est le fichier texte où les statistiques seront sauvegardées,

- la date et l’heure actuelles auxquelles les statistiques ont été prises.

Si vous rencontrez des problèmes de performance périodiques

Ces problèmes sont généralement causés par l’exécution du balayage automatique. Vous devez d’abord déterminer la période entre ces baisses de performance. Ensuite, divisez cet intervalle au minimum par 4 (8, 16, etc.). Les systèmes d’information actuels ont beaucoup d’utilisateurs simultanés, et la plupart des problèmes de performance avec un serveur et une base de données non configurés se produisent 2 ou 3 fois par jour. Par exemple, si les baisses de performance se produisent toutes les 3 heures, vous devez prendre

gstat -h db.gdb

des statistiques toutes les 30 à 45 minutes, et

gstat -a -r db.gdb -user SYSDBA -pass masterkey

toutes les 1 à 1,5 heures.

Le mieux est de prendre les statistiques gstat -a -r juste avant la baisse de performance à venir. Cela montrera où se trouve le véritable garbage et combien de versions d’enregistrements obsolètes se sont accumulées.

Que faire avec ces statistiques

Si votre application utilise explicitement les transactions et les utilise bien, c’est-à-dire que vous savez ce qu’est read_committed et quand l’utiliser, que vos transactions snapshot ne durent pas plus longtemps que nécessaire, et que les transactions restent actives pendant une durée minimale, vous pouvez ajuster l’intervalle de balayage ou le désactiver, puis vous préoccuper uniquement du nombre de mises à jour effectuées par les applications et des tables qui doivent être moins mises à jour ou surveillées.

Que cela signifie-t-il, demanderez-vous ? Nous allons donner l’exemple d’un système où des problèmes de performance se produisaient chaque matin pendant 20 à 30 minutes. C’était très suffisant pour les applications “du matin” et ne pouvait pas durer plus longtemps.

L’administrateur de la base de données a posé les bonnes questions, et voici le tableau :

Le travail quotidien était divisé en sections - les analystes travaillaient le matin, puis les données étaient insérées et modifiées par les opérateurs habituels, et à la fin de la journée, des procédures spéciales commençaient à collecter des données qui seraient utilisées pour l’analyse le lendemain (au moins).

Le dernier travail sur la base de données en fin de journée consistait en de nombreuses mises à jour, et des mises à jour des tables que les analystes utilisaient le matin. Il y avait donc beaucoup de versions de garbage, qui commençaient à être collectées par l’application s’exécutant le matin.

Et la réponse à ce problème a été trouvée simplement - exécuter gfix -sweep à la fin de la journée.

Le balayage lit toutes les tables de la base de données et tente de collecter toutes les versions de garbage pour les transactions validées et annulées. Après le balayage, la base de données est devenue propre presque comme après une restauration.

Et le “problème du matin” a disparu.

Vous devez donc considérer les statistiques avec de nombreux autres facteurs :

1. combien d’utilisateurs simultanés (en moyenne) travaillent pendant la journée

2. quelle est la durée de la journée de travail (8, 12, 16, 24 heures)

3. quel type d’applications s’exécute à différents moments de la journée, et comment elles affectent les données utilisées par d’autres applications, s’exécutant en même temps ou ensuite. C’est-à-dire que vous devez comprendre les processus métier qui se déroulent pendant toute la journée et toute la semaine.

Quand l’administrateur de base de données ne peut rien faire

Il est triste de dire que ces situations se produisent. Et encore un exemple :

Un système installé pour environ 15 utilisateurs. Périodiquement, les performances sont si mauvaises que l’administrateur doit redémarrer le serveur. Après le redémarrage du serveur, tout fonctionne bien pendant un certain temps, puis les performances se dégradent à nouveau. Les statistiques ont montré que le nombre moyen de transactions quotidiennes est d’environ 75 000, et qu’il y a des transactions actives qui s’exécutent depuis le début de la journée jusqu’au moment où les performances se dégradent.

Malheureusement, les applications ont été écrites avec BDE et sans utiliser de transactions du tout ; c’est-à-dire que toute la gestion des transactions était automatique et utilisée par BDE lui-même. Cela a provoqué que certaines transactions restent actives pendant une longue période, et le garbage (versions d’enregistrements) s’est accumulé jusqu’à ce que l’administrateur redémarre le serveur. Après le redémarrage, le balayage automatique s’est exécuté et le garbage a été collecté (éliminé).

Tout cela a été causé par les applications, car elles n’ont été testées qu’avec 2 à 3 utilisateurs simultanés, et lorsqu’elles sont passées à environ 15, les applications ont commencé à générer une charge très élevée.

Il faut dire que dans cette configuration, 70 % des utilisateurs ne faisaient que lire des données, et les autres 30 % inséraient et mettaient à jour certaines (!) données.

Dans cette situation, la seule chose qui peut améliorer les performances est de reconcevoir complètement les applications.

Vous avez encore des questions ? Contactez-nous à [email protected]