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

Breve descrizione

Quando scrivi o cerchi dati in un cluster del 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 istanza del nodo 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 (Pool di thread) sul sito web Elasticsearch.

Risoluzione

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

Il tipo di istanza di un nodo di dati ha CPU virtuali fisse (vCPU). Inserisci il numero di vCPU nella formula per recuperare le operazioni di ricerca o scrittura concorrenti 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 nodo, consulta Prezzi del Servizio OpenSearch.

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

Ad esempio, se scegli il tipo di nodo R5.2xlarge per cinque nodi nel 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, puoi eseguire un massimo di 13 operazioni di ricerca:

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

Per un nodo R5.2xLarge, puoi eseguire un massimo di 8 operazioni di scrittura:

8 VCPUs = 8 operations

Per un cluster del Servizio OpenSearch con cinque nodi, puoi eseguire un massimo di 65 operazioni di ricerca:

5 nodes * 13 = 65 operations

Per un cluster del Servizio OpenSearch con cinque nodi, puoi 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 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 l'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 di un nodo di dati. Una singola chiamata all'API _search potrebbe restituire risultati da molti shard diversi. Se in 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 del Servizio OpenSearch.
• PrimaryWriteRejected: numero totale di rifiuti avvenuti negli shard primari. Questi rifiuti sono causati dalla pressione di indicizzazione accumulata dall'ultimo avvio del Servizio OpenSearch.
• ReplicaWriteRejected: numero totale di rifiuti avvenuti negli shard di replica a causa della pressione di indicizzazione. Questi rifiuti sono causati dalla pressione di indicizzazione accumulata dall'ultimo avvio del 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 del Servizio OpenSearch. Di conseguenza, questa metrica non è più l'unico indicatore dei rifiuti da parte del 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 scalare 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 scalare il cluster.
• JVMMemoryPressure: percentuale dell'heap Java in un nodo del cluster. Se la pressione della memoria JVM raggiunge il 75%, il Servizio OpenSearch avvia il garbage collector CMS (Concurrent Mark Sweep). Il processo di rimozione degli oggetti inutili (garbage collection) richiede un uso intensivo della CPU. Se la pressione della memoria JVM rimane a questa percentuale per alcuni minuti, potresti riscontrare problemi di prestazioni del cluster. Per ulteriori informazioni, consulta Come posso risolvere il problema della pressione elevata della memoria JVM del mio cluster del Servizio OpenSearch?

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

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

Thread attivi e in coda

In caso di numero insufficiente di CPU o elevata concorrenza 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 questo 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 (Esempio con colonne esplicite) in cat thread pool API (API cat thread pool) sul sito web 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 di ricerca indica che i thread attivi sono occupati e che le code sono piene, ossia hanno raggiunto il numero massimo di attività. Di conseguenza, la richiesta di ricerca può subire un rifiuto. Puoi configurare i log del Servizio OpenSearch in modo che questi messaggi di errore vengano visualizzati nei log delle ricerche lente.

Nota: per evitare sovraccarichi, imposta la soglia per questi log su un valore abbondante. Ad esempio, se la maggior parte delle query richiede 11 secondi e la soglia è "10", il Servizio OpenSearch impiega più tempo per scrivere un log. Puoi evitare questo sovraccarico impostando la soglia per i log delle query lente su 20 secondi. Così facendo, viene registrata solamente una percentuale ridotta delle query più lente (quelle che richiedono più di 11 secondi).

Dopo aver configurato il cluster per inviare i log delle query lente a CloudWatch, imposta una soglia specifica per la generazione dei log. Puoi impostare una soglia specifica per la generazione dei log 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 di ogni nodo può contenere da 50 a 200 richieste, a seconda della versione di Elasticsearch in uso.

Puoi configurare i log del Servizio OpenSearch in modo che questi messaggi di errore compaiano nei log delle indicizzazioni lente.

Nota: per evitare sovraccarichi, imposta la soglia per questi log su un valore abbondante. Ad esempio, se la maggior parte delle query richiede 11 secondi e la soglia è "10", il Servizio OpenSearch impiega più tempo per scrivere un log. Puoi evitare questo sovraccarico impostando la soglia per i log delle query lente su 20 secondi. Così facendo, viene registrata solamente una percentuale ridotta delle query più lente (quelle che richiedono più di 11 secondi).

Dopo aver configurato il cluster per inviare i log delle query lente a CloudWatch, imposta una soglia specifica per la generazione dei log. Per impostare una soglia specifica per la generazione dei log, 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 (Ottimizzazione della velocità di indicizzazione) sul sito web Elasticsearch.
• Aggiungi una logica di ripetizione esponenziale nella logica dell'applicazione. La logica di ripetizione esponenziale assicura che le richieste non riuscite vengano ritentate automaticamente.
  Nota: se il cluster riceve continuamente molte richieste concorrenti, 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 importi 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 del 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. Il 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((numero di processori_disponibili * 3) / 2) + 1. Passa a un'istanza con più vCPU per ottenere più thread per elaborare le richieste di ricerca.
• Attiva i log delle ricerche lente per un determinato indice o per tutti gli indici con un valore di soglia ragionevole. Identifica le query che richiedono più tempo per essere eseguite e implementa strategie di miglioramento delle prestazioni di ricerca per le query. Per ulteriori informazioni, consulta Troubleshooting Elasticsearch searches, for beginners (Risoluzione dei problemi relativi alle ricerche in Elasticsearch, per principianti) o Advanced tuning: Finding and fixing slow Elasticsearch queries (Ottimizzazione avanzata: individuare e correggere le query lente in Elasticsearch) sul sito web Elasticsearch.