Chasse aux fuites mémoire : autopsie d’un OutOfMemoryError avec Datadog Continuous Profiler

Datadog, tout le monde connaît… ou presque.

Sur nos projets, il est devenu banal d’avoir des dashboards, des alertes et quelques traces applicatives. Mais beaucoup moins d’équipes ont l’occasion de manipuler une fonctionnalité aussi puissante que coûteuse : Datadog Continuous Profiler.

Lors d’une mission pour la SNCF, nous avons dû investiguer une anomalie de production présente depuis plusieurs mois : des redémarrages applicatifs réguliers provoqués par le cauchemar de nombreux développeurs Java :

java.lang.OutOfMemoryError: Java heap space

Entre fuite mémoire difficile à reproduire, logique Hibernate complexe et comportement qui ne se révélait qu’en production, identifier la root cause n’a été ni simple… ni rapide.

Dans cette session, je partagerai :

Comment nous avons utilisé Datadog Continuous Profiler pour analyser la consommation mémoire réelle

• Comment on a pu détecter une anomalie invisible des utilisateurs qui aurait pu provoquer une indisponibilité critique pendant les ponts de mai.
• Les corrélations entre profiling, métriques et traces applicatives
• Les pièges classiques des analyses mémoire Java modernes
• Pourquoi les approches « classiques » de load testing et d’observabilité ne suffisaient pas
• Et aussi pourquoi les outils d’IA, pourtant très efficaces sur d’autres sujets, sont complètement passés à côté du problème.

Cette présentation sera avant tout un retour d’expérience terrain : une vraie enquête de production, avec ses fausses pistes, ses hypothèses invalidées et les décisions d’ingénierie qui ont permis de stabiliser définitivement l’application.

La bonne nouvelle ? Aujourd’hui, les pods qui restartent en boucle et les serveurs surdimensionnés à 16 Go de RAM « pour tenir un peu plus longtemps » appartiennent enfin au passé.