Um serviço é morto por falta de memória a cada dois dias. Como você investiga?

Confirme o padrão primeiro pelas métricas: crescimento constante aponta para um vazamento ou um cache sem limite, enquanto um pico agudo aponta para uma única requisição carregando coisa demais de uma vez. Capture um heap profile antes e depois de um período de crescimento e compare as alocações retidas. As causas de sempre são caches sem despejo, coleções crescendo dentro de objetos de vida longa, recursos não fechados e endpoints que carregam um result set inteiro em memória.

O formato do gráfico me diz onde olhar. Uma subida lenta ao longo de dias que sobrevive a períodos calmos é um vazamento ou um cache sem limite. Um dente de serra que dispara em requisições específicas significa que algo carrega demais de uma vez. Para o primeiro caso eu tiro heap profiles com algumas horas de diferença sob tráfego parecido e faço um diff por tamanho retido, depois olho o que segura os maiores objetos. Na prática costuma ser algo sem graça: um mapa usado como cache sem despejo e sem máximo, um label de métrica construído a partir de um valor fornecido pelo usuário, então a cardinalidade cresceu para sempre, ou listeners registrados num objeto de vida longa e nunca removidos. Para picos eu procuro endpoints que leem uma tabela inteira para uma lista em vez de fazer streaming, ou um job em lote que carrega todas as linhas antes de gravar. Peguei exatamente isso numa exportação CSV que materializava um milhão de linhas; fazer streaming em páginas deixou a memória plana. Depois eu adiciono um alerta na tendência de memória, não só na queda, para saber disso antes do reinício.