Como gerenciar e solucionar problemas de memória do Elasticsearch

Com o Elastic Cloud oferecendo soluções como Observability, Security, e busca, ampliamos o número de usuários que utilizam o Elastic Cloud além das equipes completas de operações, incluindo engenheiros de dados, equipes de segurança e consultores. Como representante de suporte da Elastic, gostei de interagir com uma ampla variedade de usuários e casos de uso.

Com um público maior, estou vendo mais perguntas sobre como gerenciar a alocação de recursos, em particular solucionar problemas de integridade da alocação e evitar disjuntores. Eu entendo! Quando comecei com o Elasticsearch, eu tinha as mesmas perguntas. Foi minha primeira introdução ao gerenciamento de heap Java e shards de banco de dados de séries temporais e ao redimensionamento de minha própria infraestrutura.

Quando entrei na Elastic, adorei que, além da documentação, tínhamos blogs e tutoriais para que eu pudesse me integrar rapidamente. Mas eu sofri no primeiro mês para correlacionar meu conhecimento teórico com os erros que os usuários enviavam pela minha fila de tíquetes. Por fim, descobri, como outros representantes de suporte, que muitos dos erros relatados eram apenas sintomas de problemas de alocação e que os mesmos sete links ajudariam os usuários a gerenciar sua alocação de recursos com sucesso.

Falando como representante de suporte, vou examinar os principais links da teoria de gerenciamento de alocação que enviamos aos usuários, os principais sintomas que vemos e para onde direcionamos os usuários a atualizar suas configurações para resolver seus problemas de alocação de recursos.

2. Como variável do ambiente Elasticsearch no seu docker-compose:

3. Via nosso Elastic Cloud Hosted > Implantação > Editar visualização. Nota: o menu suspenso atribui memória física e aproximadamente metade será alocada para o heap.

Se você está enfrentando problemas de desempenho com seu cluster, provavelmente trata-se dos suspeitos de sempre:

• Problemas de configuração: nós master subdimensionados, sem políticas ILM
• Volume induzido: alta velocidade e carga de solicitações, sobreposição de consultas/escritas custosas

E para: _cluster/health.

Se algum shard relatar >0 fora de active_shards ou active_primary_shards, você identificou uma causa de problemas de desempenho.

Na maioria das vezes, se isso reportar um problema, será unassigned_shards>0. Se esses shards forem primários, seu cluster reportará como status:red, e se for apenas réplica, reportará como status:yellow. (é por isso configurar réplicas nos índices é importante — se o cluster encontrar um problema, ele pode se recuperar em vez de sofrer perda de dados.) Vamos supor que temos um status:yellow com um único shard não atribuído. Para investigar, daríamos uma olhada em qual shard de índice está tendo problemas via _cat/shards.

Então, isso será para nossos logs de índice que não são do sistema, que têm um shard de réplica não atribuído. Vamos ver o que está causando problemas executando _cluster/allocation/explain. (Dica profissional: quando você encaminha o suporte, é exatamente isso que fazemos.)

GET _cluster/allocation/explain?pretty&filter_path=index,node_allocation_decisions.node_name,node_allocation_decisions.deciders.*

Essa mensagem de erro aponta para data_hot, que faz parte de uma política de gestão de ciclo de vida do índice (ILM) e indica que nossa política de ILM é incongruente com as configurações atuais do índice. Nesse caso, a causa desse erro é a configuração de uma política ILM hot-warm sem ter nós quentes designados. (Eu precisava garantir que algo falharia, então estou forçando exemplos de erro para vocês. Para mais informações, veja este vídeo de resolução de problemas de exemplo para guia de resolução.)

Se você executar esse comando sem shards não atribuídos, vai receber um erro 400 dizendo que não consegue encontrar shards não atribuídos para explicar porque não há nada errado pararelatório.Se tiver uma causa não lógica (por exemplo, um erro temporário de rede, como node saiu do cluster durante a alocação), você pode usar o _cluster/reroute da Elastic.

Esta solicitação sem personalizações inicia um processo assíncrono em segundo plano que tenta alocar todos os shards com estado: não atribuídos. (Não faça como eu e não espere a conclusão do processo antes de contatar a equipe de desenvolvimento, pois achei que seria instantâneo e, coincidentemente, o problema foi escalado justamente quando eles disseram que não havia nada de errado, porque, na verdade, não havia mais nada.) Para obter mais informações, consulte este vídeo de solução de problemas para monitorar a saúde da alocação.

Para investigar, dê uma olhada em seu heap.percent, seja examinando _cat/nodes:

Ou, se você já ativou antes, navegue até o Kibana > Stack Monitoring.

Se você confirmou que está atingindo seus circuit breakers de memória, considere aumentar a heap temporariamente para ter espaço para investigar. Ao investigar a causa raiz, procure em seu logging de auditoria, logging lento, clusterlogs ou elasticsearch.log pelos eventos consecutivos anteriores. Você vai procurar:

• Consultas caras, especialmente:
  • Altas agregações de bucket
    • Eu me senti muito bobo quando descobri que as buscas alocam temporariamente uma determinada parte da sua heap antes de executarem a consulta com base no tamanho da busca ou nas dimensões do bucket, então definir 10.000.000 estava realmente dando uma dor de cabeça na minha equipe de operações.
  • mapeamentos não otimizados
    • A segunda razão para me sentir boba foi quando pensei que fazer relatórios hierárquicos faria buscas melhores do que dados nivelados (não é o caso).
• Volume/ritmo de solicitação: geralmente consultas em lote ou assíncronas

Ou você pode calcular a partir de _nodes/stats:

Onde:

Um possível sintoma disso é a alta frequência e a longa duração dos eventos do coletor de lixo (gc) em seu elasticsearch.log:

Se você confirmar esse cenário, precisará pensar em redimensionar seu cluster ou reduzir as demandas que o atingem. Convém investigar/considerar:

• Aumento dos recursos de heap (heap/nó, número de nós)
• Redução dos shards (excluir dados desnecessários/antigos; use o ILM para colocar dados em armazenamento warm/cold para que você possa encolhê-los; desative réplicas para dados que você não se importa em perder)

Publicado originalmente em 27 de abril de 2021; atualizado em 5 de novembro de 2024.

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.