Como resolvo rejeições de pesquisa ou gravação no OpenSearch Service?

Breve descrição

Ao gravar ou pesquisar dados no cluster do OpenSearch Service, é possível receber o seguinte erro HTTP 429 ou es_rejected_execution_exception:

error":"elastic: Error 429 (Too Many Requests): rejected execution of org.elasticsearch.transport.TransportService$7@b25fff4 on
EsThreadPoolExecutor[bulk, queue capacity = 200, org.elasticsearch.common.util.concurrent.EsThreadPoolExecutor@768d4a66[Running,
pool size = 2, active threads = 2, queued tasks = 200, completed tasks = 820898]] [type=es_rejected_execution_exception]"

Reason={"type":"es_rejected_execution_exception","reason":"rejected execution of org.elasticsearch.transport.TcpTransport$RequestHandler@3ad6b683 on EsThreadPoolExecutor[search, queue capacity = 1000, org.elasticsearch.common.util.concurrent.EsThreadPoolExecutor@bef81a5[Running, pool size = 25, active threads = 23, queued tasks = 1000, completed tasks = 440066695]]"

As variáveis a seguir podem contribuir para um erro HTTP 429 ou es_rejected_execution_exception:

• Tipos de instância do nó de dados e limites de pesquisa ou gravação
• Valores elevados para métricas de instâncias
• Threads ativos e de fila
• Alta utilização da CPU e pressão de memória da JVM

Erros HTTP 429 podem ocorrer devido a solicitações de pesquisa e gravação no cluster. As rejeições também podem vir de um único nó ou de vários nós do cluster.

Observação: versões diferentes do Elasticsearch usam diferentes grupos de threads para processar chamadas da API _index. As versões 1.5 e 2.3 do Elasticsearch usam o pool de threads de índice. As versões 5.x, 6.0 e 6.2 do Elasticsearch usam o pool de threads de lote. As versões 6.3 e posteriores do Elasticsearch usam o pool de threads de gravação. Para mais informações, consulte Pool de threads no site do Elasticsearch.

Resolução

Tipos de instância do nó de dados e limites de pesquisa ou gravação

Um tipo de instância de nó de dados tem CPUs virtuais (vCPUs) fixas. Insira a contagem de vCPUs na fórmula para recuperar as operações simultâneas de pesquisa ou gravação que o nó pode realizar antes de entrar em uma fila. Se um thread ativo ficar cheio, ele será transferido para uma fila e, eventualmente, será rejeitado. Para mais informações sobre a relação entre vCPUs e tipos de nós, consulte preços do OpenSearch Service.

Além disso, há um limite de quantas pesquisas por nó ou gravações por nó é possível realizar. Esse limite baseia-se na definição do pool de threads e no número da versão do Elasticsearch. Para mais informações, consulte Pool de threads no site do Elasticsearch.

Por exemplo, se você escolher o tipo de nó R5.2xlarge para cinco nós no cluster do Elasticsearch (versão 7.4), o nó terá 8 vCPUs.

Use a fórmula a seguir para calcular o máximo de threads ativos para solicitações de pesquisa:

int ((# of available_processors * 3) / 2) + 1

Use a fórmula a seguir para calcular o máximo de threads ativos para solicitações de gravação:

int (# of available_processors)

Para o nó R5.2xlarge, é possível realizar no máximo 13 operações de pesquisa:

(8 VCPUs * 3) / 2 + 1 = 13 operations

Para o nó R5.2xlarge, é possível realizar no máximo 8 operações de gravação:

8 VCPUs = 8 operations

Para o cluster do OpenSearch Service com cinco nós, é possível realizar no máximo 65 operações de pesquisa:

5 nodes * 13 = 65 operations

Para o cluster do OpenSearch Service com cinco nós, é possível realizar no máximo 40 operações de gravação:

5 nodes * 8 = 40 operations

Valores elevados para métricas de instâncias

Para solucionar a exceção 429, verifique as seguintes métricas do Amazon CloudWatch para seu cluster:

• TaxaIndexação: o número de operações de indexação por minuto. Uma única chamada para a API _bulk que adiciona dois documentos e atualiza dois conta como quatro operações que podem se distribuir entre os nós. Se esse índice tiver uma ou mais réplicas, outros nós no cluster também registrarão um total de quatro operações de indexação. As exclusões de documentos não contam na métrica TaxaIndexação.
• TaxaPesquisa: o número total de solicitações de pesquisa por minuto para todos os fragmentos em um nó de dados. Uma única chamada para a API _search pode retornar resultados de vários fragmentos diferentes. Se cinco fragmentos diferentes estiverem em um nó, o nó registrará “5” para essa métrica, mesmo que o cliente tenha feito apenas uma solicitação.
• RejeiçõesGravaçãoCoordenação: o número total de rejeições que ocorreram no nó de coordenação. Essas rejeições são causadas pela pressão de indexação acumulada desde a startup do OpenSearch Service.
• RejeiçõesGravaçãoPrimária: o número total de rejeições que ocorreram nos fragmentos primários. Essas rejeições são causadas pela pressão de indexação acumulada desde a última startup do OpenSearch Service.
• RejeiçõesGravaçãoRéplica: o número total de rejeições que ocorreram nos fragmentos de réplica devido à pressão de indexação. Essas rejeições são causadas pela pressão de indexação acumulada desde a última startup do OpenSearch Service.
• FilaGravaçãoPoolThreads: o número de tarefas em fila no pool de threads de gravação. Essa métrica informa se uma solicitação está sendo rejeitada devido ao alto uso da CPU ou à alta simultaneidade de indexação.
• RejeiçõesGravaçãoPoolThreads: o número de tarefas rejeitadas no pool de threads de gravação.
  Observação: O tamanho padrão da fila de gravação passou de 200 para 10.000 no OpenSearch Service versão 7.9. Consequentemente, essa métrica não é mais o único indicador de rejeições do OpenSearch Service. Use as métricas RejeiçõesGravaçãoCoordenação, RejeiçõesGravaçãoPrimária e RejeiçõesGravaçãoRéplica nas versões 7.9 e posteriores para monitorar rejeições.
• FilaPesquisaPoolThreads: o número de tarefas em fila no pool de threads de pesquisa. Se o tamanho da fila for consistentemente alto, considere escalar o cluster. O tamanho máximo da fila de pesquisa é 1.000.
• RejieçõesPesquisaPoolThreads: o número de tarefas rejeitadas no pool de threads de pesquisa. Se esse número crescer continuamente, considere escalar o cluster.
• PressãoMemóriaJVM: a pressão de memória de JVM especifica a porcentagem da pilha Java em um nó do cluster. Se a pressão de memória da JVM atingir 75%, o OpenSearch Service iniciará o coletor de resíduos Concurrent Mark Sweep (CMS). A coleta de resíduos é um processo que exige muita CPU. Se a pressão de memória da JVM permanecer nessa porcentagem por alguns minutos, podem surgir problemas de desempenho do cluster. Obtenha mais informações consultando Como posso solucionar problemas de alta pressão de memória JVM no cluster do Amazon OpenSearch Service?

Observação: as métricas do pool de threads listadas informam sobre a TaxaIndexação e a TaxaPesquisa.

Para mais informações sobre como monitorar o cluster do OpenSearch Service com o CloudWatch, consulte Métricas de instância.

Threads ativos e de fila

Se houver falta de CPUs ou alta simultaneidade de solicitações, uma fila poderá ser preenchida rapidamente, resultando em um erro HTTP 429. Para monitorar os threads de fila, verifique as métricas FilaPesquisaPoolThreads e FilaGravaçãoPoolThreads no CloudWatch.

Para verificar se há alguma rejeição de pesquisa nos threads ativos e de fila, use o seguinte comando:

GET /_cat/thread_pool/search?v&h=id,name,active,queue,rejected,completed

Para verificar se há rejeições de gravação nos threads ativos e de fila, substitua “pesquisa” por “gravação”. Os valores rejeitados e concluídos na saída são contadores de nós cumulativos, que são redefinidos quando novos nós são lançados. Para mais informações, consulte a seção Exemplo com colunas explícitas da API cat thread pool no site do Elasticsearch.

Observação: a fila em lote em cada nó pode conter entre 50 e 200 solicitações, dependendo da versão do Elasticsearch que você está usando. Quando a fila está cheia, novas solicitações são rejeitadas.

Erros nas rejeições de pesquisa e gravação

Rejeições de pesquisa

Um erro de rejeição de pesquisa indica que os threads ativos estão ocupados e que as filas estão cheias até o número máximo de tarefas. Consequentemente, a solicitação de pesquisa pode ser rejeitada. É possível configurar os logs do OpenSearch Service para que essas mensagens de erro apareçam em seus logs com lentidão de pesquisa.

Observação: para evitar sobrecarga extra, defina o limite de logs com lentidão com um valor espaçado. Por exemplo, se a maioria das consultas levar 11 segundos e o limite for “10”, o OpenSearch Service levará mais tempo para gravar um log. É possível evitar essa sobrecarga definindo o limite de log com lentidão para 20 segundos. Assim, somente uma pequena porcentagem das consultas mais lentas (que demoram mais de 11 segundos) é registrada.

Depois que o cluster estiver configurado para enviar logs com lentidão de pesquisa para o CloudWatch, defina um limite específico para a geração de logs com lentidão. É possível definir um limite específico para a geração de logs com lentidão com a seguinte chamada HTTP POST:

curl -XPUT http://<your domain’s endpoint>/index/_settings -d '{"index.search.slowlog.threshold.query.<level>":"10s"}'

Rejeições de gravação

Uma mensagem de erro 429 como rejeição de gravação indica um erro de fila em lote. es_rejected_execution_exception[bulk] indica que a fila está cheia e que todas as novas solicitações foram rejeitadas. Esse erro de fila em lote ocorre quando o número de solicitações do cluster excede o tamanho da fila em lote (threadpool.bulk.queue_size). A fila em lote em cada nó pode conter entre 50 e 200 solicitações, dependendo da versão do Elasticsearch que você está usando.

É possível configurar os logs do OpenSearch Service para que essas mensagens de erro apareçam em seus logs com lentidão de indexação.

Observação: para evitar sobrecarga extra, defina o limite de logs com lentidão com um valor espaçado. Por exemplo, se a maioria das consultas levar 11 segundos e o limite for “10”, o OpenSearch Service levará mais tempo para gravar um log. É possível evitar essa sobrecarga definindo o limite de log com lentidão para 20 segundos. Assim, somente uma pequena porcentagem das consultas mais lentas (que demoram mais de 11 segundos) é registrada.

Depois que o cluster estiver configurado para enviar logs com lentidão de pesquisa para o CloudWatch, defina um limite específico para a geração de logs com lentidão. Para definir um limite específico para a geração de logs com lentidão, use a seguinte chamada HTTP POST:

curl -XPUT http://<your domain’s endpoint>/index/_settings -d '{"index.indexing.slowlog.threshold.query.<level>":"10s"}'

Práticas recomendadas para rejeições de gravação

Seguem algumas práticas recomendadas que reduzem as rejeições de gravação:

• Quando os documentos são indexados mais rapidamente, é menos provável que a fila de gravação atinja a capacidade máxima.
• Ajuste o tamanho em lote de acordo com o workload e o desempenho desejado. Para mais informações, consulte Ajustar a velocidade de indexação no site do Elasticsearch.
• Adicione a lógica de repetição exponencial na lógica da aplicação. A lógica de repetição exponencial garante que as solicitações com falha se repitam automaticamente.
  Observação: se seu cluster receber continuamente altas solicitações simultâneas, a lógica de repetição exponencial não ajudará a resolver o erro 429. Adote essa prática recomendada quando houver um pico repentino ou ocasional de tráfego.
• Se você estiver ingerindo dados do Logstash, ajuste a contagem de processamento e o tamanho do lote. É uma prática recomendada definir o tamanho do volume entre 3 e 5 MB.

Para mais informações sobre o ajuste do desempenho da indexação, consulte Como posso melhorar o desempenho da indexação no meu cluster do OpenSearch Service?

Práticas recomendadas para rejeições de pesquisa

Seguem algumas práticas recomendadas que reduzem as rejeições de pesquisa:

• Mude para um tipo de instância maior. O OpenSearch Service depende muito do cache do sistema de arquivos para resultados de pesquisa mais rápidos. O número de threads no pool de threads em cada nó para solicitações de pesquisa é igual ao seguinte: int((# of available_processors * 3) / 2) + 1. Mude para uma instância com mais vCPUs para obter mais threads para processar solicitações de pesquisa.
• Ative os logs com lentidão de pesquisa para um determinado índice ou para todos os índices com um valor limite razoável. Verifique quais consultas estão demorando mais para serem executadas e implemente estratégias de desempenho de pesquisa para suas consultas. Para mais informações, consulte Solução de problemas de pesquisas do Elasticsearch para iniciantes ou Ajuste avançado: como localizar e corrigir consultas com lentidão do Elasticsearch no site do Elasticsearch.