Solucionando Gargalos Comuns de Performance no Elasticsearch

Solucionar gargalos de performance no Elasticsearch funciona melhor quando você resiste à primeira teoria fácil. Um dashboard lento pode ser uma consulta ruim, mas também pode ser um shard quente, um disco saturado, um problema de heap, um erro de mapeamento ou um processo de recuperação competindo por I/O. Comece com evidências e depois reduza o escopo.

Geralmente divido a questão em três partes: o que está lento, onde está lento e o que mudou. "O Elasticsearch está lento" não é acionável. "A latência de busca para logs-prod-* dobrou após a mudança de mapeamento de ontem, principalmente em dois nós de dados" dá a você um ponto de partida.

Diagnosticando Problemas de Performance

Antes de mergulhar em soluções específicas, é essencial ter ferramentas e métodos para diagnosticar problemas de performance. O Elasticsearch fornece várias APIs e métricas que são inestimáveis para esse processo.

Ferramentas e Métricas Principais:

• API de Saúde do Cluster (_cluster/health): Fornece uma visão geral do status do cluster (verde, amarelo, vermelho), número de nós, shards e tarefas pendentes. Números elevados de tarefas pendentes podem indicar problemas de indexação ou recuperação.
• API de Estatísticas do Nó (_nodes/stats): Oferece estatísticas detalhadas para cada nó, incluindo uso de CPU, memória, I/O de disco, tráfego de rede e uso de heap da JVM. Isso é crítico para identificar nós com recursos limitados.
• API de Estatísticas do Índice (_stats): Fornece estatísticas para índices individuais, como taxas de indexação, taxas de busca e uso de cache. Isso ajuda a identificar índices problemáticos.
• Slow Log: O Elasticsearch pode registrar solicitações lentas de indexação e busca. Os limites do slow log são configurações do índice, então você pode aplicá-los a um índice ruidoso em vez de transformar todo o cluster em um gerador de logs.
  • Slow Log de Indexação: Útil quando as gravações em lote param ou a latência de ingestão aumenta.
  • Slow Log de Busca: Útil quando você precisa do padrão real da solicitação, não apenas de um gráfico de latência.
• Ferramentas de Monitoramento: Soluções como a UI de Monitoramento do Kibana, Prometheus com o Elasticsearch Exporter ou ferramentas APM comerciais fornecem dashboards e dados históricos para análises mais aprofundadas.

Gargalos Comuns e Soluções

1. Indexação Lenta

A indexação lenta pode ser causada por vários fatores, incluindo latência de rede, gargalos de I/O de disco, recursos insuficientes, mapeamento ineficiente ou uso abaixo do ideal da API Bulk.

Causas e Soluções:

• Saturação de I/O de Disco: O Elasticsearch depende fortemente de I/O de disco rápido para indexação. SSDs são altamente recomendados.

  • Diagnóstico: Monitore IOPS de leitura/gravação e throughput usando _nodes/stats ou ferramentas de nível de SO. Procure por profundidades de fila altas.
  • Solução: Atualize para armazenamento mais rápido (SSDs), distribua shards por mais nós ou otimize sua estratégia de shards para reduzir I/O por nó.

• Pressão no Heap da JVM: Se o heap da JVM está constantemente sob pressão, a coleta de lixo pode se tornar um gargalo significativo, desacelerando todas as operações, incluindo a indexação.

  • Diagnóstico: Monitore o uso do heap da JVM no Monitoramento do Kibana ou em _nodes/stats. Uso elevado de heap e pausas frequentes e longas de coleta de lixo são bandeiras vermelhas.
  • Solução: Aumente o tamanho do heap da JVM (mas não além de 50% da RAM do sistema e não excedendo 30,5 GB), otimize mapeamentos para reduzir o tamanho do documento ou adicione mais nós para distribuir a carga.

• Mapeamento Ineficiente: Mapeamentos excessivamente complexos, mapeamento dinâmico com muitos novos campos sendo criados ou tipos de dados incorretos podem aumentar a sobrecarga de indexação.

  • Diagnóstico: Analise os mapeamentos do índice (API _mapping). Procure por objetos aninhados, grandes números de campos ou campos indexados desnecessariamente.
  • Solução: Defina mapeamentos explícitos com tipos de dados apropriados. Use dynamic: false ou dynamic: strict quando aplicável. Evite estruturas profundamente aninhadas se não forem essenciais.

• Latência de Rede: Alta latência entre nós ou entre clientes e o cluster pode desacelerar solicitações de indexação em lote.

  • Diagnóstico: Meça a latência de rede entre seus clientes/nós. Analise os tempos de resposta da API Bulk.
  • Solução: Mantenha os nós do cluster em uma rede privada de baixa latência, coloque clientes bulk próximos ao cluster quando possível e reduza o tráfego desnecessário entre regiões. As configurações de cache de solicitação não corrigirão a latência de rede.

• Uso Abaixo do Ideal da API Bulk: Enviar solicitações individuais em vez de usar solicitações em lote, ou enviar solicitações em lote excessivamente grandes/pequenas, pode ser ineficiente.

  • Diagnóstico: Monitore o throughput da sua indexação em lote. Analise o tamanho das suas solicitações em lote.
  • Solução: Use a API Bulk para todas as operações de indexação. Experimente com o tamanho do lote (tipicamente 5-15 MB por solicitação em lote é um bom ponto de partida) para encontrar o equilíbrio ideal entre throughput e latência. Certifique-se de que suas solicitações em lote estejam devidamente agrupadas.

• Durabilidade do Translog: A configuração index.translog.durability controla com que frequência o log de transações é liberado para o disco. request (padrão) é mais seguro, mas pode impactar a performance em comparação com async.

  • Diagnóstico: Esta é uma configuração.
  • Solução: Para throughput máximo de indexação, considere a durabilidade async. No entanto, esteja ciente de que isso aumenta o risco de perda de dados em caso de falha do nó entre as liberações.

2. Consultas Lentas

A performance das consultas é influenciada pelo tamanho do shard, complexidade da consulta, cache e eficiência da estrutura de dados subjacente.

Causas e Soluções:

• Shards Grandes: Shards muito grandes podem desacelerar as consultas, pois o Elasticsearch precisa pesquisar mais dados e mesclar resultados de mais segmentos.

  • Diagnóstico: Verifique os tamanhos dos shards usando _cat/shards ou _all/settings?pretty.
  • Solução: Mire em tamanhos de shard entre 10GB e 50GB. Considere reindexar dados em um novo índice com shards menores ou usar o Index Lifecycle Management (ILM) para gerenciar o tamanho do shard ao longo do tempo.

• Muitos Shards: Ter um número excessivo de shards pequenos pode levar a alta sobrecarga para o cluster, especialmente durante as buscas. Cada shard requer recursos para gerenciamento.

  • Diagnóstico: Conte o número total de shards por nó e por índice usando _cat/shards.
  • Solução: Consolide índices se possível. Otimize seu modelo de dados para reduzir o número de índices e, portanto, o número total de shards. Para dados de série temporal, o ILM pode ajudar a gerenciar a contagem de shards.

• Consultas Ineficientes: Consultas complexas, consultas que envolvem scripts pesados, pesquisas curinga no início dos termos ou expressões regulares podem consumir muitos recursos.

  • Diagnóstico: Use a API Profile (_search?profile=true) para analisar o tempo de execução da consulta e identificar partes lentas. Analise os slow logs.
  • Solução: Simplifique as consultas. Evite curingas iniciais e regex caros. Use consultas term em vez de match para correspondências exatas quando possível. Considere usar sugestores search_as_you_type ou completion para sugestões de digitação. Otimize cláusulas de filtro (use o contexto filter em vez do contexto query para consultas sem pontuação).

• Falta de Cache: Cache insuficiente ou ineficaz pode levar a cálculos repetidos e recuperação de dados.

  • Diagnóstico: Monitore as taxas de acerto do cache para o cache de consulta e cache de solicitação usando _nodes/stats/indices/query_cache e _nodes/stats/indices/request_cache.
  • Solução: Certifique-se de que o cache apropriado esteja ativado. O cache de filtro (parte do cache de consulta) é particularmente importante para consultas de filtro repetidas. Para consultas idênticas executadas com frequência, considere ativar o cache de solicitação.

• Sobrecarga de Mesclagem de Segmentos: O Elasticsearch mescla segmentos menores em maiores em segundo plano. Este processo consome recursos de I/O e CPU, o que às vezes pode impactar a performance de consultas em tempo real.

  • Diagnóstico: Monitore o número de segmentos por shard usando _cat/segments.
  • Solução: Evite alterar as configurações de mesclagem casualmente. Durante um grande backfill, reduza a frequência de atualização, controle a concorrência em lote e observe a limitação de mesclagem e I/O de disco. Force merges são geralmente para índices somente leitura, não para índices quentes ativos.

3. Contenção de Recursos (CPU, Memória, Rede)

A contenção de recursos é uma categoria ampla que pode se manifestar tanto na degradação da performance de indexação quanto de consulta.

Causas e Soluções:

• Sobrecarga de CPU: O alto uso de CPU pode ser causado por consultas complexas, agregações intensivas, muitas operações de indexação ou coleta de lixo excessiva.

  • Diagnóstico: Monitore o uso de CPU por nó (_nodes/stats). Identifique quais operações estão consumindo mais CPU (por exemplo, busca, indexação, GC da JVM).
  • Solução: Otimize consultas e agregações. Distribua a carga por mais nós. Reduza a taxa de indexação se estiver sobrecarregando a CPU. Certifique-se de que as configurações de heap da JVM sejam adequadas para minimizar a sobrecarga de GC.

• Problemas de Memória (Heap da JVM e Memória do Sistema): Heap insuficiente da JVM leva a GC frequente. Ficar sem memória do sistema pode causar swapping, reduzindo drasticamente a performance.

  • Diagnóstico: Monitore o uso do heap da JVM e a memória total do sistema (RAM, swap) em cada nó.
  • Solução: Aloque heap suficiente da JVM (por exemplo, 50% da RAM do sistema, até 30,5 GB). Evite swapping garantindo memória livre do sistema suficiente. Considere adicionar mais nós ou usar nós dedicados para funções específicas (master, data, ingest).

• Gargalos de Rede: O alto tráfego de rede pode desacelerar a comunicação entre nós, a replicação e as solicitações dos clientes.

  • Diagnóstico: Monitore o uso de largura de banda de rede e a latência entre nós e clientes.
  • Solução: Otimize a infraestrutura de rede. Reduza a transferência de dados desnecessária. Certifique-se de que as configurações de alocação e replicação de shards sejam ideais.

• Saturação de I/O de Disco: Como mencionado na indexação, isso também impacta a performance de consultas ao ler dados do disco.

  • Diagnóstico: Monitore as métricas de I/O de disco.
  • Solução: Atualize para armazenamento mais rápido, distribua dados por mais nós ou otimize consultas para reduzir a quantidade de dados lidos.

Melhores Práticas para Ajuste de Performance

• Monitore Continuamente: O ajuste de performance é um processo contínuo. Monitore regularmente a saúde do seu cluster e a utilização de recursos.
• Otimize Mapeamentos: Defina mapeamentos explícitos e eficientes adaptados aos seus dados. Evite campos ou indexação desnecessários.
• Estratégia de Shards: Mire em tamanhos de shard ideais (10-50 GB) e evite ter muitos ou poucos shards.
• Use a API Bulk: Use a API Bulk para indexação e a API multi-search quando precisar agrupar buscas independentes.
• Ajuste o Heap da JVM: Aloque heap suficiente, mas não aloque em excesso. Evite swapping.
• Entenda a Performance de Consultas: Perfile consultas, simplifique-as e aproveite o contexto de filtro.
• Aproveite o Cache: Certifique-se de que os caches de consulta e solicitação sejam usados de forma eficaz.
• Hardware: Use SSDs para armazenamento e garanta CPU e RAM adequadas.
• Nós Dedicados: Considere usar nós dedicados para funções de master, data e ingest para isolar cargas de trabalho.
• Index Lifecycle Management (ILM): Para dados de série temporal, o ILM é essencial para gerenciar índices, fazer rollover de shards e eventualmente excluir dados antigos, o que ajuda a controlar a contagem e o tamanho dos shards.

Quando você encontrar um gargalo, faça a menor mudança que o aborde diretamente. Adicione nós quando o cluster estiver genuinamente sem capacidade. Corrija mapeamentos quando o heap estiver sendo desperdiçado. Reescreva consultas quando a saída do perfil apontar para cláusulas caras. Ajuste a estratégia de shards quando um nó estiver fazendo trabalho que deveria ser distribuído. Essa disciplina impede que o trabalho de performance se torne uma pilha de botões de ajuste não relacionados.