Ferramentas para solucionar problemas 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.

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.

Saúde dos recursos

Você pode monitorizar eventos do ciclo de vida da aplicação e configurar alertas com o Azure Activity Log e o Azure Service Health. Para obter mais informações, consulte Monitorizar eventos do ciclo de vida da aplicação usando o log de atividades do Azure e o Azure Service Health.

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 ecrã a seguir mostra um alerta de estado de recurso da aplicação, indicando um problema de OOM.

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.

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.

Captura de ecrã do portal do Azure a mostrar a página Diagnosticar e resolver problemas do Azure Spring Apps com a Utilização da Memória realçada no menu suspenso.

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.

Captura de ecrã do portal do Azure a mostrar a página Utilização da Memória das Aplicações Azure Spring.

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.memória.utilizada/comprometida/máxima

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 heap e da antiga memória permGen de memória fora do 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 a memória heap usada e a permGen anterior usada em memória fora do heap.

    jvm.memory.used é um reflexo significativo da mudança da memória heap, porque a antiga parte PermGen é geralmente estável.

    Se achar jvm.memory.used muito grande, considere definir um tamanho máximo menor para a heap de memória.

  • jvm.memory.committed é a quantidade de memória comprometida para a JVM usar. O tamanho de jvm.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 jvm.memory.max pode às vezes ser confuso porque pode ser muito maior do que a memória disponível do aplicativo. Para esclarecer, jvm.memory.max é a soma de todos os tamanhos máximos da memória heap e da antiga parte permGen da 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 secção Tamanho máximo de heap padrão em Gerenciamento de memória Java.

    Se o tamanho padrão do espaço de classe compactado for 1 GB, então o valor de jvm.memory.max será maior que 1,5 GB, independentemente de o tamanho da memória do aplicativo 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 da Oracle.

jvm.gc.memory.alocado/promovido

Essas duas métricas são para observar a coleta de lixo Java (GC). Para obter mais informações, consulte a secção de recolha de lixo Java no 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 um menor GC.

  • 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.

Captura de ecrã do portal do Azure a mostrar a página Azure Spring Apps Metrics.

Depuração mais aprofundada

Para depuração adicional, pode capturar manualmente dumps de heap e dumps de thread e usar o Java Flight Recorder (JFR). Para mais informações, veja Capturar os despejos de pilha e de threads manualmente e usar o Java Flight Recorder no Azure Spring Apps.

Os heap dumps registam o estado da memória heap do 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.

Captura de ecrã do portal do Azure a mostrar a página de descrição geral da aplicação com o botão Resolução de problemas realçado.

Para mais informações, veja Capturar os despejos de pilha e de threads 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:

Captura de tela do portal do Azure mostrando a página de configuração do aplicativo com as opções da JVM realçadas.

Consulte também