Come posso risolvere il problema dei rifiuti di ricerca o scrittura in Servizio OpenSearch?

Breve descrizione

Quando scrivi o cerchi dati nel tuo cluster di Servizio OpenSearch, 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 istanze dei nodi di dati e limiti di ricerca o scrittura
• Valori elevati delle metriche dell'istanza
• Thread attivi e in coda
• Elevato utilizzo della CPU e della memoria JVM

Le richieste di ricerca e scrittura inviate al cluster possono causare errori HTTP 429. Il rifiuto può anche provenire da uno o più nodi del cluster.

Nota: versioni diverse 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 blocco. Le versioni 6.3 e successive di Elasticsearch utilizzano il pool di thread di scrittura. Per ulteriori informazioni, consulta Thread pool sul sito web di Elasticsearch.

Risoluzione

Tipi di istanze dei nodi di dati e limiti di ricerca o scrittura

Un tipo di istanza del nodo di dati ha CPU virtuali fisse (vCPU). Inserisci il numero di vCPU nella formula per recuperare le operazioni di ricerca o scrittura simultanee che il nodo può eseguire prima di entrare in coda. Se un thread attivo si riempie, il thread si riversa in una coda e alla fine viene rifiutato. Per ulteriori informazioni sulla relazione tra vCPU e tipi di nodi, consulta Prezzi del servizio OpenSearch.

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 Thread pool 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 formula seguente per calcolare il numero massimo di thread attivi per le richieste di ricerca:

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

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

int (# of available_processors)

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 di Servizio OpenSearch con cinque nodi, è possibile eseguire un massimo di 65 operazioni di ricerca:

5 nodes * 13 = 65 operations

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

5 nodes * 8 = 40 operations

Valori elevati delle metriche dell'istanza

Per risolvere l'eccezione 429, controlla le seguenti metriche di Amazon CloudWatch per il tuo cluster:

• IndexingRate: numero di operazioni di indicizzazione al minuto. Una singola chiamata all'API _bulk che aggiunge due documenti e ne aggiorna due viene conteggiata come quattro operazioni che potrebbero distribuirsi tra i nodi. Se quell'indice ha una o più repliche, anche altri nodi del cluster registrano un totale di quattro operazioni di indicizzazione. Le eliminazioni di documenti non vengono conteggiate ai fini della metrica IndexingRate.
• SearchRate: numero totale di richieste di ricerca al minuto per tutti gli shard su un nodo di dati. Una singola chiamata all'API _search potrebbe restituire risultati da molti shard diversi. Se su un nodo sono presenti cinque shard diversi, il nodo riporta "5" per questa metrica, anche se il client ha effettuato una sola richiesta.
• CoordinatingWriteRejected: numero totale di rifiuti avvenuti sul nodo di coordinamento. Questi rifiuti sono causati dalla pressione di indicizzazione accumulata dall'avvio di Servizio OpenSearch.
• PrimaryWriteRejected: numero totale di rifiuti avvenuti sugli shard primari. Questi rifiuti sono causati dalla pressione di indicizzazione accumulata dall'ultimo avvio di Servizio OpenSearch.
• ReplicaWriteRejected: numero totale di rifiuti avvenuti sugli shard di replica a causa della pressione di indicizzazione. Questi rifiuti sono causati dalla pressione di indicizzazione accumulata dall'ultimo avvio di Servizio OpenSearch.
• ThreadpoolWriteQueue: numero di attività in coda nel pool di thread di scrittura. Questa metrica indica se una richiesta viene rifiutata a causa dell'elevato utilizzo della CPU o dell'elevata concomitanza di indicizzazione.
• ThreadpoolWriteRejected: 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 Servizio OpenSearch. Di conseguenza, questa metrica non è più l'unico indicatore dei rifiuti da parte di Servizio OpenSearch. Utilizza le metriche CoordinatingWriteRejected, PrimaryWriteRejected e ReplicaWriteRejected per monitorare i rifiuti nelle versioni 7.9 e successive.
• ThreadpoolSearchQueue: 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: numero di attività rifiutate nel pool di thread di ricerca. Se questo numero aumenta continuamente, valuta la possibilità di ridimensionare il cluster.
• JVMMemoryPressure: la pressione della memoria JVM specifica la percentuale dell'heap Java in un nodo del cluster. Se la pressione della memoria JVM raggiunge il 75%, Servizio OpenSearch avvia il garbage collector CMS (Concurrent Mark Sweep). Il processo di garbage collection richiede un uso intensivo della CPU. Se la pressione della memoria JVM rimane a questa percentuale per alcuni minuti, è possibile che si verifichino problemi di prestazioni del cluster. Per ulteriori informazioni, consulta Come posso risolvere l'elevata pressione della memoria JVM sul mio cluster del servizio OpenSearch di Amazon?

Nota: le metriche del pool di thread elencate contribuiscono a fornire informazioni su IndexingRate e SearchRate.

Per ulteriori informazioni sul monitoraggio del cluster di Servizio OpenSearch con CloudWatch, consulta Metriche dell'istanza.

Thread attivi e in coda

In caso di mancanza di CPU o di elevata concomitanza di richieste, una coda può riempirsi rapidamente, generando un errore HTTP 429. Per monitorare i thread della coda, controlla le metriche ThreadpoolSearchQueue e ThreadpoolWriteQueue in CloudWatch.

Per verificare la presenza di rifiuti di ricerca nei thread attivi e in coda, utilizza il seguente comando:

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

Per verificare la presenza di rifiuti di scrittura nei thread attivi e in coda, sostituisci "search" con "write". I valori rejected e completed nell'output sono contatori cumulativi di nodi che vengono azzerati all'avvio di nuovi nodi. Per ulteriori informazioni, consulta la sezione Example with explicit columns di cat thread pool API sul sito web di Elasticsearch.

Nota: la coda in blocco su ogni nodo può contenere tra 50 e 200 richieste, a seconda della versione di Elasticsearch in uso. Quando la coda è piena, le nuove richieste vengono rifiutate.

Errori relativi a 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 attività. Di conseguenza, la tua richiesta di ricerca può subire un rifiuto. Puoi configurare i log di Servizio OpenSearch in modo che questi messaggi di errore vengano visualizzati nei log lenti di ricerca.

Nota: per evitare sovraccarichi, imposta la soglia dei log lenti su un valore generoso. Ad esempio, se la maggior parte delle tue query richiede 11 secondi e la tua soglia è "10", Servizio OpenSearch impiega più tempo per scrivere un log. Puoi evitare questo sovraccarico impostando la soglia dei log lenti su 20 secondi. Così facendo, 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 a CloudWatch, imposta una soglia specifica per la generazione di log lenti. Puoi impostare una soglia specifica per la generazione di log lenti con la seguente chiamata HTTP POST:

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 valore es_rejected_execution_exception[bulk] indica che la coda è piena e che tutte le nuove richieste verranno rifiutate. Questo errore di coda in blocco si verifica quando il numero di richieste al cluster supera la dimensione della coda in blocco (threadpool.bulk.queue_size). Una coda in blocco su ogni nodo può contenere da 50 a 200 richieste, a seconda della versione di Elasticsearch in uso.

Puoi configurare i log di Servizio OpenSearch in modo che questi messaggi di errore compaiano nei log lenti dell'indice.

Nota: per evitare sovraccarichi, imposta la soglia dei log lenti su un valore generoso. Ad esempio, se la maggior parte delle tue query richiede 11 secondi e la tua soglia è "10", Servizio OpenSearch impiega più tempo per scrivere un log. Puoi evitare questo sovraccarico impostando la soglia dei log lenti su 20 secondi. Così facendo, 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 a CloudWatch, imposta una soglia specifica per la generazione di log lenti. Per impostare una soglia specifica per la generazione dei log lenti, utilizza la seguente chiamata HTTP POST:

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

Best pratice per i rifiuti di scrittura

Ecco alcune best practice per mitigare i rifiuti di scrittura:

• Quando i documenti vengono indicizzati più velocemente, è meno probabile che la coda di scrittura raggiunga la capacità massima.
• Regola le dimensioni del blocco in base al carico di lavoro e alle prestazioni desiderate. Per ulteriori informazioni, consulta Tune for indexing speed sul sito web di Elasticsearch.
• Aggiungi una logica di ripetizione esponenziale nella logica della tua applicazione. La logica di ripetizione esponenziale assicura che le richieste non riuscite vengano ritentate automaticamente.
  Nota: se il cluster riceve continuamente molte richieste concomitanti, la logica di ripetizione esponenziale non aiuta a risolvere l'errore 429. Utilizza questa best practice in caso di picchi di traffico occasionali o improvvisi.
• Se stai acquisendo dati da Logstash, regola il numero di nodi worker e le dimensioni del blocco. È consigliabile impostare la dimensione del blocco fra 3 e 5 MB.

Per ulteriori informazioni sull'ottimizzazione delle prestazioni di indicizzazione, consulta In che modo è possibile migliorare le prestazioni di indicizzazione nel mio cluster di Servizio OpenSearch di Amazon?

Best practice per i rifiuti di ricerca

Ecco alcune best practice per mitigare i rifiuti di ricerca:

• Passa a un tipo di istanza più grande. Servizio OpenSearch 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.
• Attiva i log lenti di ricerca per un determinato indice o per tutti gli indici con un valore di soglia ragionevole. Verifica quali query richiedono più tempo per essere eseguite e implementa strategie di miglioramento delle prestazioni di ricerca per le tue query. Per ulteriori informazioni, consulta Troubleshooting Elasticsearch searches, for beginners o Advanced tuning: Finding and fixing slow Elasticsearch queries sul sito web di Elasticsearch.