Partilhar via


Problemas de reinicialização do aplicativo causados por problemas de falta de memória

Nota

Os planos Basic, Standarde Enterprise entraram em um período de aposentadoria em 17 de março de 2025. Para obter mais informações, consulte o anúncio de aposentadoria do Azure Spring Apps.

O plano de consumo padrão e o plano dedicado entraram em um período de desativação a 30 de setembro de 2024, com um encerramento completo até o final de março de 2025. Para mais informações, consulte Migrar o plano de consumo padrão e dedicado do Azure Spring Apps para Azure Container Apps.

Este artigo aplica-se a:✅ Basic/Standard ✅ Enterprise

Este artigo descreve problemas de falta de memória (OOM) para aplicativos Java no Azure Spring Apps.

Tipos de problemas de falta de memória

Há dois tipos de problemas de falta de memória: OOM de container e OOM da JVM.

  • O OOM de contêiner, também chamado de OOM do sistema, ocorre quando a memória disponível do aplicativo se esgota. O problema de OOM no contêiner causa eventos de reinicialização do aplicativo, que são relatados na seção Saúde de Recurso do portal Azure. Normalmente, o OOM do contêiner é causado por configurações incorretas de tamanho de memória.

  • JVM OOM ocorre quando a quantidade de memória usada atingiu o tamanho máximo definido nas opções da JVM. A JVM OOM não fará com que um aplicativo seja reiniciado. Normalmente, o OOM da JVM é resultado de um código incorreto, que você pode encontrar procurando java.lang.OutOfMemoryError exceções no log do aplicativo. A JVM OOM tem um efeito negativo sobre a aplicação e as ferramentas de criação de perfil Java, como o Java Flight Recorder.

Este artigo se concentra em como corrigir problemas de OOM de contêiner. Para corrigir problemas de OOM da JVM, verifique ferramentas como heap dump, thread dump e Java Flight Recorder. Para obter mais informações, consulte Capturar despejo de pilha e despejo de thread manualmente e usar o Java Flight Recorder no Azure Spring Apps.

Corrigir problemas de reinicialização do aplicativo devido ao OOM

As seções a seguir descrevem as ferramentas, métricas e opções da JVM que você pode usar para diagnosticar e corrigir problemas de OOM de contêiner.

Ver alertas na página Saúde do recurso

A página Integridade do recurso no portal do Azure mostra eventos de reinicialização do aplicativo devido ao OOM do contêiner, conforme mostrado na captura de tela a seguir:

Captura de ecrã do portal do Azure a mostrar a página Estado de Funcionamento dos Recursos do Azure Spring Apps com a mensagem OOM realçada.

Configurar o tamanho da memória

As métricas Uso da memória do aplicativo, jvm.memory.usede jvm.memory.committed fornecem uma exibição do uso da memória. Para obter mais informações, consulte a seção Métricas de Ferramentas para solucionar problemas de memória. Configure os tamanhos máximos de memória nas opções da JVM para garantir que a memória esteja abaixo do limite.

A soma dos tamanhos máximos de memória de todas as partes no modelo de memória Java deve ser menor do que a memória real disponível do aplicativo. Para definir os tamanhos máximos de memória, consulte o layout de memória típico descrito na seção Layout de uso de memória do gerenciamento de memória Java.

Encontre um equilíbrio ao definir o tamanho máximo de memória. Quando se define o tamanho máximo de memória muito alto, há um risco de o contentor exceder o limite de memória. Quando se define a memória máxima muito baixa, há um risco de falta de memória na JVM, e a coleta de lixo ocorrerá com mais frequência, o que tornará a aplicação mais lenta.

Controlar a memória de pilha

Você pode definir o tamanho máximo da pilha usando as -Xms, -Xmx, -XX:InitialRAMPercentage e -XX:MaxRAMPercentage opções JVM.

Talvez seja necessário ajustar as configurações de tamanho máximo de heap quando o valor de jvm.memory.used for muito alto nas métricas. Para obter mais informações, consulte a seção jvm.memory.used/committed/max de Ferramentas para solucionar problemas de memória.

Controle a memória direta

É importante definir a -XX:MaxDirectMemorySize opção JVM pelos seguintes motivos:

  • Você pode não perceber quando frameworks como nio e gzip usam memória direta.
  • A recolha de lixo da memória direta é efetuada apenas durante a recolha completa de lixo, e esta ocorre somente quando a heap está quase cheia.

Normalmente, pode definir MaxDirectMemorySize como um valor menor do que o tamanho da memória da aplicação menos a memória heap menos a memória não alocada.

Controle o metaespaço

Você pode definir o tamanho máximo do metaespaço definindo a -XX:MaxMetaspaceSize opção JVM. A -XX:MetaspaceSize opção define o valor limite para acionar a coleta completa de lixo.

A memória do metaespaço é geralmente estável.

Consulte também