Analyser le seuil du journal.

un fichier est changé, l’enregistrement du journal de changement de fichier est écrit immédiatement ; de leur côté, les enregistrements physiques et logiques de la base de données changée restent en mémoire principale jusqu’à ce qu’ils soient écrits plus tard. Si la journalisation des chemins d’accès est active (journalisation explicite), ou si SMAPP a décidé de journaliser les index (journalisation implicite), il y a une entrée de journal pour le changement du fichier physique et une entrée de journal pour chaque changement de fichier d’index associé. Un certain temps après l’écriture des entrées du journal, le système écrit, ou purge, les enregistrements des fichiers physiques et logiques accumulés sur disque. C’est le ratio de reprise du journal qui décide du moment où ces écritures ont lieu.

J’ai constaté une dégradation du débit pouvant atteindre 60 ou 70 %, causée par la purge des enregistrements de la base de données. La dégradation se manifeste généralement quand un très grand nombre de requêtes d’écriture sont émises dans un court laps de temps. Si l’on n’intervient pas, cette situation peut excéder le seuil du cache d’écriture sur disque et entraîner des temps de service d’I/O disque très élevés du fait que le sous-système disque vide le cache sur disque.

De nombreux facteurs contribuent aux hauts niveaux de dégradation. L’un des facteurs est l’activité de changement de fichiers avec une valeur de seuil proche de la valeur par défaut de reprise du journal de 50 000, qui aboutit à une fréquente haute activité d’écriture sur fichier. Les jobs qui s’exécutent pendant longtemps dans un vaste pool de stockage sont plus susceptibles d’atteindre le seuil que s’ils s’exécutent dans un pool restreint plus petit. Dans ce dernier cas, les jobs n’accumulent pas en principe autant de pages changées dans un petit pool, parce que les fonctions d’allocation de la mémoire principale volent les pages de fichiers changées pour satisfaire les défauts de page ou la demande de mémoire principale.

Company aBc évite les ralentissements pendant les périodes de pointe en anticipant le moment où se produira le pic de la charge de travail et sa durée. Elle établit un seuil très haut pour éviter l’activité d’écriture sur le fichier de seuil de reprise du journal avant le pic de la demande. Ce faisant, le seuil ne sera pas atteint pendant la période de pointe. Une fois le pic passé, elle ramène le seuil à sa valeur normale. Un autre moyen d’éviter le problème consiste à désactiver la journalisation. On ne l’applique pas souvent parce que la journalisation fonctionne bien et a peu ou pas d’influence sur la performance du système, particulièrement quand on utilise le journal à distance et le cache de journal.