Le diagnostic Cold Case

Le contexte

Une banque française, application de gestion de portefeuille critique, quelques milliers d’utilisateurs simultanés. Tout marche… sauf quand ça ne marche pas.

Aléatoirement, certaines requêtes prenaient 5-10 secondes pour répondre. Les autres ? Instant, 50ms top. Aucune pattern discernable.

Les logs disaient “tout est OK”. Les métriques Prometheus ? Rien d’anormal. Les experts bankables internes ? “C’est peut-être le réseau, on sait pas.”

C’est le type de problème qui rend fou : invisible en monitoring, brutal en prod, invisible en dev (reproduction impossible en local).

L’analyse Leanovia

Trois experts, trois jours :

Jour 1 : Deep profiling JVM avec JProfiler et YourKit pendant une journée de production complète. On enregistre chaque pause GC, chaque allocation mémoire, chaque context switch.

Jour 2 : Analyse des traces. On voit des pauses GC sporadiques de 1-2 secondes. Logiquement pas possible sur une GC bien configurée. Ça vient d’où ?

En creusant : une page entière de GC pause logs, mais c’était du “Old GC” non-prévu. Quelque chose était en train de remplir le heap full generation de manière sporadique.

Jour 3 : Couplé à une analyse database. Les requêtes SQL prenaient à elles seules 3-5 secondes parfois. Après inspection : deadlock et lock escalation sur la pool de connexions SQL.

Le coupable: Une race condition subtile combinée à une mauvaise gestion de connexions sous charge. Quand vous lancez 50 requêtes en parallèle qui demandent toutes une connexion à la même base—mais la pool avait qu’8 connexions—ça crée du queueing et du lock thrashing.

Le GC pause ? Un symptôme. L’équipe avait augmenté la heap JVM pour “compenser”, ce qui avait allongé les pauses GC.

La solution

Augmenter pool de connexions de 8 à 25 (mais intelligent : avec une queue configurable et timeouts agressifs)
GC tuning : Réduire la heap à la taille réelle (elle était surdimensionnée), utiliser G1GC avec des pauses cibles de 100ms max
Code audit : Identifier les requêtes N+1 qui s’additionaient avec la charge

L’impact

Latence p95 divisée par 20 (50ms stable, zéro pics au-delà de 200ms)
Zéro timeout applicatif (avant : quelques par jour)
Prédictibilité : L’app répond maintenant en temps prévisible peu importe la charge

Leçon

Aucun monitoring classique ne l’aurait détecté. Vous auriez pu ajouter 10 serveurs et le problème serait resté. L’infra n’était pas le problème. Le code l’était.

C’est ça, le deep profiling.