Compartilhar via

Ferramentas para solucionar problemas de memória

  • Artigo

Observação

Azure Spring Apps é o novo nome do serviço Azure Spring Cloud. Embora o serviço tenha um novo nome, você verá o nome antigo em alguns locais por um tempo enquanto trabalhamos para atualizar ativos como capturas de tela, vídeos e diagramas.

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.

Captura de tela do portal do Azure mostrando a página Resource Health dos Aplicativos Spring do Azure com a mensagem de OOM em destaque.

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.

Captura de tela do portal do Azure mostrando a página Diagnosticar e resolver problemas dos Aplicativos Spring do Azure com o Uso de memória destacado no menu suspenso.

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.

Captura de tela do portal do Azure mostrando a página Uso de Memória dos Aplicativos Spring do Azure.

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.used muito 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 de jvm.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.max será 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.

Captura de tela do portal do Azure mostrando a página Métricas dos Aplicativos Spring do Azure.

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.

Captura de tela do portal do Azure mostrando a página de visão geral do aplicativo com o botão de Solução de problemas em destaque.

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:

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

Confira também