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

Breve descrição

Ao gravar ou pesquisar dados no cluster do OpenSearch Service, você pode 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 de nó de dados e limites de pesquisa ou gravação
• Valores altos para métricas de instância
• Threads ativos e de fila

Erros HTTP 429 podem ocorrer em função de solicitações de pesquisa e gravação para o 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 grupos de threads diferentes para processar chamadas para a 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 grupol 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 de nó de dados e limites de pesquisa ou gravação

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

Além disso, há um limite de quantas pesquisas ou gravações por nó você poderá realizar. Esse limite é baseado 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)

Portanto, para um nó R5.2xlarge, você poderá executar no máximo 13 operações de pesquisa:

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

Para um nó R5.2xlarge, você poderá executar no máximo oito operações de gravação:

8 VCPUs = 8 operations

Para um cluster do OpenSearch Service com cinco nós, você poderá executar no máximo 65 operações de pesquisa:

5 nodes * 13 = 65 operations

Para um cluster do OpenSearch Service com cinco nós, você poderá executar no máximo 40 operações de gravação:

5 nodes * 8 = 40 operations

Valores altos para métricas de instância

Para solucionar problemas da exceção 429, confira as seguintes métricas do Amazon CloudWatch para o 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, contabiliza quatro operações que podem estar espalhadas por um ou mais 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 geram contagens em relação à 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 muitos fragmentos diferentes. Se cinco fragmentos diferentes estiverem em um nó, o nó reportará “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 enfileiradas no grupo 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.
• 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 foi aumentado de 200 para 10.000 no OpenSearch Service versão 7.9. Como resultado, essa métrica não é mais o único indicador de rejeições do OpenSearch Service. Use as métricasCoordinatingWriteRejected, PrimaryWriteRejected e ReplicaWriteRejected para monitorar rejeições nas versões 7.9 e posteriores. Para obter mais informações, consulte Métricas do UltraWarm.
• ThreadpoolSearchQueue: o número de tarefas enfileiradas no grupo de threads de pesquisa. Se o tamanho da fila for consistentemente alto, considere escalar o seu cluster. O tamanho máximo da fila de pesquisa é de 1.000.
• ThreadpoolSearchRejected: o número de tarefas rejeitadas no grupo de threads de pesquisa. Se esse número crescer de forma contínua, considere escalar o seu cluster.

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

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

Threads ativos e de fila

Se houver falta de CPUs ou alta simultaneidade de solicitações, uma fila poderá ser rapidamente preenchida, resultando em um erro HTTP 429. Para monitorar os seus threads de fila, confira as métricas ThreadpoolSearchQueue e ThreadpoolWriteQueue metrics no Amazon CloudWatch.

Para conferir se há rejeições de pesquisa nos seus threads ativos e de fila, use o seguinte comando:

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

Para conferir se há rejeições de gravação nos seus threads ativos e de fila, substitua “search” por “write”. 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 iniciados. Para obter mais informações, consulte a seção Example with explicit columns (Exemplo com colunas explícitas) da cat thread pool API (API do grupo de threads cat) 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 estiver cheia, novas solicitações serão rejeitadas. Para obter mais informações, consulte Thread pool (Grupo de threads) no site do Elasticsearch.

Exemplos de erros para 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 preenchidas até o número máximo de tarefas. Como resultado, a sua solicitação de pesquisa poderá ser rejeitada. Você pode configurar os logs do OpenSearch Service para que essas mensagens de erro apareçam nos seus logs de pesquisa lentos.

Observação: para evitar sobrecarga extra, defina o seu limite de log lento para uma quantidade generosa. Por exemplo, se a maioria das suas consultas demorar 11 segundos e seu limite for “10", o OpenSearch Service levará mais tempo para gravar um log. Você pode evitar essa sobrecarga definindo seu limite de log lento para 20 segundos. Então, apenas uma pequena porcentagem das consultas mais lentas (que demoram mais de 11 segundos) será registrada.

Depois que o cluster for configurado para enviar logs de pesquisa lentos para o Amazon CloudWatch, defina um limite específico para geração lenta de logs. Você pode 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. O erro es_rejected_execution_exception[bulk] indica que a sua fila está cheia e que todas as novas solicitações são rejeitadas. Esse erro de fila em massa ocorre quando o número de solicitações para o cluster excede o tamanho da fila em massa (threadpool.bulk.queue_size). Uma fila em massa em cada nó pode conter entre 50 e 200 solicitações, dependendo da versão do Elasticsearch que você estiver usando.

Você pode configurar os logs do OpenSearch Service para que essas mensagens de erro apareçam nos logs lentos do índice.

Observação: para evitar sobrecarga extra, defina o seu limite de log lento para uma quantidade generosa. Por exemplo, se a maioria das suas consultas levar 11 segundos e o seu limite for “10", o OpenSearch Service levará mais tempo para gravar um log. Você pode evitar essa sobrecarga definindo seu limite de log lento para 20 segundos. Então, apenas uma pequena porcentagem das consultas mais lentas (que demoram mais de 11 segundos) será registrada.

Depois que o cluster for configurado para enviar logs de pesquisa lentos para o Amazon CloudWatch, defina um limite específico para geração lenta de logs. Para definir um limite específico para 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 de rejeição de gravação

Aqui estão algumas práticas recomendadas que minimizam as rejeições de gravação:

• Quando os documentos são indexados mais rapidamente, torna-se menos provável que a fila de gravação atinja a sua capacidade.
• Ajuste o tamanho do volume de acordo com a sua workload e a performance desejada. Para obter mais informações, consulte Tune for indexing speed no site do Elasticsearch.
• Adicione uma lógica exponencial de nova tentativa à lógica da sua aplicação. A lógica exponencial de nova tentativa garante que as solicitações com falha sejam repetidas automaticamente.
  Observação: se o cluster receber solicitações simultâneas altas continuamente, a lógica exponencial de nova tentativa não ajudará a solucionar o erro 429. Incorpore essa prática recomendada quando houver um aumento repentino ou ocasional de tráfego.
• Se você estiver ingerindo dados do Logstash, ajuste a contagem e o tamanho do volume do operador. Definir o tamanho do volume entre 3 e 5 MB é uma prática recomendada.

Para obter mais informações sobre o ajuste de performance de indexação, consulte Como melhorar a performance de indexação em meu cluster do Amazon OpenSearch Service?

Práticas recomendadas de rejeição de pesquisa

Aqui estão algumas práticas recomendadas que minimizam as rejeições de pesquisa:

• Mude para um tipo maior de instância. O OpenSearch Service depende muito do cache do sistema de arquivos para obter 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 logs de pesquisa lentos para um determinado índice ou para todos os índices com um valor limite razoável. Confira quais consultas estão demorando mais para executar e implementar estratégias de performance de pesquisa em suas consultas. Para obter mais informações, consulte Solução de problemas com o Elasticsearch para iniciantes ou Ajuste avançado: localização e correção de consultas lentas do Elasticsearch no site do Elasticsearch.

---