Un servicio muere por falta de memoria cada dos días. ¿Cómo lo investigas?

Confirma primero el patrón en las métricas: un crecimiento constante apunta a una fuga o a una caché sin límite, mientras que un pico brusco apunta a una sola petición que carga demasiado de golpe. Captura un perfil de memoria antes y después de un periodo de crecimiento y compara las asignaciones retenidas. Las causas habituales son cachés sin desalojo, colecciones que crecen colgando de objetos de vida larga, recursos sin cerrar y endpoints que cargan un conjunto de resultados entero en memoria.

La forma de la gráfica me dice dónde mirar. Una subida lenta durante días que sobrevive a los periodos tranquilos es una fuga o una caché sin límite. Un diente de sierra que pica en peticiones concretas significa que algo carga demasiado de golpe. Para el primer caso tomo perfiles de memoria con unas horas de diferencia bajo tráfico parecido y los comparo por tamaño retenido, y luego miro qué sostiene los objetos más grandes. En la práctica ha sido casi siempre algo aburrido: un mapa usado como caché sin desalojo ni máximo, una etiqueta de métrica construida a partir de un valor que envía el usuario, con lo que la cardinalidad crecía sin fin, o listeners registrados sobre un objeto de vida larga que nunca se quitaban. Para los picos busco endpoints que leen una tabla entera a una lista en vez de ir en streaming, o un proceso por lotes que carga todas las filas antes de escribir. Me topé exactamente con eso en una exportación a CSV que materializaba un millón de filas; hacerla en streaming por páginas dejó la memoria plana. Después añado una alerta sobre la tendencia de memoria y no solo sobre la caída, para enterarme antes que el reinicio.