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

Breve descrição

Ao gravar ou pesquisar dados no seu 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
• Utilização excessiva de CPU e pressão de memória JVM

Erros HTTP 429 podem ocorrer devido a solicitações de pesquisa e gravação no seu cluster. As rejeições também podem vir de um único nó ou de vários nós do seu 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 grupo de threads de índice. As versões 5.x, 6.0 e 6.2 do Elasticsearch usam o grupo de threads em massa. As versões 6.3 e posteriores do Elasticsearch usam o grupo de threads de gravação. Para obter mais informações, consulte Thread pool (Grupo 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 obter mais informações sobre a relação entre vCPUs e tipos de nós, consulte Preços do Amazon 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 grupo de threads e no número da versão do Elasticsearch. Para obter mais informações, consulte Thread pool (Grupo 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)

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

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

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

8 VCPUs = 8 operations

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

5 nodes * 13 = 65 operations

Em um 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 o erro de exceção 429, verifique as seguintes Amazon CloudWatch Metrics em seu cluster:

• IndexingRate: 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 registram um total de quatro operações de indexação. As exclusões de documentos não contam na métrica IndexingRate.
• SearchRate: 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ó registra "5" para essa métrica, mesmo que o cliente tenha feito apenas uma solicitação.
• CoordinatingWriteRejected: 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 inicialização do OpenSearch Service.
• PrimaryWriteRejected: 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 inicialização do OpenSearch Service.
• ReplicaWriteRejected: 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 inicialização do OpenSearch Service.
• ThreadpoolWriteQueue: o número de tarefas em fila no grupo de threads de gravação. Essa métrica informa se uma solicitação está sendo rejeitada devido ao uso excessivo da CPU ou à alta simultaneidade de indexação.
• ThreadpoolWriteRejected: o número de tarefas rejeitadas no grupo 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 CoordinatingWriteRejected, PrimaryWriteRejected e ReplicaWriteRejected nas versões 7.9 e posteriores para monitorar rejeições.
• ThreadpoolSearchQueue: o número de tarefas em fila no grupo 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.
• ThreadpoolSearchRejected: o número de tarefas rejeitadas no grupo de threads de pesquisa. Se esse número crescer continuamente, considere escalar o cluster.
• JVMMemoryPressure: A pressão de memória JVM especifica a porcentagem do heap do Java em um nó do cluster. Se a pressão de memória JVM atingir 75%, o OpenSearch Service inicia 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 JVM permanecer nessa porcentagem por alguns minutos, podem surgir problemas de desempenho do cluster. Para obter mais informações, consulte How do I troubleshoot high JVM memory pressure on my Amazon OpenSearch Service cluster? (Como soluciono problemas de alta pressão de memória de JVM no meu cluster do Amazon OpenSearch Service?)

Observação: as métricas do grupo de threads listadas informam sobre a IndexingRate e a SearchRate.

Para obter mais informações sobre como monitorar seu 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 da sua fila, verifique as métricas ThreadpoolSearchQueue e ThreadpoolWriteQueue 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 "search" por "write". Os valores rejected e completed na saída são contadores de nós cumulativos, que são redefinidos quando novos nós são executados. Para obter mais informações, consulte a seção Example with explicit columns (Exemplo com colunas explícitas) em API cat thread pool no site do Elasticsearch.

Observação: a fila em massa 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 lentos de pesquisa.

Observação: para evitar sobrecarga extra, defina o limite de logs lentos 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 lento para 20 segundos. Assim, somente uma pequena porcentagem das consultas mais lentas (que demoram mais de 11 segundos) é registrada.

Depois que seu cluster estiver configurado para enviar logs lentos de pesquisa para o CloudWatch, defina um limite específico para a geração de logs lentos. É possível definir um limite específico para a geração de logs lentos 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 massa. es_rejected_execution_exception[bulk] indica que a fila está cheia e que todas as novas solicitações serão rejeitadas. Esse erro de fila em massa ocorre quando o número de solicitações do cluster excede o tamanho da fila em massa (threadpool.bulk.queue_size). A fila em massa em cada nó pode conter entre 50 e 200 solicitações, dependendo de cada 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 lentos de índice.

Observação: para evitar sobrecarga extra, defina o limite de logs lentos 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 lento para 20 segundos. Assim, somente uma pequena porcentagem das consultas mais lentas (que demoram mais de 11 segundos) é registrada.

Depois que seu cluster estiver configurado para enviar logs lentos de pesquisa para o CloudWatch, defina um limite específico para a geração de logs lentos. Para definir um limite específico para a geração de logs lentos, 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 massa de acordo com seu workload e o desempenho desejado. Para obter mais informações, consulte Tune for indexing speed (Ajustar a velocidade de indexação) no site do Elasticsearch.
• Adicione a lógica de nova tentativa exponencial na lógica da sua aplicação. A lógica de nova tentativa 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 nova tentativa 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 processamentos e o tamanho do volume. É uma prática recomendada definir o tamanho do volume entre 3 e 5 MB.

Para obter mais informações sobre o ajuste do desempenho da indexação, consulte Como melhorar a performance de indexação em meu cluster do Amazon 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 ter resultados de pesquisa mais rápidos. O número de threads no grupo 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 lentos 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 obter mais informações, consulte Troubleshooting Elasticsearch searches, for beginners (Solução de problemas de pesquisas do Elasticsearch para iniciantes) ou Ajuste avançado: localização e correção de consultas lentas do Elasticsearch no site do Elasticsearch.