Come posso risolvere i rifiuti di ricerca o di scrittura su Amazon OpenSearch Service?

Ultimo aggiornamento: 19/10/2021

Quando invio una richiesta di ricerca o scrittura al cluster Amazon OpenSearch Service (successore di Amazon Elasticsearch Service), le richieste vengono rifiutate. Perché accade?

Breve descrizione

Quando scrivi o cerchi dati nel cluster OpenSearch Service, potresti ricevere il seguente errore HTTP 429 o 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]]"

Le seguenti variabili possono contribuire a un errore HTTP 429 o es_rejected_execution_exception:

  • Tipi di istanza del nodo dati e limiti di ricerca o scrittura
  • Valori elevati per i parametri di esempio
  • Thread attivi e in coda

Gli errori HTTP 429 possono verificarsi a causa di richieste di ricerca e scrittura nel cluster. I rifiuti possono anche provenire da un singolo nodo o da più nodi del cluster.

Nota: diverse versioni di Elasticsearch utilizzano pool di thread diversi per elaborare le chiamate all'API _index. Le versioni 1.5 e 2.3 di Elasticsearch utilizzano il pool di thread di indice. Le versioni 5.x, 6.0 e 6.2 di Elasticsearch utilizzano il pool di thread di massa. Le versioni 6.3 e successive di Elasticsearch utilizzano il pool di thread di scrittura. Per ulteriori informazioni, consulta Pool di thread sul sito Web di Elasticsearch.

Risoluzione

Tipi di istanza del nodo dati e limiti di ricerca o scrittura

Un tipo di istanza di nodo dati dispone di CPU virtuali fisse (vCPU). Collega il numero di vCPU alla formula per recuperare le operazioni di ricerca o scrittura simultanee che il nodo può eseguire prima che entri in una coda. Se un thread attivo diventa pieno, il thread si riversa in una coda e alla fine viene rifiutato. Per ulteriori informazioni sulla relazione tra vCPU e tipi di nodo, consulta i prezzi di Amazon OpenSearch Service.

Inoltre, esiste un limite al numero di ricerche o scritture per nodo che è possibile eseguire. Questo limite si basa sulla definizione del pool di thread e sul numero di versione di Elasticsearch. Per ulteriori informazioni, consulta Pool di thread sul sito Web di Elasticsearch.

Ad esempio, se scegli il tipo di nodo R5.2xlarge per cinque nodi nel tuo cluster Elasticsearch (versione 7.4), il nodo avrà 8 vCPU.

Utilizza la seguente formula per calcolare il numero massimo di thread attivi per le richieste di ricerca:

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

Utilizza la seguente formula per calcolare il numero massimo di thread attivi per le richieste di scrittura:

int (# of available_processors)

Pertanto, per un nodo R5.2xlarge, è possibile eseguire un massimo di 13 operazioni di ricerca:

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

Per un nodo R5.2xlarge, è possibile eseguire un massimo di 8 operazioni di scrittura:

8 VCPUs = 8 operations

Per un cluster OpenSearch Service con cinque nodi, è quindi possibile eseguire un massimo di 65 operazioni di ricerca:

5 nodes * 13 = 65 operations

Per un cluster OpenSearch Service con cinque nodi, è quindi possibile eseguire un massimo di 40 operazioni di scrittura:

5 nodes * 8 = 40 operations

Valori elevati per i parametri di esempio

Per risolvere i problemi relativi all'eccezione 429, controlla i seguenti parametri di Amazon CloudWatch per il tuo cluster:

  • IndexingRate: il numero di operazioni di indicizzazione al minuto. Una singola chiamata all'API _bulk che aggiunge due documenti e ne aggiorna due conta come quattro operazioni che potrebbero essere distribuite su uno o più nodi. Se l'indice contiene una o più repliche, anche gli altri nodi del cluster registrano un totale di quattro operazioni di indicizzazione. Le eliminazioni di documenti non vengono conteggiate ai fini del parametro IndexingRate.
  • SearchRate: il numero totale di richieste di ricerca al minuto per tutti i frammenti su un nodo di dati. Una singola chiamata all'API _search potrebbe restituire risultati da molti frammenti diversi. Se cinque diversi frammenti si trovano su un nodo, il nodo riporta "5" per questo parametro, anche se il client ha fatto solo una richiesta.
  • CoordinatingWriteRejected: il numero totale di rifiuti che si sono verificati sul nodo di coordinamento. Questi rifiuti sono causati dalla pressione di indicizzazione accumulata dall'avvio di OpenSearch Service.
  • PrimaryWriteRejected: il numero totale di rifiuti che si sono verificati sui shard primari. Questi rifiuti sono causati dalla pressione di indicizzazione accumulata dall'ultimo avvio di OpenSearch Service.
  • ReplicaWriteRejected: il numero totale di rifiuti che si sono verificati sugli shard di replica a causa della pressione di indicizzazione. Questi rifiuti sono causati dalla pressione di indicizzazione accumulata dall'ultimo avvio di OpenSearch Service.
  • ThreadPoolWriteQueue: il numero di attività in coda nel pool di thread di scrittura. Questo parametro indica se una richiesta viene rifiutata a causa di un elevato utilizzo della CPU o di un'elevata simultaneità di indicizzazione.
  • ThreadPoolWriteRejected: il numero di attività rifiutate nel pool di thread di scrittura.
    Nota: la dimensione predefinita della coda di scrittura è stata aumentata da 200 a 10.000 nella versione 7.9 di OpenSearch Service. Di conseguenza, questa metrica non è più l'unico indicatore di rifiuti da parte di OpenSearch Service. Utilizza i parametri CoordinatingWriteRejected, PrimaryWriteRejected e ReplicaWriteRejected per monitorare i rifiuti nelle versioni 7.9 e successive. Per ulteriori informazioni, consulta i parametri UltraWarm.
  • ThreadPoolSearchQueue: il numero di attività in coda nel pool di thread di ricerca. Se la dimensione della coda è costantemente elevata, valuta la possibilità di ridimensionare il cluster. La dimensione massima della coda di ricerca è 1.000.
  • ThreadPoolSearchRejected: il numero di attività rifiutate nel pool di thread di ricerca. Se questo numero aumenta continuamente, valuta la possibilità di ridimensionare il cluster.

Nota: i parametri del pool di thread elencati aiutano a informare l'utente su IndexingRate e SearchRate.

Per ulteriori informazioni sul monitoraggio del cluster OpenSearch Service con Amazon CloudWatch, consulta Parametri delle istanze.

Thread attivi e in coda

In caso di mancanza di CPU o di una elevata simultaneità di richieste, una coda può riempirsi rapidamente, causando un errore HTTP 429. Per monitorare i thread della coda, controlla i parametri ThreadpoolSearchQueue e ThreadpoolWriteQueue in Amazon CloudWatch.

Per controllare i thread attivi e in coda per eventuali rifiuti di ricerca, utilizza il seguente comando:

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

Per controllare i thread attivi e in coda per i rifiuti di scrittura, sostituisci "search" con "write". I valori rifiutati e completati nell'output sono contatori di nodi cumulativi, che vengono reimpostati all'avvio di nuovi nodi. Per ulteriori informazioni, consulta la sezione Esempio con colonne esplicite dell'API del pool di thread cat sul sito Web Elasticsearch.

Nota: la coda bulk su ciascun nodo può contenere da 50 a 200 richieste, a seconda della versione di Elasticsearch in uso. Quando la coda è piena, le nuove richieste vengono rifiutate. Per ulteriori informazioni, consulta Pool di thread sul sito Web di Elasticsearch.

Errori di esempio per i rifiuti di ricerca e scrittura

Rifiuti di ricerca

Un errore di rifiuto della ricerca indica che i thread attivi sono occupati e che le code sono riempite fino al numero massimo di processi. Di conseguenza, la tua richiesta di ricerca può essere rifiutata. Puoi configurare i registri di OpenSearch Service in modo che questi messaggi di errore vengano visualizzati nei registri lenti di ricerca.

Nota: per evitare un sovraccarico aggiuntivo, imposta la soglia dei log lenti su un valore abbondante. Ad esempio, se la maggior parte delle query richiede 11 secondi e la soglia è "10", OpenSearch Service impiega più tempo per scrivere un log. È possibile evitare questo sovraccarico impostando la soglia dei log lenti su 20 secondi. Quindi, viene registrata solo una piccola percentuale delle query più lente (che richiedono più di 11 secondi).

Dopo aver configurato il cluster per inviare i log lenti di ricerca ad Amazon CloudWatch, imposta una soglia specifica per la generazione dei log lenti. È possibile impostare una soglia specifica per la generazione dei log lenti con la seguente chiamata POST HTTP:

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

Rifiuti di scrittura

Un messaggio di errore 429 come rifiuto di scrittura indica un errore di coda in blocco. Il file es_rejected_execution_exception [bulk] indica che la coda è piena e che tutte le nuove richieste vengono rifiutate. Questo errore di coda in blocco si verifica quando il numero di richieste al cluster supera la dimensione della coda di massa (threadpool.bulk.queue_size). Una coda in blocco su ciascun nodo può contenere da 50 a 200 richieste, a seconda della versione di Elasticsearch in uso.

Puoi configurare i registri di OpenSearch Service in modo che questi messaggi di errore vengano visualizzati nei registri lenti degli indici.

Nota: per evitare un sovraccarico aggiuntivo, imposta la soglia dei log lenti su un valore abbondante. Ad esempio, se la maggior parte delle query richiede 11 secondi e la soglia è "10", OpenSearch Service impiegherà più tempo per scrivere un log. È possibile evitare questo sovraccarico impostando la soglia dei log lenti su 20 secondi. Quindi, viene registrata solo una piccola percentuale delle query più lente (che richiedono più di 11 secondi).

Dopo aver configurato il cluster per inviare i log lenti di ricerca ad Amazon CloudWatch, imposta una soglia specifica per la generazione dei log lenti. Per impostare una soglia specifica per la generazione dei log lenti, utilizza la seguente chiamata POST HTTP:

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

Best practice per il rifiuto di scritture

Ecco alcune best practice che mitigano i rifiuti di scrittura:

  • Quando i documenti vengono indicizzati più velocemente, è meno probabile che la coda di scrittura raggiunga la capacità.
  • Regola le dimensioni in blocco in base al carico di lavoro e alle prestazioni desiderate. Per ulteriori informazioni, consulta Ottimizzazione della velocità di indicizzazione sul sito Web di Elasticsearch.
  • Aggiungi la logica dei tentativi esponenziale alla logica dell'applicazione. La logica dei tentativi esponenziali garantisce che le richieste non riuscite vengano riprovate automaticamente.
    Nota: se il cluster presenta continuamente un numero elevato di richieste simultanee, la logica dei tentativi esponenziali non aiuta a risolvere l'errore 429. Segui questa best practice quando si verifica un picco di traffico improvviso o occasionale.
  • Se si stanno inserendo dati da Logstash, regola il numero dei worker e le dimensioni in blocco. È una best practice impostare la dimensione in blocco tra 3-5 MB.

Per ulteriori informazioni sull'ottimizzazione delle prestazioni di indicizzazione, consulta Come posso migliorare le prestazioni di indicizzazione sul cluster Amazon OpenSearch Service?

Best practice per il rifiuto di ricerca

Di seguito sono elencate alcune best practice per mitigare i rifiuti di ricerca:

  • Passa a un tipo di istanza più grande. OpenSearch Service fa molto affidamento sulla cache del file system per risultati di ricerca più rapidi. Il numero di thread nel pool di thread su ciascun nodo per le richieste di ricerca è uguale al seguente: int ((# of available_processors * 3)/2) + 1. Passa a un'istanza con più vCPU per ottenere più thread per elaborare le richieste di ricerca.
  • Abilita i log lenti di ricerca per un determinato indice o per tutti gli indici con un valore soglia ragionevole. Verificare quali query richiedono più tempo per l'esecuzione e implementa strategie di prestazioni di ricerca per le query. Per ulteriori informazioni, consulta Risoluzione dei problemi delle ricerche Elasticsearch, per principianti o Ottimizzazione avanzata: ricerca e correzione di query Elasticsearch lente sul sito Web Elasticsearch.

Questo articolo è stato utile?


Hai bisogno di supporto tecnico o per la fatturazione?