Ferramentas para solucionar problemas de memória
Observação
Os planos Básico, Standard e Enterprise serão preteridos a partir de meados de março de 2025, com um período de desativação de 3 anos. Recomendamos a transição para os Aplicativos de Contêiner do Azure. Para mais informações, confira o anúncio de desativação dos Aplicativos Spring do Azure.
O plano Standard de consumo 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 mais informações, confira Migrar o plano Standard de consumo e dedicado dos Aplicativos Spring do Azure para os Aplicativos de Contêiner do Azure.
Este artigo se aplica ao: ✔️ nível Básico/Standard ✔️ nível Enterprise
Este artigo descreve várias ferramentas úteis para solucionar problemas de memória Java. Você pode usar essas ferramentas em vários cenários não limitados a problemas de memória, mas este artigo se concentra apenas no tópico da memória.
Alertas e diagnóstico
As seções a seguir descrevem os alertas de integridade do recurso e diagnósticos disponíveis por meio do portal do Azure.
Integridade de recursos
Você pode monitorar os eventos do ciclo de vida do aplicativo e configurar alertas usando o log de atividades do Azure e a Integridade do Serviço do Azure. Para saber mais, confira Monitorar os 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 OOM (memória insuficiente) do contêiner. Para obter mais informações, confira Problemas de reinicialização do aplicativo causados por problemas de memória insuficiente.
A captura de tela a seguir mostra um alerta de integridade do 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 aplicativo sem configuração. Para obter mais informações, confira Fazer o autodiagnóstico e resolver problemas nos Aplicativos Spring do Azure.
No portal do Azure, você pode encontrar o 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 uso de memória do aplicativo, conforme mostrado na captura de tela a seguir.
Métricas
As seções a seguir descrevem métricas que abordam problemas, incluindo alto uso da memória, memória heap muito grande e coleta de lixo anormal (muito ou pouco frequente). Para obter mais informações, confira Guia de início rápido: monitorar aplicativos dos Aplicativos Spring do Azure com logs, métricas e rastreamento.
Uso de memória do aplicativo
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 memória JVM, há três métricas: jvm.memory.used, jvm.memory.committed e jvm.memory.max, que estão descritas na lista a seguir.
"Memória JVM" não é um conceito claramente definido. Aqui, jvm.memory é a soma da memória heap 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 de jvm.memory.
jvm.memory.usedé a quantidade de memória JVM usada, incluindo memória heap usada e permGen anterior usado na memória não heap.jvm.memory.usedé um grande reflexo da alteração da memória heap, pois a parte anterior do permGen é geralmente estável.Se você achar
jvm.memory.usedmuito grande, considere definir um tamanho de memória heap máximo menor.jvm.memory.committedé a quantidade de memória confirmada para uso pela JVM. 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 e não deve ser confundida com a quantidade real disponível.O valor de
jvm.memory.maxàs vezes pode ser confuso porque pode ser muito maior do que a memória do aplicativo disponível. Para esclarecer,jvm.memory.maxé a soma de todos os tamanhos máximos de memória heap e a parte anterior permGen da memória não heap, independentemente da memória real disponível. Por exemplo, se um aplicativo for definido com 1 GB de memória no portal doo Aplicativos Spring do Azure, o tamanho de memória heap padrão 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 padrão do espaço de classe compactado for de 1 GB, o valor
jvm.memory.maxserá maior que 1,5 GB, independentemente do tamanho de 1 GB da memória do aplicativo. Para obter mais informações, consulte a Plataforma Java, Guia de Ajuste de Coleta de Lixo da Máquina Virtual HotSpot Edição Standard: outras considerações na documentação do Oracle.
jvm.gc.memory.allocated/promoted
Essas duas métricas servem para observar a GC (coleta de lixo) Java. Para obter mais informações, consulte a seção Coleta de lixo Java do Gerenciamento de memória Java. O tamanho máximo do heap influencia a frequência da GC secundária e da GC completa. O metaspace máximo e o tamanho máximo de memória direta influenciam a GC Completa. Se você quiser ajustar a frequência da coleta de lixo, considere modificar os tamanhos máximos de memória a seguir.
jvm.gc.memory.allocatedé o valor do aumento no tamanho do pool de memória de geração jovem, de após um GC e antes do próximo. Esse valor reflete a GC secundária.jvm.gc.memory.promotedé o aumento no tamanho do pool de memória da geração antiga após a GC. Esse valor reflete a GC completa.
Você pode encontrar essa funcionalidade 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, é possível capturar manualmente despejos de heap e despejos de thread e usar o JFR (Java Flight Recorder). Para obter mais informações, consulte Capturar o despejo de heap e o despejo de thread manualmente e usar o Java Flight Recorder no Azure Spring Apps.
Os despejos de heap registram o estado da memória heap do Java. Os despejos 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 o despejo de heap e o 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 heap.
Modificar configurações para corrigir problemas
Alguns problemas que podem ser identificados incluem OOM de contêiner, memória heap muito grande e coleta de lixo anormal. Se você identificar qualquer um desses problemas, talvez seja necessário configurar o tamanho máximo da memória nas opções da JVM. Para obter mais informações, consulte a seção Opções de JVM importantes do Gerenciamento de memória Java.
Você pode modificar as opções de 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 Opções de JVM, conforme mostrado na seguinte captura de tela:
