O registro da coleta de lixo afeta o desempenho do aplicativo?

Às vezes encontramos usuários de Java que acreditam que a ativação do registro de coleta de lixo terá um impacto significativo em suas métricas de desempenho. Vamos examinar os fatos e mitos.

Sobre o coletor de lixo

O coletor de lixo Java é uma parte crucial da Java Virtual Machine (JVM) que afeta o desempenho e a confiabilidade do seu aplicativo. Se você quiser se aprofundar nos detalhes dos diferentes tipos de coletores de lixo disponíveis no tempo de execução Java e como eles funcionam, confira esta postagem anterior do blog: “O que devo saber sobre a coleta de lixo como desenvolvedor Java”.

O que é registro de GC?

O log de coleta de lixo (GC) é um recurso da JVM que fornece informações sobre o processo de coleta de lixo. Graças aos arquivos de log gerados, você pode obter insights sobre como a JVM gerencia a memória dinamicamente em tempo de execução, coletando e descartando objetos que o programa não precisa mais. Isso é muito útil quando você deseja monitorar o desempenho de um aplicativo Java, diagnosticar vazamentos de memória e ajustar a configuração de coleta de lixo da JVM.

“Alguns de nossos clientes buscam cada microssegundo para melhorar o desempenho de suas aplicações, mas ainda permitem o registro de GC”, observa Daniel Witkowski, engenheiro de vendas da Azul. “Como tem pouco ou nenhum impacto no desempenho do aplicativo e permite a depuração de muitos problemas diferentes, é vital que essas empresas sempre consigam recuperar os logs do GC após a ocorrência de um problema.”

Quando o log de coleta de lixo está ativado, sempre que a JVM executa uma coleta de lixo, as seguintes informações são armazenadas em um arquivo de log:

• Tipodo evento GC
  • GC Menor: Limpando o espaço da geração jovem
  • GC principal: Limpando o espaço da velha geração
  • GC completo: Limpando todo o espaço de heap
• Tempoquando o evento GC começou
• Duraçãodo evento GC
• Quantidade de memóriaantes e depois do evento GC para cada pool de memória
• Memória total disponívelem cada piscina

O arquivo de log é legível por humanos e o conteúdo é semelhante a este:

As informações e o formato armazenados podem variar dependendo da JVM e do algoritmo de GC que você usa.

Habilitando o registro do GC

O log do GC é ativado com o argumento de linha de comando Java-Xlog. Isso está disponível desde Java 9, graças ao JEP 158 “Unified JVM Logging”:

• -Xlog:gc,safepoint:gc.logpara ativar o registro padrão dos eventos importantes de coleta de lixo, incluindo todas as pausas do ponto seguro.
• -Xlog:gc*,safepoint:gc.log para permitir o registro mais detalhado, incluindo todas as pausas do ponto seguro e eventos e fases menores do coletor de lixo que normalmente não são registrados. Para OpenJDK, isso geralmente é necessário; caso contrário, algumas métricas de memória heap Java não serão registradas e nem todas as pausas serão rastreadas. No Zing, isso não é necessário, pois todos os dados necessários já estão registrados por padrão com apenas gc. A troca entre gc e gc* geralmente é 10 vezes mais quantidade de dados de log, o que reduzirá o intervalo de tempo que seu log cobre.
• -Xlog:gc,safepointpara gravar os dados de log em stdouto que pode ser útil em contêineres para evitar o armazenamento de arquivos de log locais.
• -Xlog:gc,safepoint:gc.log::filecount=10,filesize=100M para alterar a rotação de log padrão de 5 arquivos de 20 MB cada para 10 arquivos de 100 MB cada.
• -Xlog:gc,safepoint:gc.log::filecount=0para desabilitar a rotação do arquivo de log, útil para execuções de testes rápidos ou para processos que são reiniciados com frequência. Observe os dois pontos duplos.

Você pode até repetir o -Xlog argumento e usá-lo para especificar diferentes saídas ao mesmo tempo – por exemplo, o seguinte grava-o em stdout e para um arquivo local:

$ java -Xlog:gc,safepoint -Xlog:gc,safepoint:/opt/log/gc.log -jar myApp.jar

Há mais opções disponíveis com o sistema de log unificado, como você pode ver ao executar o seguinte comando:

Impacto do registro do GC

Habilitar o log do GC em um aplicativo Java geralmente tem impacto mínimo no desempenho, especialmente com JVMs modernas. No entanto, o impacto exato pode variar com base na versão da JVM, no algoritmo de GC usado, nas configurações de registro do GC e no desempenho de E/S do sistema onde os logs são gravados. Estes são alguns fatos que você precisa levar em consideração:

• Risco de encher o sistema de arquivos: preencher um sistema de arquivos até 100% ou próximo de 100% é o impacto de desempenho mais prático frequentemente visto em relação ao registro em log e precisa ser evitado. Por padrão, Java 9 e versões mais recentes têm a rotação de arquivos de log habilitada e gravarão apenas cinco fragmentos de log de 20 MB cada.
• Operações de E/S: os logs do GC são gravados diretamente no disco. Isso cria operações de E/S e pode, portanto, tornar o aplicativo mais lento se o disco estiver lento ou se houver uma alta porcentagem de uso do disco.
• Buffer de memória: JVMs modernas normalmente usam um buffer de memória para logs de GC. Quando o buffer está cheio, os logs vão para o disco para reduzir o impacto de E/S. No entanto, o buffer ocupa memória que o aplicativo poderia usar de outra forma.
• Registros detalhados do GC: se os logs de GC detalhados estiverem ativados, como aqueles que registram o tempo por thread ou estatísticas de objeto, o impacto no desempenho poderá se tornar perceptível, pois esses dados precisam ser registrados e processados, o que pode consumir recursos da CPU.
• Pontos seguros: toda a atividade de registro do GC acontece em “pontos seguros” na execução do aplicativo, o que significa que não causa mais pausas de “parar o mundo” do que ocorreriam naturalmente devido à própria atividade do GC.

“O tópico prático de desempenho que os usuários devem considerar em relação ao registro do GC é a quantidade de dados no sistema de arquivos”, diz Holger, engenheiro da equipe de atendimento ao cliente da Azul. “Uma parada do sistema devido a um sistema de arquivos cheio resultaria em um desempenho muito ruim. Ao usar apenas-Xlog:gc:gc.log para Zing ou-Xlog:gc,safepoint:gc.logpara OpenJDK, você obtém todas as métricas relevantes de desempenho necessárias sem desperdiçar muito espaço. Especialmente em Zing,-XX:+PrintGCDetails, gc*ou safepoint não são necessários porque não adicionam mais gráficos no GCLogAnalyzer.”

“Uma grande parte das tarefas de log do GC é salvar os dados em um arquivo de log. O tipo de E/S usado para armazenar esses arquivos pode impactar o desempenho do registro, e não diretamente o aplicativo em si”, explica Deepak Sreedhar, principal engenheiro de software da Azul. “Portanto, alguns dos problemas que podem ocorrer não estão relacionados ao desempenho do registro do GC, mas à velocidade de E/S. Se os logs não puderem ser salvos com rapidez suficiente em tempo real, o OpenJDK tem a opção de usar o log unificado assíncrono comXlog:async.

Registro GC com Azul Zing

Ao usar o Azul Zing, você só precisa adicionar -Xlog:gc:gc.log para instruir Zing a armazenar arquivos de log do coletor de lixo. Argumentos extras como gc* ou safepoint para aumentar o nível de detalhe não são necessários, pois o Zing sempre registra pausas de safepoint e até mesmo informações adicionais não vistas nos logs do OpenJDK GC por padrão, como atividade do compilador just-in-time (JIT), uso de CPU e memória, cache de página do Linux métricas e mais algumas métricas frequentemente relevantes para análise de desempenho do sistema.

Analisando registros de GC

Existem várias ferramentas disponíveis para analisar o conteúdo dos arquivos de log do GC:

• JVM integrado jstat comando: este utilitário exibe estatísticas de desempenho e pode ser usado para gerar estatísticas do coletor de lixo.
• VisualVM: esta ferramenta oferece diversas visualizações de diferentes aspectos da JVM, como coleta de lixo. Ele também fornece métricas ao vivo, que podem ser úteis para analisar problemas em tempo real. Você pode baixar esta ferramenta no GitHub.
• Analisador de Log Azul GC: lê o log do GC e o visualiza como um conjunto de gráficos ao longo do tempo (relógio de parede e tempo de atividade). Ele mostra informações sobre o coletor de lixo, o compilador JIT, métricas do sistema e estatísticas do ReadyNow. Este aplicativo gráfico de desktop está documentado aqui e um vídeo passo a passo está disponível aqui.

Conclusão

Embora os logs de coleta de lixo possam apresentar custos mínimos de desempenho, a compensação geralmente vale a pena, pois os logs costumam ser inestimáveis ​​ao ajustar a coleta de lixo e diagnosticar problemas de memória. Sem os logs de GC habilitados, você pode perder insights sobre como a JVM gerencia a memória dinamicamente em tempo de execução. Estas informações são muito úteis para monitorar o desempenho de uma aplicação Java, diagnosticar vazamentos de memória e ajustar a configuração de coleta de lixo da JVM.

A postagem O registro da coleta de lixo afeta o desempenho do aplicativo? apareceu primeiro em The New Stack.