Saturation mémoire en boucle sur les tomcats 2532

Perturbations, ralentissement, et interruption de service.

Tant que le fichier sera problématique et que le code n’est pas fixé.

Alertes de supervision saturation mémoire tomcat

Causes immédiates : Saturation mémoire tomcat Messages HL7 PN13 malformés (Doublons d'identifiants de prescriptions) boucle suppression/recréation Le client crée ses flux lui-même. Le client n’a pas fait de qualif avant.

Comment l’incident a été résolu Redémarrages cycliques des tomcats jusqu'à l'arrêt du connecteur Arrêt du connecteur ARAGO par Laurence COLOMBIER Demande de correction à Diane Consult Le connecteur ne sera remis en prod qu'après correction et validation interop

Ce qui s'est bien passé : Analyse du hprof difficile et non automatisée Incident circonscrit à un seul client

Ralentissement des applications hébergées sur STDN

temps de réponse x5

Très régulier, chaque semaine https://app.notion.com/p/softwaymedical/2026-Post-Mortem-One-Manager-et-Infra-2dfe0ccaabcc818b9912c93cdf8aec49?p=36ce0ccaabcc803fbf53c69b38de41d7&pm=s

Alertes de supervision

Causes immédiates : Saturation réseau diverses. Atteinte de la limitation matérielle 15Gbps du pare feux Y a t’il eu des faits aggravants

Au bout d’un moment, le transfert se termine.

Ce qui s'est bien passé : Difficulté à identifier l’origine de la dégradation ou de l’augmentation de la bande passante. Difficulté à avoir des certitude sur l’état des firewall, leur capacité à traiter correctement les flux sans induire de la latence. Les lenteurs ont permis d’identifier des transferts énormes.

A la suite d’une mise à jour, le microservice vidal répond 10x moins vite

Les clients utilisant vidal rencontrent de fort ralentissements dans les prescriptions, jusqu’à estimer ne pas pouvoir passer la nuit comme ça et appeler l’astreinte infra vers 18h30 (4 clients différents 3444 3241 3528 3449)

Quelle est la récurrence du problème ? Pas de récurrence

Comment l’incident a t’il été détecté?

Causes immédiates : Quelle est la cause immédiate Passage de 8 à 3 PODs Quelles sont les causes racines qui ont amener à la cause immédiate ? Fait à 16h Changement (mise à jour) non publié dans le canal Teams “Changements Prod - Clients”

Comment l’incident a été résolu L’astreinte a remonté manuellement le nombre de POD à 8 pour revenir à la charge normale Nous avons modifié notre configuration pour que le nombre de POD reste à 8 lors de chaque nouvelle mise à jour Nous avons modifié notre documentation de déploiement en attendant la fin de nos travaux d’automatisation pour ajouter 2 points : publication d’un message dans le canal Teams + observation des dashboard après mise à jour en prod

Ce qui s'est bien passé : On a eu de la chance que les clients nous aient dirigé vers le médicament et Vidal Pas d’infos Correction simple et rapide en remontant à 8 pods manuellement dans OC