Como solucionar os picos de latência de pesquisa em meu cluster do Amazon OpenSearch Service?

Última atualização: 05/08/2021

Estou enfrentando picos de latência de pesquisa em meu cluster do Amazon OpenSearch Service (sucessor do Amazon Elasticsearch Service). Como posso solucionar problemas e resolver picos de latência de pesquisa?

Breve descrição

Para solicitações de pesquisa, o tempo de ida e volta é calculado da seguinte forma:

Round trip = Time the query spends in the query phase + time in the fetch phase + time spent in the queue + network latency

A métrica SearchLatency no Amazon CloudWatch informa o tempo que a consulta passou na fase de consulta.

Há várias etapas de solução de problemas que você pode seguir para solucionar problemas de pesquisa de picos de latência no cluster do OpenSearch Service, incluindo:

  • Conferir se os recursos provisionados no cluster são insuficientes
  • Confira se há rejeições de pesquisa usando a métrica ThreadpoolSearchRejected no CloudWatch
  • Usar logs lentos de pesquisa e a API de perfil
  • Resolver quaisquer erros 504 GatewayTimeout

Resolução

Conferir se os recursos provisionados no cluster são insuficientes

Você pode experimentar picos de latência de pesquisa se tiver recursos insuficientes provisionados no cluster. Use as práticas recomendadas a seguir para garantir que você tenha recursos suficientes provisionados.

1.    Analise a métrica CPUUtilization e a pressão JVMMemory do cluster usando o Amazon CloudWatch para confirmar se elas estão dentro dos limites recomendados. Para obter mais informações, consulte Alarmes recomendados do CloudWatch.

2.    Use a API Node Stats para obter estatísticas em nível de nó em seu cluster:

GET /_nodes/stats

Nos resultados, confira as seguintes seções: caches, fielddata e jvm. Execute essa API várias vezes com algum atraso para comparar os resultados.

3.    O OpenSearch Service usa o cache do sistema de arquivos para fazer solicitações de pesquisa mais rápidas. Analise o resultado da API NodeStats para ver se há remoções de cache. Um grande número de remoções de cache nos resultados significa que o tamanho do cache é inadequado para atender à solicitação. Nesse caso, considere usar nós maiores com mais memória.

4.    A execução de agregações em campos que contêm valores altamente exclusivos pode causar um aumento no uso de heap. Se as consultas de agregação já estiverem em uso, as operações de pesquisa usarão FieldData. O FieldData também é usado para classificar e acessar os valores de campo no script. As remoções de FieldData dependem do tamanho do arquivo indices.fielddata.cache.size, e isso representa 20% do espaço de heap de JVM. As remoções iniciam quando o cache é excedido.

Para obter mais informações sobre como solucionar problemas de memória da JVM alta, consulte Como solucionar problemas de alta pressão de memória da JVM em meu cluster do Amazon OpenSearch Service?

Para solucionar problemas de alta utilização da CPU, consulte Como solucionar problemas de alta utilização da CPU em meu cluster do Amazon OpenSearch Service?

Confira se há rejeições de pesquisa usando a métrica ThreadpoolSearchRejected no CloudWatch

Para conferir se há rejeições de pesquisa usando o CloudWatch, siga as etapas em Como solucionar rejeições de pesquisa ou de gravação no Amazon OpenSearch Service?

Use logs de pesquisa lentos para identificar consultas de longa duração

Use logs lentos para identificar consultas de longa duração e o tempo gasto por uma consulta em um fragmento específico. Você pode definir limiares para a fase de consulta e, em seguida, buscar a fase para cada índice. Para obter mais informações sobre como configurar logs lentos, consulte Visualização de logs lentos do Amazon OpenSearch Service. Certifique-se de definir“profile” :true para sua consulta de pesquisa para obter um detalhamento do tempo gasto pela consulta na fase de consulta.

Observação: se você definir o limiar para registro em log com um valor muito baixo, a pressão da memória JVM poderá aumentar. Isso pode levar a uma coleta de resíduos mais frequente, o que aumenta a utilização da CPU e adiciona latência ao cluster. Registar mais consultas também pode aumentar seus custos. O resultado da API profile pode ser longo, adicionando uma sobrecarga significativa a qualquer consulta de pesquisa.

Solucione quaisquer erros 504 Gateway Timeout

Nos logs de aplicações do cluster do OpenSearch Service, você pode ver códigos de erro HTTP específicos para solicitações individuais. Para obter mais informações sobre como resolver erros HTTP 504 Gateway Timeout, consulte Como evitar erros HTTP 504 Gateway Timeout no Amazon OpenSearch Service?

Observação: você deve habilitar os logs de erros para identificar códigos de erro HTTP específicos. Para obter mais informações sobre códigos de erro HTTP, consulte Exibir logs de erros do Amazon OpenSearch Service.

Outros fatores que podem causar alta latência de pesquisa

Existem vários outros fatores que podem causar alta latência de pesquisa. Use as dicas a seguir para solucionar problemas de alta latência de pesquisa:

  • A atividade de coleta de resíduos frequente ou prolongada pode causar problemas na performance de pesquisa. A atividade de coleta de resíduos pode pausar threads e aumentar a latência da pesquisa. Para obter informações adicionais, consulte Gerenciar o heap gerenciado do Elasticsearch no site do Elasticsearch.
  • As IOPS provisionadas (ou instâncias i3) podem ajudar você a remover gargalos do Amazon Elastic Block Store (Amazon EBS). Na maioria dos casos, você não precisará deles. É uma prática recomendada testar a performance entre os nós i3 e os nós r5 antes de passar diretamente para o i3.
  • Um cluster com muitos fragmentos pode causar um aumento na utilização de recursos, mesmo quando o cluster estiver inativo. Muitos fragmentos diminuem a performance da consulta. Embora aumentar a contagem de fragmentos de réplica possa ajudá-lo a obter pesquisas mais rápidas, verifique se você não está indo além de 1000 fragmentos em um determinado nó. Além disso, verifique se os tamanhos dos fragmento estão entre 10 GiB e 50 GiB. Idealmente, o número máximo de fragmentos em um nó deve ser heap * 20.
  • Muitos segmentos ou muitos documentos excluídos podem afetar a performance da pesquisa. Usar mesclagem forçada em índices somente leitura pode ajudar nesse caso. Se o caso de uso permitir, aumente a atualização interna nos índices ativos. Para obter mais informações, consulte Tratar documentos excluídos do Lucene no site do Elasticsearch.
  • Se o cluster estiver em uma VPC, considere executar suas aplicações na mesma VPC.
  • Considere usar nós UltraWarm ou nós de dados ativos para dados somente leitura. O armazenamento quente fornece a performance mais rápida possível para indexação e pesquisa de novos dados. No entanto, os nós UltraWarm são uma maneira econômica de armazenar grandes quantidades de dados somente leitura em seu cluster. Para índices nos quais você não está gravando ativamente e não precisa da mesma performance, o UltraWarm oferece custos significativamente mais baixos por GiB de dados.
  • Teste sua workload para ver se ela se beneficia de ter os dados que você está procurando disponíveis em todos os nós. Algumas aplicações se beneficiam dessa abordagem, especialmente se houver poucos índices no cluster. Para fazer isso, aumente o número de fragmentos de réplica. Lembre-se de que isso pode aumentar a latência de indexação. Além disso, você pode precisar de armazenamento adicional do Amazon EBS para acomodar as réplicas que você está adicionando. Isso aumentará os custos de volume do EBS.
  • Pesquisar o menor número possível de campos, evita scripts e consultas curinga. Para obter mais informações, consulte Ajuste da velocidade de pesquisa no site do Elasticsearch.
  • Para índices com muitos fragmentos, você pode usar o roteamento personalizado para ajudar a acelerar as pesquisas. O roteamento personalizado garante que apenas os fragmentos que comportam seus dados sejam consultados, em vez de transmitir a solicitação para todos os fragmentos do índice. Para obter mais informações, consulte Personalizar o roteamento de documentos no site do Elasticsearch.

Este artigo ajudou?


Precisa de ajuda com faturamento ou suporte técnico?