Fundamentos da JVM para Elasticsearch: métricas, memória e monitoramento

O Elasticsearch é um mecanismo de análise de dados e buscar baseado em Java e um banco de dados vetorial criado sobre o Apache Lucene, e é o núcleo da Elasticsearch Platform. Para executar o Elasticsearch em suas plataformas suportadas, você precisa de uma máquina virtual Java (JVM). A JVM fornece um ambiente de tempo de execução independente de Platform, e você pode executar o Elasticsearch em um ambiente virtual sobre o sistema operacional existente. A JVM abstrai o sistema operacional e o hardware subjacentes, para que as aplicações Java possam executar em qualquer Platform.

Entender o gerenciamento de memória da JVM e a coleta de objetos via coleta de lixo (GC) é a chave para solucionar problemas como java.lang.OutOfMemoryError (código de saída 127). Esses problemas ocorrem quando a JVM executa sem memória ou quando há um código de saída 137, o que normalmente indica que o OOM (out-of-memory) killer do host encerrou o processo da JVM devido ao uso excessivo de memória. Este blog guiará você sobre como examinar os padrões de uso de memória e solucionar esses problemas da JVM.

Também explicarei a função da JVM e como correlacioná-la com a ajuda das APIs existentes do Elasticsearch, fornecendo insights valiosos sobre o estado da JVM do Elasticsearch e ajudando você a decidir se deseja ajustá-la ainda mais de acordo com seu próprio caso de uso. 

Conforme mencionado na documentação da JVM do Elasticsearch, os valores padrão das opções da JVM que são enviados com o produto funcionam de forma eficiente em todos os ambientes de produção suportados; esses valores padrão podem lidar com a maioria dos casos de uso para operações de busca e indexação. Não é recomendada a alteração de quaisquer valores ou a adição de valores personalizados para as opções ou configurações da JVM.

Uma máquina virtual Java é parte integrante do Java Runtime Environment (JRE), que vem incluído em um Java Development Kit (JDK).

A JVM é semelhante a um programa de computador que ajuda a executar aplicações Java. Ela não existe como uma máquina física, mas age como uma ao traduzir código Java em instruções que seu sistema operacional compatível consegue entender. A JVM também cuida de tarefas importantes como gerenciamento de memória, tratamento de coleta de lixo e manutenção da segurança de suas aplicações.

Em seguida, vamos focar no gerenciamento de memória da JVM e na coleta de lixo — um ponto importante no Elasticsearch que verificamos frequentemente ao solucionar problemas de desempenho de memória ou relacionados a OOM.

Para entender o gerenciamento de memória e a coleta de lixo, primeiro você precisa entender a representação lógica da área de heap (ou memória heap) onde todos os objetos residem quando uma JVM é iniciada.

Área/região young generation
Quando qualquer aplicação Java inicia, ela cria novos objetos e aloca esses novos objetos na área chamada memória heap. O Eden space da young generation é o primeiro lugar onde a aplicação aloca objetos recém-criados. Esta área é reservada para a alocação de novos objetos. E quando ela fica cheia, os objetos elegíveis serão coletados (garbage collected) ou promovidos para outras regiões.

Quando ocorre uma coleta de lixo menor, os objetos referenciados serão movidos para outra subseção, que é a região Survivor S0. E os objetos não referenciados serão excluídos para liberar espaço no Eden. Esta região contém os objetos que sobreviveram ao processo de coleta de lixo, daí o nome região Survivor. 

O mesmo ciclo se repete quando o espaço Eden está cheio novamente. Desta vez, os objetos que sobreviveram tanto ao Eden quanto ao S0 serão movidos para a região S1, e esse processo continua. 

Os objetos que sobreviveram às coletas de lixo em Eden, S0 e S1 serão promovidos para a geração antiga com base no calculador de idade.

Área/região da old generation
A old generation (também conhecida como tenured generation) é uma coleção de objetos de longa duração que sobreviveram aos múltiplos eventos de garbage collection na young generation (minor GCs). Objetos que sobreviveram a um certo número de ciclos no survivor space são movidos pelo algoritmo para a old generation, também conhecida como promoção de objetos.

O padrão de GC em dente de serra acima, proveniente do Stack Monitoring, mostra que, quando a coleta de lixo secundária está ocorrendo, a memória heap da JVM é reduzida porque o GC está removendo os objetos indesejados da memória. Após alguns ciclos, os objetos se acumulam e o GC entra em ação novamente para limpar os objetos. 

O G1GC tem um alvo de tempo de pausa (-XX:MaxGCPauseMillis=200) que ele tenta atingir durante a coleta de lixo. Isso significa que, durante a coleta de lixo, ele garante que a JVM não sofra uma pausa superior a esse valor, tornando-o melhor que o CMS ou outros coletores onde essa não é uma opção. No geral, recomenda-se manter as configurações de GC com os valores padrão, o que manterá a pausa do GC dentro dos limites para um desempenho aprimorado.

Esta API fornecerá os detalhes da configuração do Node, incluindo argumentos de entrada da JVM, pools de memória e tamanho do heap. 

Além disso, se você quiser verificar as métricas da JVM do Elasticsearch para o tempo de funcionamento de um Node específico, o heap usado em todos os pools de memória ou estatísticas sobre a coleta de lixo, você pode usar a API de estatísticas de Node. Ela fornecerá métricas detalhadas sobre cada uma das métricas mencionadas.

Se você for um usuário avançado e quiser verificar estatísticas em tempo real sobre uma JVM em execução sem usar APIs do Elasticsearch, você pode usar o Java incluído e executar o jstat para verificar as estatísticas ao vivo. Para fazer isso, primeiro encontre o diretório home do Java ou o diretório bin e o PID do processo do Elasticsearch. A partir do diretório bin, use a ferramenta jstat:

Aqui, 2000 é o intervalo em milissegundos após o qual as estatísticas serão buscadas e impressas na CLI. Este comando é útil para identificar com que frequência o GC está ocorrendo em todas as áreas e quão rápido os pools de memória estão sendo preenchidos pelos objetos (taxas de criação e promoção de objetos). 

Esta não é uma alternativa às APIs mencionadas acima, mas é mais voltada para a depuração em nível de desenvolvedor.

O lançamento e o tempo de amadurecimento de todos os recursos ou funcionalidades descritos neste artigo permanecem a exclusivo critério da Elastic. Os recursos ou funcionalidades não disponíveis no momento poderão não ser entregues ou não chegarem no prazo previsto.