Ajuste da JVM para Desempenho do Elasticsearch: Dicas de Heap e Coleta de Lixo

O Elasticsearch é executado na JVM, então heap e coleta de lixo são importantes. Mas o ajuste da JVM não é por onde eu começaria se um cluster estiver lento. Primeiro verifique a contagem de shards, a forma da consulta, a pressão de indexação, a latência do disco e se o nó é simplesmente subdimensionado. As configurações da JVM são importantes porque valores ruins podem tornar um cluster saudável instável. Elas não são um atalho para um design de índice ruim ou hardware sobrecarregado.

Este guia foca no ajuste da JVM do Elasticsearch que ainda é útil nas operações do dia a dia: dimensionamento do heap, sintomas de coleta de lixo, pressão de memória e as verificações práticas que informam se o Java é realmente o problema.

Entendendo os Requisitos de Memória do Elasticsearch

O Elasticsearch requer memória para duas áreas principais: Memória Heap e Memória Off-Heap. O ajuste adequado envolve definir o heap corretamente e garantir que o sistema operacional tenha memória física suficiente restante para os requisitos off-heap.

1. Alocação de Memória Heap (`ES_JAVA_OPTS`)

O heap é onde residem os objetos, índices, shards e caches do Elasticsearch. É a configuração mais crítica a ser definida.

Definindo o Tamanho do Heap

O Elasticsearch recomenda fortemente definir o tamanho inicial do heap (-Xms) igual ao tamanho máximo do heap (-Xmx). Isso evita que a JVM redimensione dinamicamente o heap, o que pode causar pausas perceptíveis de desempenho.

Melhor Prática: A Regra dos 50%

Nunca aloque mais de 50% da RAM física para o heap do Elasticsearch. A memória restante é crucial para o cache do sistema de arquivos do Sistema Operacional (SO). O SO usa esse cache para armazenar dados de índice acessados com frequência (índices invertidos, campos armazenados) do disco, o que é significativamente mais rápido do que ler do disco.

Recomendação: Se uma máquina tem 64 GB de RAM, defina -Xms e -Xmx para 31g ou menos.

Localização da Configuração

Essas configurações são tipicamente configuradas no arquivo jvm.options localizado no diretório de configuração do Elasticsearch (por exemplo, $ES_HOME/config/jvm.options) ou via variáveis de ambiente, se você preferir gerenciar as configurações externamente (como usar ES_JAVA_OPTS).

Exemplo de Configuração (em jvm.options):

# Tamanho inicial do heap Java (por exemplo, 30 Gigabytes)
-Xms30g

# Tamanho máximo do heap Java (deve corresponder a -Xms)
-Xmx30g

Aviso sobre o Tamanho do Heap: Evite definir o tamanho do heap acima de 31 GB (ou aproximadamente 32 GB). Isso ocorre porque uma JVM de 64 bits usa ponteiros de objeto compactados (Compressed Oops) para heaps menores que ~32 GB, levando a layouts de objeto mais eficientes em termos de memória. Exceder esse limite geralmente anula esse benefício de eficiência.

2. Memória Off-Heap (Memória Direta)

O Elasticsearch também usa memória fora do heap Java. O Lucene depende fortemente do cache de página do sistema operacional, e o Elasticsearch pode usar memória direta para operações de rede e nativas. Na maioria das instalações, você não deve definir -XX:MaxDirectMemorySize a menos que a documentação do Elastic ou orientação de suporte para sua versão e carga de trabalho exatas diga para fazer isso. Um limite de memória direta manual pode criar um novo modo de falha se for muito baixo ou baseado em uma suposição desatualizada.

Ajuste da Coleta de Lixo (GC)

A coleta de lixo é o processo onde a JVM recupera memória usada por objetos que não são mais referenciados. No Elasticsearch, uma GC mal gerenciada pode causar picos significativos de latência, muitas vezes chamados de pausas "stop-the-world", que podem levar a timeouts de nó e instabilidade.

Escolhendo o Coletor Certo

As versões modernas do Elasticsearch são fornecidas com padrões de JVM suportados e geralmente usam G1GC em versões recentes comuns do Java. Trate esses padrões como a linha de base. Altere as configurações do coletor somente quando os logs e métricas mostrarem um problema real de coleta de lixo.

Parâmetros de Ajuste do G1GC

O parâmetro principal para otimização do G1GC é definir a meta de tempo máximo de pausa. Isso informa ao coletor com que agressividade ele deve limpar a memória.

Exemplo de Configuração G1GC:

# Exemplo apenas: não adicione flags de GC a menos que sua versão as suporte
# e você tenha evidências de que o comportamento padrão é o problema.
-XX:MaxGCPauseMillis=200

Monitorando a Atividade de GC

Um ajuste eficaz requer saber quando a GC é executada e quanto tempo leva. O Elasticsearch permite registrar eventos de GC diretamente em um arquivo, o que é essencial para solucionar problemas de latência.

Ativando o Log de GC:

Adicione estas flags ao seu arquivo jvm.options para ativar o log detalhado de GC:

# Ativar log de GC
-Xlog:gc*:file=logs/gc.log:time,level,tags

# Opcional: Especificar o tamanho da rotação do log (por exemplo, rotacionar após 10 MB)
-Xlog:gc*:file=logs/gc.log:utctime,level,tags:filecount=10,filesize=10m

Analise o arquivo gc.log resultante usando ferramentas como GCEasy ou scripts específicos para identificar:

Frequência: Com que frequência a GC é executada.
Duração: A duração das pausas (Total time for GC in...).
Taxa de Promoção: Quantos dados estão sobrevivendo tempo suficiente para se mover para a geração antiga.

Se as pausas de GC excederem consistentemente a meta MaxGCPauseMillis (por exemplo, atingindo frequentemente 500 ms ou mais), isso indica pressão de memória. As soluções incluem aumentar o tamanho do heap (se a RAM permitir, aderindo à regra dos 50%) ou otimizar padrões de indexação/consulta para reduzir a rotatividade de objetos.

Fluxo de Trabalho Prático de Ajuste e Melhores Práticas

Siga esta abordagem sistemática para ajustar as configurações da JVM do seu Elasticsearch:

Passo 1: Determinar a Capacidade do Nó

Identifique a RAM física total disponível na máquina que hospeda o nó do Elasticsearch.

Passo 2: Calcular o Tamanho do Heap

Calcule o tamanho máximo do heap: Heap Máximo = RAM Física * 0,5 (arredondado para baixo para a fração segura mais próxima, normalmente deixando 1-2 GB de buffer livre). Defina -Xms e -Xmx para este valor.

Passo 3: Deixe a Memória Direta em Paz, a Menos que Tenha um Motivo

Não copie flags de memória direta de postagens de blog antigas. Verifique primeiro a documentação da sua versão do Elasticsearch e os logs de inicialização atuais.

Passo 4: Configurar a GC

Certifique-se de que -XX:+UseG1GC esteja presente e considere definir uma meta razoável como -XX:MaxGCPauseMillis=100.

Passo 5: Ativar e Monitorar o Logging

Ative o log de GC e deixe o cluster ser executado sob uma carga de produção típica por várias horas ou dias. Revise os logs.

Passo 6: Iterar com Base nos Logs

Se as pausas forem muito longas: Você pode precisar reduzir a carga de indexação ou, se a RAM permitir, aumentar ligeiramente o tamanho do heap e reavaliar a regra dos 50%.
Se a GC for executada com muita frequência, mas as pausas forem curtas: Seu heap pode ser um pouco pequeno demais, causando coleções menores excessivas, ou você está criando muitos objetos de curta duração.

Dica sobre Dimensionamento de Shards: O ajuste da JVM funciona melhor quando combinado com estratégias de indexação adequadas. O excesso de shards (muitos shards pequenos) força a JVM a gerenciar um número massivo de objetos em muitas estruturas, aumentando a sobrecarga da GC. Procure shards maiores (por exemplo, 10 GB a 50 GB) para reduzir a sobrecarga por nó.

Como a Pressão do Heap se Parece em Clusters Reais

A pressão do heap raramente se anuncia como "pressão do heap" para a pessoa de plantão. Ela se manifesta como picos de latência de pesquisa, rejeições de indexação, atualizações lentas do estado do cluster, nós saindo e reentrando, ou painéis que parecem bons até o tráfego atingir o pico. O sinal útil é se o heap da JVM aumenta, a coleta de lixo é executada e o heap retorna a um nível saudável depois.

Se o heap aumenta durante um período movimentado e depois cai após a coleta de lixo, o nó pode estar simplesmente trabalhando duro. Se o heap aumenta e permanece alto após as coleções da geração antiga, você pode ter pressão sustentada. Se longas pausas de GC coincidirem com desconexões de nós, eleições de mestre ou timeouts de cliente, o comportamento da JVM provavelmente faz parte do incidente.

Use as estatísticas de nó do Elasticsearch para verificar o comportamento da JVM:

curl -s "http://localhost:9200/_nodes/stats/jvm,indices,thread_pool?pretty"

Observe a porcentagem de heap usada, contagem e tempo de coleta de lixo, memória fielddata, cache de solicitação, cache de consulta, pressão de indexação e tarefas de pool de threads rejeitadas. Uma única métrica pode enganar você. Por exemplo, heap alto sem tarefas rejeitadas pode ser menos urgente do que heap moderado com rejeições de pesquisa e longas pausas da geração antiga.

A Regra dos 50% Tem um Motivo

O conselho comum de manter o heap do Elasticsearch em ou abaixo de cerca de metade da RAM do sistema não é arbitrário. O Lucene lê arquivos de índice do disco, e o cache de página do sistema operacional torna as leituras repetidas muito mais rápidas. Se você der quase toda a memória para a JVM, o heap pode parecer generoso enquanto o desempenho da pesquisa piora porque o SO não pode armazenar em cache segmentos quentes de forma eficaz.

Em um nó de 64 GB, um heap em torno de 30 GB ou 31 GB é um teto comum. Em um nó de 16 GB, 8 GB pode ser um ponto de partida. Em um nó de desenvolvimento minúsculo, o Elasticsearch pode ser executado com muito menos. O valor certo depende da carga de trabalho, versão e função do nó. Nós dedicados elegíveis a mestre geralmente precisam de muito menos heap do que nós de dados quentes. Nós somente de coordenação podem precisar de heap significativo se distribuírem pesquisas grandes e mesclarem grandes respostas.

Não aumente o heap só porque o heap está alto às vezes. Primeiro pergunte o que o está usando. Muitos shards, agregações caras, fielddata grande, solicitações em massa grandes, janelas de resultados de pesquisa enormes e estado de cluster pesado podem todos empurrar o heap para cima. Aumentar o heap pode atrasar o sintoma enquanto o design subjacente continua piorando.

Ponteiros de Objeto Compactados e a Armadilha dos 32 GB

Muitas implantações Java evitam heaps acima de aproximadamente 32 GB porque a JVM pode perder ponteiros de objeto comuns compactados, muitas vezes chamados de compressed oops. Quando isso acontece, as referências de objeto podem ocupar mais memória, e o heap extra pode não comprar tanto espaço utilizável quanto o esperado. O ponto de corte exato pode variar, então verifique os logs de inicialização em vez de tratar 32 GB como um número mágico.

O Elasticsearch registra a ergonomia da JVM durante a inicialização. Se você estiver perto do limite, confirme se os compressed oops estão ativados. Um heap de 31g é frequentemente escolhido para ficar abaixo da linha com alguma margem de segurança. Se um nó realmente precisa de muito mais memória, pode ser melhor adicionar nós, reduzir a pressão de shard ou dividir funções em vez de criar um heap gigante com comportamento doloroso de GC.

Shards, Mapeamentos e Consultas Podem Criar Problemas na JVM

O ajuste da JVM não pode salvar um cluster de contagens excessivas de shards. Cada shard tem sobrecarga: estruturas de dados, metadados de segmento, caches, coordenação de pesquisa e trabalho de recuperação. Milhares de shards minúsculos podem consumir heap e desacelerar as operações do cluster, mesmo quando cada shard contém muito poucos dados. Se o seu problema de heap apareceu após adicionar muitos índices diários, a correção pode ser o gerenciamento do ciclo de vida do índice e a consolidação de shards, não uma flag de GC.

Mapeamentos também importam. Campos de texto, campos de palavra-chave, doc values, fielddata, documentos aninhados e campos de tempo de execução têm comportamento de memória diferente. Ativar fielddata em grandes campos de texto pode ser especialmente caro. Se o heap saltar durante as agregações, verifique se os usuários estão agregando em campos que não foram projetados para isso.

Consultas podem criar explosões de uso de memória. Paginação profunda com grandes valores from, consultas curinga amplas, agregações de alta cardinalidade e grandes tamanhos de resultado colocam pressão nos nós de coordenação e dados. Use search_after, pesquisas point-in-time, filtros mais restritos e agregações bem projetadas onde elas se encaixam. Uma consulta que parece inofensiva no desenvolvimento pode prejudicar muito quando executada em centenas de shards.

Indexação em Massa e Heap

A indexação em massa é outra fonte comum de confusão. Solicitações em massa maiores podem melhorar a taxa de transferência até certo ponto, mas solicitações superdimensionadas consomem memória, aumentam o tempo de fila e tornam as novas tentativas mais caras. Se você vir pressão de indexação, rejeições do pool de threads de gravação ou picos de GC durante a ingestão, reduza o tamanho da solicitação em massa ou a simultaneidade antes de alterar as flags da JVM.

Uma abordagem prática é testar tamanhos de lote com documentos semelhantes aos de produção. Comece modestamente, aumente até que a taxa de transferência pare de melhorar e depois recue. Observe CPU, heap, GC, I/O de disco, atividade de mesclagem e contagens de rejeição. Se o nó estiver gastando a maior parte do tempo mesclando segmentos ou esperando no disco, o ajuste do heap não corrigirá o gargalo de ingestão.

O intervalo de atualização também afeta o comportamento de indexação. Para ingestão pesada onde a pesquisa quase em tempo real não é necessária, aumentar refresh_interval pode reduzir a rotatividade de segmentos. Essa é uma configuração de índice, não ajuste da JVM, mas muitas vezes melhora os sintomas que as pessoas atribuem à JVM.

Limites de Memória em Contêineres

O Elasticsearch em contêineres precisa de atenção especial porque a JVM vê os limites do contêiner de forma diferente, dependendo da versão do Java e da configuração. Se o contêiner tem um limite de memória de 4 GB e você define um heap de 4 GB, o processo ainda pode ser morto porque a memória off-heap, pilhas de threads, memória nativa e cache do sistema de arquivos também precisam de espaço.

Defina o heap em relação ao limite de memória do contêiner, não à memória do host. Deixe espaço para memória não heap. Observe eventos OOMKilled no Kubernetes ou logs de tempo de execução do contêiner. Um pod que desaparece sem um erro limpo do Elasticsearch pode ter sido morto pela plataforma em vez de travar dentro do Java.

Para Kubernetes, solicitações e limites devem refletir o perfil de memória real. Um limite muito próximo do heap convida mortes por OOM. Uma solicitação muito baixa pode colocar o pod em um nó onde ele compete pesadamente com outras cargas de trabalho. O Elasticsearch se beneficia mais de memória previsível e I/O de disco do que de overcommit oportunista.

Quando Alterar as Configurações de GC

A maioria dos operadores deve evitar experimentos com coletores. O Elasticsearch testa e fornece configurações de JVM suportadas para cada versão. Adicionar aleatoriamente flags antigas de CMS, metas de pausa agressivas ou pacotes de ajuste copiados pode impedir a inicialização ou piorar o comportamento.

Altere as configurações de GC somente depois que você puder descrever o problema nos logs: pausas antigas de GC são muito longas, a GC jovem é muito frequente, o heap não se recupera ou eventos de pausa coincidem com instabilidade do cluster. Mesmo assim, prefira pequenas alterações e mantenha um caminho de reversão. As flags da JVM fazem parte da configuração de produção e devem passar pela mesma revisão que as alterações de alocação de shard ou segurança.

Se você alterar uma meta de pausa como MaxGCPauseMillis, lembre-se de que é uma meta, não uma promessa. A JVM pode não cumpri-la sob pressão pesada de alocação. Se o aplicativo criar muitos objetos muito rapidamente, o coletor não pode transformar isso em desempenho gratuito.

Uma Lista de Verificação Curta de Incidentes

Quando a latência do Elasticsearch dispara e a JVM é suspeita, eu verificaria estas coisas em ordem:

Um ou dois nós estão não saudáveis, ou todo o cluster está afetado?
O uso do heap aumentou ao mesmo tempo que a latência?
Ocorreram pausas de GC da geração antiga e quanto tempo duraram?
Os pools de threads de pesquisa ou gravação estão rejeitando trabalho?
A taxa de indexação, o tamanho do lote ou o volume de consultas mudaram?
A contagem de shards, contagem de segmentos ou tamanho do estado do cluster cresceu recentemente?
A latência de I/O do disco está alta?
Uma implantação, alteração de mapeamento ou nova consulta de painel começou por volta do mesmo horário?

Essa lista de verificação mantém a investigação fundamentada. O ajuste da JVM é uma alavanca, mas é uma alavanca entre várias.

A Conclusão Prática

Configurações adequadas da JVM ajudam o Elasticsearch a permanecer estável, mas a maioria dos ganhos vem de dimensionar o heap com cuidado, deixar espaço para o cache do sistema de arquivos, observar o comportamento real da GC e corrigir problemas de shard ou consulta que criam pressão de memória em primeiro lugar. Mantenha -Xms e -Xmx iguais, seja conservador perto do limite de compressed oops, confie nos padrões da versão até que as evidências digam o contrário e trate os logs de GC como evidência operacional, não como decoração.