Le contexte

La version mini 6 des SIRC s’avéra rapidement trop limitée en matière de puissance CPU (Même la charge de base était bien trop élevée) et en capacité mémoire vive. L’annonce de l’arrivée sur le marché du DPS6 qui permettait de desserrer une partie des contraintes mémoire et qui offrait une puissance de calcul deux fois supérieure, tout en assurant une compatibilité logicielle préservant les investissements logiciels a été vue comme providentielle.

La compatibilité ascendante

Nous n’insisterons pas ici sur la compatibilité ascendante qui nous joua quelques tours dont on ne citera ici que deux exemples :
• Le changement obligatoire du compilateur FORTRAN dont certaines options n’étaient pas identiques à celle du compilateur précédent notamment l’initialisation par défaut des variables,
• Le plafonnement de la taille de certains fichiers, qui ont amené des reprises assez profondes dans la surcouche spécifique du système de gestion des fichiers.

Le positif : le DPS 6 était bien deux fois plus rapide que le mini 6

Une fois ces difficultés surmontées, les premiers tests permirent de constater que les temps de réponse avaient globalement été divisés par deux, ce qui correspondait bien au rapport de puissance annoncé des machines.
Mais il fallut bien vite déchanter, lors de périodes de fortes charges (liées à l’exploitation du réseau électrique) un certain ralentissement apparaissait…
L’on vérifia les codes potentiellement incriminés, les verrouillages par sémaphore, les priorités relatives des tâches. Il fût bien découvert quelques bizarreries, mais pas en rapport avec le phénomène étudié.

L’effondrement des temps de réponse en cas de gros incidents réseau électrique

Et puis lors d’un incident de plus grande ampleur, les temps de réponse s’effondrèrent et l’application se trouva quasiment figé.
Après moult recherches infructueuses, il fût décidé, avec l’appui d’une prestation, de réaliser une simulation de l’application (système DPS6 et applicatif) à l’aide de files d’attente. Cette modélisation apparemment simpliste permit néanmoins d’appréhender les causes du problème…

Quelques explications…

Le choix pris dans la conception du Mini6 était que GCOS6 (l’OS) exécutait la tâche la plus prioritaire disponible.
Pour faciliter la lecture, on va considérer les tâches A, B, C, D…. par priorité décroissante.
La tâche A s’exécute jusqu’au premier appel disque pendant lequel elle se met en attente.
La tâche B prend le relais et s’exécute jusqu’au premier appel disque pendant lequel elle se met en attente.
La tâche C prend le relais et s’exécute jusqu’au premier appel disque pendant lequel elle se met en attente.
La tâche A dont l’appel disque a abouti, reprend la main et s’exécute jusqu’à l’appel disque suivant pendant lequel elle se met en attente.
Les tâches D et suivantes sont toujours en attente et ne seront activées que lorsque des tâches plus prioritaires A, B, C ne seront plus éligibles à l’exécution.

C’est ce qui se passait sur le mini 6.
Le DPS6 étant plus rapide au niveau CPU (mais pas au niveau disque), le phénomène suivant se passait :
La tâche A s’exécute jusqu’au premier appel disque pendant lequel elle se met en attente.
La tâche B prend le relais et s’exécute jusqu’au premier appel disque pendant lequel elle se met en attente.
La tâche C prend le relais et s’exécute jusqu’au premier appel disque pendant lequel elle se met en attente.
Le CPU étant plus rapide, l’appel disque n’est pas terminé, d’autres tâches sont prises en compte
La tâche D prend le relais et s’exécute jusqu’au premier appel disque pendant lequel elle se met en attente.
La tâche E prend le relais et s’exécute jusqu’au premier appel disque pendant lequel elle se met en attente.
La tâche F prend le relais et s’exécute jusqu’au premier appel disque pendant lequel elle se met en attente.
La tâche A dont l’appel disque a abouti, reprend la main et s’exécute jusqu’à l’appel disque suivant pendant lequel elle se met en attente. Mais dans la file d’attente du disque, qui est unique, beaucoup plus de demandes que dans le cas du mini 6 sont en attente. Le temps d’attente de la tâche A sur accès disque va donc être encore plus long, ce qui permettra à encore plus de tâches non prioritaires de s’exécuter et de mettre des appels disque en attente. D’où un effondrement du système amenant à des temps de réponse plus de dix fois plus longs que la normale. Le phénomène était accentué par le fait que les opérateurs, sous stress de leur situation incidentielle, et  ne voyant pas les images demandées s’afficher, cliquaient à nouveau ajoutant ainsi des lancements de tâches supplémentaires…

En conclusion

Une fois le phénomène compris, il a fallu revoir la gestion de l’accès au disque pour établir un priorisation, non native à l’accès au disque.
Le développement a été réussi et le SIRC a pu continuer sa longue vie…

Mais cet épisode nous a fait comprendre que :

• le fonctionnement équilibré de la première phase était quand même dû à une certaine part de hasard bienheureux et qu’il y avait peut-être (et même sûrement) d’autres phénomènes de natures similaires, qui étaient dormants et que de profondes modifications (comme un portage sous AIX, par exemple) pouvaient faire ressurgir.

• La mise en œuvre d’un système informatique complexe, quand bien même, il a fonctionné dans des conditions voisines (autre versions de l’OS, autre réseau électrique…), est souvent un challenge…

Images liées: