Ferramentas para solucionar problemas de memória
Nota
Os planos Basic, Standard e Enterprise serão preteridos a partir de meados de março de 2025, com um período de aposentadoria de 3 anos. Recomendamos a transição para os Aplicativos de Contêiner do Azure. Para obter mais informações, consulte o anúncio de aposentadoria do Azure Spring Apps.
O plano de consumo padrão e dedicado será preterido a partir de 30 de setembro de 2024, com um desligamento completo após seis meses. Recomendamos a transição para os Aplicativos de Contêiner do Azure. Para obter mais informações, consulte Migrar consumo padrão e plano dedicado do Azure Spring Apps para Aplicativos de Contêiner do Azure.
Este artigo aplica-se a:✅ Basic/Standard ✅ Enterprise
Este artigo descreve várias ferramentas que são úteis para solucionar problemas de memória Java. Você pode usar essas ferramentas em muitos cenários não limitados a problemas de memória, mas este artigo se concentra apenas no tópico de memória.
Alertas e diagnósticos
As seções a seguir descrevem alertas e diagnósticos de integridade de recursos disponíveis por meio do portal do Azure.
Estado de funcionamento de recursos
Você pode monitorar eventos do ciclo de vida do aplicativo e configurar alertas com o log de atividades do Azure e a integridade do serviço do Azure. Para obter mais informações, consulte Monitorar eventos do ciclo de vida do aplicativo usando o log de atividades do Azure e a Integridade do Serviço do Azure.
A integridade do recurso envia alertas sobre eventos de reinicialização do aplicativo devido a problemas de falta de memória (OOM) do contêiner. Para obter mais informações, consulte Problemas de reinicialização do aplicativo causados por problemas de falta de memória.
A captura de tela a seguir mostra um alerta de integridade de recurso do aplicativo indicando um problema de OOM.
Diagnosticar e resolver problemas
O diagnóstico do Azure Spring Apps é uma experiência interativa para solucionar problemas do seu aplicativo sem configuração. Para obter mais informações, consulte Autodiagnosticar e resolver problemas no Azure Spring Apps.
No portal do Azure, você pode encontrar Uso de Memória em Diagnosticar e resolver problemas, conforme mostrado na captura de tela a seguir.
O Uso de memória fornece um diagnóstico simples para o uso da memória do aplicativo, conforme mostrado na captura de tela a seguir.
Métricas
As seções a seguir descrevem métricas que abrangem problemas como alto uso de memória, memória de pilha muito grande e coleta de lixo anormal (muito frequente ou não frequente o suficiente). Para obter mais informações, consulte Guia de início rápido: monitorando aplicativos do Azure Spring Apps com logs, métricas e rastreamento.
Utilização da memória da aplicação
O uso da memória do aplicativo é uma porcentagem igual à memória do aplicativo usada dividida pelo limite de memória do aplicativo. Esse valor mostra toda a memória do aplicativo.
jvm.memory.used/committed/max
Para a memória JVM, há três métricas: jvm.memory.used, jvm.memory.committede jvm.memory.max, que são descritas na lista a seguir.
"Memória JVM" não é um conceito claramente definido. Aqui, jvm.memory é a soma da memória de pilha e da antiga parte permGen da memória não-heap. A memória JVM não inclui memória direta ou outra memória, como a pilha de threads. O Spring Boot Actuator reúne essas três métricas e determina o escopo do jvm.memory.
jvm.memory.usedé a quantidade de memória JVM usada, incluindo memória de pilha usada e permGen anterior usada em memória não heap.jvm.memory.usedé um grande reflexo da mudança da memória de pilha, porque a antiga parte permGen é geralmente estável.Se você achar
jvm.memory.usedmuito grande, considere definir um tamanho máximo menor de memória de pilha.jvm.memory.committedé a quantidade de memória comprometida para a JVM usar. O tamanho dejvm.memory.committedé basicamente o limite de memória JVM utilizável.jvm.memory.maxé a quantidade máxima de memória JVM, não deve ser confundida com a quantidade real disponível.O valor de às vezes pode ser confuso porque pode ser muito maior do que a memória disponível
jvm.memory.maxdo aplicativo. Para esclarecer,jvm.memory.maxé a soma de todos os tamanhos máximos de memória de pilha e a antiga parte permGen de memória não-heap, independentemente da memória real disponível. Por exemplo, se um aplicativo estiver definido com 1 GB de memória no portal do Azure Spring Apps, o tamanho padrão da memória de pilha será de 0,5 GB. Para obter mais informações, consulte a seção Tamanho máximo de heap padrão do gerenciamento de memória Java.Se o tamanho do espaço de classe compactado padrão for 1 GB, o valor de será maior que 1,5 GB, independentemente de o tamanho da memória do
jvm.memory.maxaplicativo ser de 1 GB. Para obter mais informações, consulte Java Platform, Standard Edition HotSpot Virtual Machine Garbage Collection Tuning Guide: Other Considerations na documentação do Oracle.
jvm.gc.memory.allocated/promovido
Essas duas métricas são para observar a coleta de lixo Java (GC). Para obter mais informações, consulte a seção Coleta de lixo Java do gerenciamento de memória Java. O tamanho máximo da pilha influencia a frequência de GC menor e GC completo. O metaespaço máximo e o tamanho máximo da memória direta influenciam o GC completo. Se você quiser ajustar a frequência da coleta de lixo, considere modificar os seguintes tamanhos máximos de memória.
jvm.gc.memory.allocatedé a quantidade de aumento no tamanho do pool de memória de geração jovem após um GC e antes do próximo. Este valor reflete GC menor.jvm.gc.memory.promotedé a quantidade de aumento no tamanho do pool de memória de geração antiga após o GC. Esse valor reflete o GC completo.
Você pode encontrar esse recurso no portal do Azure, conforme mostrado na captura de tela a seguir. Você pode escolher métricas específicas e adicionar filtros para um aplicativo, implantação ou instância específicos. Você também pode aplicar a divisão.
Depuração adicional
Para depuração adicional, você pode capturar manualmente despejos de pilha e dumps de thread e usar o Java Flight Recorder (JFR). 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.
Os despejos de pilha registram o estado da memória de heap Java. Os dumps de thread registram as pilhas de todos os threads dinâmicos. Essas ferramentas estão disponíveis por meio da CLI do Azure e na página do aplicativo do portal do Azure, conforme mostrado na captura de tela a seguir.
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. Você também pode usar ferramentas de terceiros, como o Analisador de Memória, para analisar despejos de pilha.
Modificar configurações para corrigir problemas
Alguns problemas que você pode identificar incluem OOM de contêiner, memória de pilha muito grande e coleta de lixo anormal. Se você identificar qualquer um desses problemas, talvez seja necessário configurar o tamanho máximo de memória nas opções da JVM. Para obter mais informações, consulte a seção Opções importantes da JVM do gerenciamento de memória Java.
Você pode modificar as opções da JVM usando o portal do Azure ou a CLI do Azure.
No portal do Azure, navegue até seu aplicativo e selecione Configuração na seção Configurações do menu de navegação. Na guia Configurações Gerais, atualize o campo de opções da JVM, conforme mostrado na captura de tela a seguir:
