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

Breve descrição

Em solicitações de pesquisa, o OpenSearch Service calcula o tempo de ida e volta com a seguinte fórmula:

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 do OpenSearch Service no Amazon CloudWatch mostra o tempo que a consulta passou na fase de consulta.

Para solucionar os picos de latência de pesquisa em seu cluster do OpenSearch Service, realize as seguintes ações:

• Verifique as métricas de infraestrutura, como uso da CPU, uso do disco e memória, tanto para a pressão de memória Java Virtual Machine (JVM) quanto para a coleta de resíduos.
• Verifique se há picos na métrica SearchRate.
• Use a métrica ThreadpoolSearchRejected para verificar se há rejeições de pesquisa.
• Use logs lentos para identificar consultas de longa execução.
• Resolva os erros "504 gateway timeout".
• Otimize sua configuração para reduzir a latência.

Resolução

Verifique as métricas de infraestrutura

A coleta de resíduos frequente e longa nos nós de dados do sistema operacional (SO) ocorre quando o uso de recursos é excessivo. Se você não provisionar recursos suficientes em seu cluster, pode enfrentar picos de latência de pesquisa.

Solucione problemas de uso excessivo de recursos

Certifique-se de que as métricas CPUUtilization e JVMMemoryPressure em seu cluster estejam abaixo de 80%. Se os valores das métricas no CloudWatch forem maiores que 80%, solucione o problema do uso excessivo de CPU ou alta pressão da memória JVM.

Para monitorar proativamente o uso de recursos, configure alarmes do CloudWatch para o Amazon Service OpenSearch.

Para obter estatísticas em nível de nó em seu cluster, execute a seguinte consulta várias vezes a cada 5 minutos:

GET /_nodes/stats

Na saída, procure mudanças significativas nos valores de uso do cache, memória de fielddata e heap da JVM entre as execuções. Valores consistentes significam que a operação está normal. Podem ocorrer picos ou quedas repentinos quando há problemas.

Verifique suas configurações de cache

O OpenSearch Service usa os seguintes caches para melhorar seu desempenho e o tempo de resposta das solicitações:

• O cache do sistema de arquivos, ou cache de página, que existe no nível do sistema operacional
• O cache de solicitação em nível de fragmento e o cache de consulta existentes no nível do OpenSearch Service

Para visualizar as informações do cache do sistema de arquivos, execute a seguinte consulta:

GET /_nodes/stats/indices/request_cache?human

Para visualizar as informações de um cache de solicitação em nível de fragmento, execute a seguinte consulta:

GET /_nodes/stats/indices/query_cache?human

Na saída, verifique se há remoções de cache. Um alto número de remoções de cache significa que o cache está muito pequeno para atender à solicitação. Para reduzir as remoções, use nós maiores com mais memória. Para obter mais informações sobre os preços dos tamanhos dos nós, consulte Preços do Amazon OpenSearch Service. Para obter mais informações sobre caches do OpenSearch, consulte Visão detalhada do armazenamento em cache da Elasticsearch: como aumentar a velocidade de consulta, um cache de cada vez, no site da Elastic.

Para limpar seu cache, consulte Clear cache API (Limpar API do cache) no site do OpenSearch.

Agregações em campos que contêm valores altamente exclusivos podem causar aumento no uso do heap. As operações de pesquisa para consultas de agregação usam fielddata. Fielddata também classificam e acessam os valores do campo no script. Remoções de fielddata dependem do tamanho do arquivo indices.fielddata.cache.size, que representa 20% do espaço de heap da JVM.

Para verificar a quantidade de memória que o fielddata usa em todos os nós do cluster, execute a seguinte consulta:

GET /_nodes/stats/indices/fielddata?human

Verifique se há picos na métrica SearchRate

Várias solicitações de pesquisa em um curto período podem sobrecarregar os recursos de um cluster, causar atrasos no processamento de consulta e tempos de resposta mais lentos para pesquisas individuais. A alta taxa de pesquisa no OpenSearch Service pode causar maior latência de pesquisa. Se a métrica SearchRate aumentar, verifique se os picos ocorrem ao mesmo tempo que os picos de latência de pesquisa. Se os picos ocorrerem ao mesmo tempo, você deve adicionar mais recursos ao seu cluster ou otimizar as consultas para gerenciar a carga de pesquisa.

Verifique se há rejeições de pesquisa

Use a métrica ThreadpoolSearchRejected para identificar e resolver rejeições de pesquisa.

Use logs lentos 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, buscar a fase para cada índice.

Para obter um resumo detalhado do tempo que sua consulta passa na fase de consulta, defina profile como true em sua consulta de pesquisa.

Exemplo de consulta:

GET /my_index/_search
{
  "profile": true,
  "query": {
    "match": {
      "field": "value"
    }
  }
}

Observação: se você definir o limite de registro em log muito baixo, a pressão de memória JVM e a latência do cluster podem aumentar. Ao fazer log de mais consultas, você também aumenta seus custos. Uma saída grande de uma consulta com profile definido como true adiciona sobrecarga a outras consultas de pesquisa. Como resultado, outras pesquisas ficam temporariamente lentas.

Resolver erros "504 gateway timeout"

Pré-requisito: ative logs de erro para identificar códigos de erro HTTP específicos.

Use os logs de aplicação do seu cluster do OpenSearch Service para visualizar códigos de erro HTTP específicos para solicitações individuais. Para resolver erros "HTTP 504 gateway timeout", consulte Como posso evitar erros HTTP 504 de tempo limite de gateway no Amazon OpenSearch Service?

Otimize sua configuração

Gerencie sua atividade de coleta de resíduos

A atividade de coleta de resíduos frequente ou de longa duração pode causar problemas de desempenho de pesquisa, pausar threads e aumentar a latência da pesquisa. Para ver as práticas recomendadas para reduzir o tempo de coleta de resíduos, consulte A heap of trouble: Managing Elasticsearch's managed heap (Uma pilha de problemas: Gerenciando o heap gerenciado da Elasticsearch) no site da Elastic.

Otimize seu armazenamento de instância

Seu tipo de instância do Amazon Elastic Compute Cloud (Amazon EC2) pode usar o armazenamento otimizado do Amazon Elastic Block Store (Amazon EBS) ou volumes de armazenamento de instância. Os volumes de armazenamento de instância podem ajudar a resolver os gargalos de E/S porque oferecem armazenamento anexado diretamente e maiores recursos de IOPS. No entanto, as instâncias otimizadas para Amazon EBS oferecem armazenamento persistente com desempenho consistente. Escolha um tipo de armazenamento que se alinhe aos seus requisitos de configuração com base em E/S, persistência de dados e custos.

Antes de alterar seu tipo de instância, é uma prática recomendada testar o desempenho entre diferentes tipos de instância para verificar se eles atendem aos seus requisitos de workload. Para obter uma lista dos tipos de instância disponíveis do OpenSearch Service, consulte Nível gratuito e Preços de instância sob demanda em Preços do Amazon OpenSearch Service.

Observação: se seu cluster estiver em uma nuvem privada virtual (VPC), é uma prática recomendada executar suas aplicações na mesma VPC.

Simplifique sua configuração de fragmentos e segmentos

Um cluster com muitos fragmentos pode aumentar a utilização de recursos, mesmo quando o cluster está inativo. Muitos fragmentos também deixam o desempenho da consulta mais lento. Embora uma contagem maior de fragmentos de réplica possibilite pesquisas mais rápidas, não use mais de 1.000 fragmentos em um único nó. Além disso, certifique-se de que os tamanhos dos fragmentos estejam entre 10 GiB e 50 GiB. É uma prática recomendada definir o número máximo de fragmentos em um nó em 20 vezes o tamanho do heap. Para obter mais informações sobre como reindexar e alterar sua estratégia de fragmento, consulte Optimize OpenSearch index shard sizes (Otimizar tamanhos de fragmentos de índice do OpenSearch) no site do OpenSearch.

Muitos segmentos ou muitos documentos excluídos também podem afetar o desempenho da pesquisa. Para melhorar o desempenho, use a mesclagem forçada em índices somente para leitura e aumente o intervalo de atualização em índices ativos. Para obter mais informações, consulte Force merge API (API de mesclagem forçada) e Optimize OpenSearch refresh interval (Otimizar intervalo de atualização do OpenSearch) no site do OpenSearch.

Antes de adicionar fragmentos de réplica em todos os nós, avalie os requisitos da sua aplicação. Se sua aplicação precisar pesquisar todos os dados de qualquer nó, aumente o número de fragmentos de réplica para aumentar a disponibilidade dos dados. Caso contrário, talvez você não precise de fragmentos de réplica em cada nó.

Observação: os fragmentos de réplica permitem que os clusters usem o processamento paralelo e distribuam solicitações de pesquisa em várias cópias dos dados. Como resultado, o desempenho da pesquisa melhora. No entanto, as operações de indexação ficam mais lentas e você precisa de armazenamento extra para cada cópia completa dos dados.

Para índices com muitos fragmentos, use o roteamento personalizado para ajudar a melhorar o desempenho da pesquisa. Com o roteamento personalizado, você consulta somente os fragmentos que contêm seus dados em vez de todos os fragmentos. Para configurar o roteamento personalizado, consulte Customizing your document routing (Personalizando o roteamento do seu documento) no site da Elastic.

Use o armazenamento UltraWarm para dados somente para leitura

O armazenamento hot oferece o desempenho mais rápido para indexar e pesquisar 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 somente para leitura que não exigem alto desempenho, use o UltraWarm em vez do armazenamento de dados hot.

Aumente sua velocidade de pesquisa

Pesquise o mínimo possível de campos e evite consultas com scripts e curingas. Para obter mais informações, consulte Tune for search speed (Ajustar a velocidade de pesquisa), no site do Elastic.