Un service se fait tuer pour dépassement mémoire tous les deux jours. Comment enquêtez-vous ?

Confirmez d'abord le motif dans les métriques : une croissance régulière pointe vers une fuite ou un cache non borné, tandis qu'un pic net pointe vers une requête unique qui charge trop d'un coup. Capturez un profil de tas avant et après une période de croissance et comparez les allocations retenues. Les causes habituelles sont des caches sans éviction, des collections qui grossissent tenues par des objets à longue durée de vie, des ressources non fermées, et des endpoints qui chargent tout un jeu de résultats en mémoire.

La forme de la courbe me dit où regarder. Une montée lente sur plusieurs jours qui survit aux périodes calmes est une fuite ou un cache sans borne. Une dent de scie qui pique sur certaines requêtes signifie que quelque chose charge trop d'un coup. Pour le premier cas, je prends des profils de tas à quelques heures d'intervalle sous un trafic comparable et je les compare par taille retenue, puis je regarde ce qui tient les plus gros objets. En pratique, c'est en général quelque chose de banal : une map utilisée comme cache sans éviction ni maximum, un libellé de métrique construit à partir d'une valeur fournie par l'utilisateur si bien que la cardinalité grandit sans fin, ou des écouteurs enregistrés sur un objet à longue durée de vie et jamais retirés. Pour les pics, je cherche des endpoints qui lisent toute une table dans une liste au lieu de la parcourir en flux, ou un traitement par lots qui charge chaque ligne avant d'écrire. J'ai eu exactement ça avec un export CSV qui matérialisait un million de lignes ; le passer en flux paginé a rendu la mémoire plate. Ensuite j'ajoute une alerte sur la tendance mémoire plutôt que seulement sur le crash, pour être prévenu avant le redémarrage.