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

Breve descrição

Para solicitações de pesquisa, o OpenSearch Service calcula o tempo de ida e volta da seguinte forma:

Ida e volta = Tempo gasto pela consulta na fase de consulta + Tempo na fase de busca + Tempo gasto na fila + Latência de rede

A métrica SearchLatency no Amazon CloudWatch fornece o tempo gasto pela consulta na fase de consulta.

Para solucionar picos de latência de pesquisa no seu cluster do OpenSearch Service, há várias etapas que você pode seguir:

• Verificar se há recursos insuficientes provisionados no cluster
• Verificar as rejeições de pesquisa usando a métrica ThreadpoolSearchRejected no CloudWatch
• Usar a API de logs lentos de pesquisa e a API de perfil
• Resolver qualquer erro de tempo limite do gateway 504

Resolução

Verificar se há recursos insuficientes provisionados no cluster

Se você não tiver recursos suficientes provisionados no seu cluster, poderá experimentar picos de latência de pesquisa. 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 de JVMMemory do cluster usando o CloudWatch. Confirme se elas estão dentro dos limites recomendados. Para mais informações, consulte Recommended CloudWatch alarms for Amazon OpenSearch Service (Alarmes recomendados do CloudWatch para o Amazon OpenSearch Service).

2.    Use a API node stats para obter estatísticas em nível de nó no seu cluster:

GET /_nodes/stats

Na saída, verifique as seguintes seções: caches, fielddata e jvm. Para comparar as saídas, execute essa API várias vezes com um certo atraso entre cada saída.

3.    O OpenSearch Service usa vários caches para melhorar seu desempenho e o tempo de resposta das solicitações:

• O cache do sistema de arquivos, ou o cache de páginas, que existe no nível do sistema operacional
• O cache de solicitações em nível de fragmentos e o cache de consulta existentes no nível do OpenSearch Service

Analise a saída da API node stats para detectar remoções de cache. Um grande número de remoções de cache na saída significa que o tamanho do cache é inadequado para atender à solicitação. Para reduzir as remoções, use nós maiores com mais memória.

Para visualizar informações específicas do cache com a API node stats, use as solicitações a seguir. A segunda solicitação é para um cache de solicitação em nível de fragmento:

GET /_nodes/stats/indices/request_cache?human

GET /_nodes/stats/indices/query_cache?human

Para obter mais informações sobre caches do OpenSearch, consulte Elasticsearch caching deep dive (Análise aprofundada de caches do Elasticsearch): Aumentar a velocidade da consulta, um cache de cada vez, no site do Elastic.

Para ver as etapas para limpar os vários caches, consulte Clear index or data stream cache (Limpar o cache do índice ou do fluxo de dados) no site do OpenSearch.

4.    A realização de agregações em campos que contêm valores altamente exclusivos pode causar aumento no uso da pilha. Se consultas de agregação já estiverem em uso, as operações de pesquisa usarão dados de campo. Dados de campo também classificam e acessam os valores do campo no script. Remoções de dados de campo dependem do tamanho do arquivo indices.fielddata.cache.size, e isso representa 20% do espaço de pilha da JVM. Quando o cache é excedido, a remoção é iniciada.

Para visualizar o cache de dados de campo, use esta solicitação:

GET /_nodes/stats/indices/fielddata?human

Para mais informações sobre como solucionar problemas de alta memória da JVM, consulte Como solucionar problemas de alta pressão de memória da JVM no 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 no meu cluster do Amazon OpenSearch Service?

Verificar as rejeições de pesquisa usando a métrica ThreadpoolSearchRejected no CloudWatch

Para verificar rejeições de pesquisa usando o CloudWatch, siga as etapas em How do I resolve search or write rejections in Amazon OpenSearch Service? (Como resolver rejeições de pesquisa ou gravação no Amazon OpenSearch Service?)

Usar logs lentos de pesquisa para identificar consultas de longa execução

Use logs lentos para identificar consultas de longa execução e o tempo gasto por uma consulta em um fragmento específico. É possível definir limites para a fase de consulta e, em seguida, obter a fase de cada índice. Para mais informações sobre como configurar logs lentos, consulte How do I resolve search or write rejections in Amazon OpenSearch Service? (Visualizar logs lentos do Amazon Elasticsearch Service). Para uma análise detalhada do tempo gasto pela sua consulta na fase de consulta, defina "profile":true para sua consulta de pesquisa..

Observação: se você definir o limite para registro em log como um valor muito baixo, a pressão da memória da JVM poderá aumentar. Isso talvez leve a uma coleta de lixo mais frequente, o que aumenta a utilização da CPU e a latência do cluster. Registrar mais consultas em log também pode aumentar seus custos. Uma saída longa da API de perfil também adiciona uma sobrecarga significativa a qualquer consulta de pesquisa.

Resolver qualquer erro de tempo limite do gateway 504

Nos logs de aplicação do seu cluster do OpenSearch Service, é possível ver códigos de erro HTTP específicos para solicitações individuais. Para obter mais informações sobre como resolver erros HTTP 504 de tempo limite do gateway, consulte How can I prevent HTTP 504 gateway timeout errors in Amazon OpenSearch Service? (Como posso evitar erros HTTP 504 de tempo limite do gateway no Amazon OpenSearch Service?)

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

Outros fatores que podem causar alta latência de pesquisa

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

• Atividades de coleta de lixo frequentes ou de longa execução podem causar problemas no desempenho das pesquisas. A atividade de coleta de lixo pode pausar os tópicos e aumentar a latência da pesquisa. Para mais informações, consulte Um pilha de problemas: Gerenciar o heap gerenciado do Amazon OpenSearch Service, no site do Elastic.
• IOPS provisionadas (ou instâncias i3) podem ajudar a remover qualquer gargalo do Amazon Elastic Block Store (Amazon EBS). Na maioria dos casos, você não precisa delas. Antes de mover uma instância para i3, é uma prática recomendada testar o desempenho entre os nós i3 e os nós r5.
• Um cluster com muitos fragmentos pode aumentar a utilização de recursos, mesmo quando esse cluster está inativo. Muitos fragmentos diminuem o desempenho da consulta. Embora aumentar a contagem de fragmentos de réplica possa ajudar você a obter pesquisas mais rápidas, não vá além de 1000 fragmentos em um determinado nó. Além disso, certifique-se de que os tamanhos dos fragmentos estejam entre 10 GiB e 50 GiB. O ideal é que o número máximo de fragmentos em um nó seja heap * 20.
• Muitos segmentos ou muitos documentos excluídos podem afetar o desempenho da pesquisa. Para melhorar o desempenho, use a mesclagem forçada em índices somente leitura. Além disso, aumente a atualização interna nos índices ativos, se possível. Para mais informações, consulte Lucene's handling of deleted documents (Tratamento de documentos excluídos pela Lucene), no site do Elastic.
• Se o cluster estiver em uma nuvem privada virtual (VPC), a melhor prática será executar suas aplicações na mesma VPC.
• Use nós UltraWarm ou nós de dados ativos para dados somente leitura. O armazenamento a quente oferece o desempenho mais rápido 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 para leitura no seu cluster. Para índices nos quais você não precisa gravar e que não exigem alto desempenho, o UltraWarm oferece custos significativamente mais baixos por GiB de dados.
• Determine se a sua workload se beneficia com a disponibilidade em todos os nós dos dados que você está procurando. Algumas aplicações se beneficiam dessa abordagem, especialmente quando há poucos índices em seu cluster. Para fazer isso, aumente o número de fragmentos de réplica.
  Observação: 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 adicionadas. Isso aumenta seus custos de volume do EBS.
• Pesquise o mínimo possível de campos e evite consultas com scripts e curingas. Para mais informações, consulte Tune for search speed (Ajustar a velocidade da pesquisas), no site do Elastic.
• Para índices com muitos fragmentos, use o roteamento personalizado para ajudar a acelerar as pesquisas. O roteamento personalizado garante que você consulte somente os fragmentos que contêm seus dados, em vez de transmitir a solicitação para todos os fragmentos. Para mais informações, consulte Customizing your document routing (Personalizar o roteamento de documentos), no site do Elastic.

Informações relacionadas

Alarmes recomendados do CloudWatch para o Amazon OpenSearch Service