Come faccio a risolvere i problemi di utilizzo elevato della CPU nel mio cluster Amazon OpenSearch Service?

Breve descrizione

È consigliabile mantenere l'utilizzo della CPU per assicurarsi che OpenSearch Service disponga di risorse sufficienti per eseguire le proprie attività. Un cluster che offre prestazioni costanti con un elevato utilizzo della CPU può ridurre le prestazioni del cluster. Quando il cluster è sovraccarico, OpenSearch Service smette di rispondere, con conseguente richiesta di timeout.

Per risolvere i problemi relativi all'elevato utilizzo della CPU nel cluster, prendi in considerazione i seguenti approcci:

• Usa l'API dei thread attivi dei nodi.
• Controlla l'operazione di scrittura o il pool di thread API di massa.
• Controlla il pool dei thread di ricerca.
• Controlla il pool di thread di unione di Apache Lucene.
• Controlla la pressione della memoria JVM.
• Rivedi la tua strategia di partizione.
• Ottimizza le tue domande.

Risoluzione

Usa l'API dei thread attivi dei nodi

Se ci sono picchi di CPU costanti nel cluster OpenSearch Service, utilizza l'API dei thread attivi dei nodi. L'API dei thread attivi dei nodi funge da task manager, mostrando la suddivisione di tutti i thread ad alta intensità di risorse in esecuzione sul cluster.

Esempio di output dell'API thread attivi dei nodi:

GET _nodes/hot_threads

100.0% (131ms out of 500ms) cpu usage by thread 'opensearch[xxx][search][T#62]'
10/10 snapshots sharing following 10
elements sun.misc.Unsafe.park(Native Method)
java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
java.util.concurrent.LinkedTransferQueue.awaitMatch(LinkedTransferQueue.java:737)

java.util.concurrent.LinkedTransferQueue.xfer(LinkedTransferQueue.java:647)

java.util.concurrent.LinkedTransferQueue.take(LinkedTransferQueue.java:1269)

org.opensearch.common.util.concurrent.SizeBlockingQueue.take(SizeBlockingQueue.java:162)

java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)

java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)

java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
java.lang.Thread.run(Thread.java:745)

Nota: L'output dei thread attivi dei nodi riporta le informazioni per ogni nodo. La lunghezza dell'output dipende dal numero di nodi in esecuzione nel cluster di OpenSearch Service.

Inoltre, utilizza l'API dei nodi cat per visualizzare la suddivisione corrente dell'utilizzo delle risorse. Puoi restringere il sottoinsieme di nodi con il massimo utilizzo della CPU con il seguente comando:

GET _cat/nodes?v&s=cpu:desc

L'ultima colonna dell'output mostra il nome del nodo. Per ulteriori informazioni, consulta API dei nodi cat sul sito Web di Elasticsearch.

Quindi, passa il nome del nodo pertinente all'API dei thread attivi:

GET _nodes/<node-name>/hot_threads

Per ulteriori informazioni, consulta API dei thread attivi sul sito Web di Elasticsearch.

Esempio di output dei thread attivi dei nodi:

<percentage> of cpu usage by thread 'opensearch[<nodeName>][<thread-name>]'

Il nome del thread indica quali processi di OpenSearch Service consumano una CPU elevata.

Per ulteriori informazioni, consulta API dei thread attivi dei nodi sul sito Web di Elasticsearch.

Controlla l'operazione di scrittura o il pool di thread API di massa

Un errore 429 in OpenSearch Service può indicare che il cluster sta gestendo troppe richieste di indicizzazione bulk. Quando ci sono picchi costanti della CPU nel cluster, OpenSearch Service rifiuta le richieste di indicizzazione di massa.

Il pool di thread di scrittura gestisce le richieste di indicizzazione, che includono le operazioni di API bulk. Per verificare se il cluster sta gestendo troppe richieste di indicizzazione bulk, controlla il parametro IndexingRate in Amazon CloudWatch.

Se il tuo cluster gestisce troppe richieste di indicizzazione di massa, prendi in considerazione i seguenti approcci:

• Riduci il numero di richieste in blocco sul tuo cluster.
• Riduci le dimensioni di ogni richiesta di massa, in modo che i tuoi nodi possano elaborarle in modo più efficiente.
• Se Logstash viene utilizzato per inviare dati nel cluster di OpenSearch Service, riduci la dimensione del batch o il numero di lavoratori.
• Se la velocità di ingestione del cluster rallenta, ridimensiona il cluster (orizzontalmente o verticalmente). Per ampliare il tuo cluster, aumenta il numero di nodi e il tipo di istanza in modo che OpenSearch Service possa elaborare le richieste in arrivo.

Per ulteriori informazioni, consulta Bulk API sul sito Web di Elasticsearch.

Controlla il pool di thread di ricerca

Un pool di thread di ricerca che utilizza CPU elevata indica che le query di ricerca stanno sovraccaricando il cluster di OpenSearch Service. Il tuo cluster può essere sovraccarico da una singola query di lunga durata. Un aumento delle query eseguite dal cluster può influire anche sul pool di thread di ricerca.

Per verificare se una singola query aumenta l'utilizzo della CPU, utilizza l'API di gestione delle attività. Ad esempio:

GET _tasks?actions=*search&detailed

L'API di gestione delle attività recupera tutte le query di ricerca attive in esecuzione sul cluster. Per ulteriori informazioni, consulta API di gestione delle attività sul sito Web di Elasticsearch.

Nota: L'output include il campo della descrizione solo se è presente un'attività di ricerca elencata dall'API di gestione delle attività.

Esempio di output:

{
    "nodes": {
        "U4M_p_x2Rg6YqLujeInPOw": {
            "name": "U4M_p_x",
            "roles": [
                "data",
                "ingest"
            ],
            "tasks": {
                "U4M_p_x2Rg6YqLujeInPOw:53506997": {
                    "node": "U4M_p_x2Rg6YqLujeInPOw",
                    "id": 53506997,
                    "type": "transport",
                    "action": "indices:data/read/search",
                    "description": """indices[*], types[], search_type[QUERY_THEN_FETCH], source[{"size":10000,"query":{"match_all":{"boost":1.0}}}]""",
                    "start_time_in_millis": 1541423217801,
                    "running_time_in_nanos": 1549433628,
                    "cancellable": true,
                    "headers": {}
                }
            }
        }
    }
}

Controlla il campo della descrizione per identificare quale query viene eseguita. Il campo running_time_in_nanos indica la quantità di tempo in cui è stata eseguita una query. Per ridurre l'utilizzo della CPU, annulla la query di ricerca che richiede un elevato consumo di CPU. L'API di gestione delle attività supporta anche una chiamata _cancel.

Nota: Assicurati di registrare l'ID dell'attività dall'output per annullare una determinata attività. In questo esempio, l'ID dell'attività è "U4M\ _p\ _x2Rg6YqLujeInPOw:53506997".

Esempio di chiamata POST per la gestione delle attività:

POST _tasks/U4M_p_x2Rg6YqLujeInPOw:53506997/_cancel

La chiamata POST per la gestione delle attività contrassegna l'attività come "annullata", rilasciando tutte le risorse AWS dipendenti. Se nel cluster sono in esecuzione più query, utilizza la chiamata POST per annullare le query una alla volta. Annulla ogni query finché il cluster non ritorna a uno stato normale. È inoltre consigliabile impostare un valore di timeout nel corpo della query, per evitare picchi elevati della CPU. Per ulteriori informazioni, consulta Parametri di ricerca nel corpo della richiesta sul sito Web di Elasticsearch. Per verificare se il numero di query attive è diminuito, controlla la metrica SearchRate in Amazon CloudWatch.

Nota: L'annullamento di tutte le query di ricerca attive contemporaneamente nel cluster di OpenSearch Service può causare errori sul lato dell'applicazione client.

Per ulteriori informazioni, consulta Pool di thread sul sito Web di Elasticsearch.

Controlla il pool di thread di unione di Apache Lucene

OpenSearch Service utilizza Apache Lucene per l'indicizzazione e la ricerca di documenti nel cluster. Apache Lucene esegue operazioni di unione per ridurre il numero effettivo di segmenti necessari per ogni shard e per rimuovere eventuali documenti eliminati. Questo processo viene eseguito ogni volta che vengono creati nuovi segmenti in uno shard.

Se vedi che un'operazione di thread di unione di Apache Lucene influisce sull'utilizzo della CPU, aumenta l'impostazione refresh_interval degli indici del cluster OpenSearch Service. L'aumento dell'impostazione refresh_interval rallenta la creazione di segmenti del cluster.

Nota: Un cluster che migra gli indici allo storage UltraWarm può aumentare l'utilizzo della CPU. Una migrazione UltraWarm di solito comporta un'operazione API di unione forzata, che può richiedere un utilizzo intensivo della CPU.

Per verificare le migrazioni UltraWarm, usa il seguente comando:

GET _ultrawarm/migration/_status?v

Per ulteriori informazioni, consulta Unione sul sito Web di Elasticsearch.

Controlla la pressione della memoria JVM

Controlla la percentuale di pressione della memoria JVM dell'heap Java in un nodo del cluster. Se la pressione della memoria JVM raggiunge il 75%, Amazon OpenSearch Service attiva il garbage collector CMS (Concurrent Mark Sweep). Se la pressione della memoria JVM raggiunge il 100%, OpenSearch Service JVM viene configurato per uscire ed eventualmente riavviarsi su OutOfMemory (OOM).

Nel seguente registro di esempio, la JVM rientra nell'intervallo consigliato, ma il cluster è influenzato dalla rimozione di oggetti inutili a lungo termine:

[2022-06-28T10:08:12,066][WARN ][o.o.m.j.JvmGcMonitorService]
[515f8f06f23327e6df3aad7b2863bb1f] [gc][6447732] overhead, spent [9.3s]
collecting in the last [10.2s]

Per ulteriori informazioni, consulta Come faccio a risolvere l'elevata pressione della memoria JVM sul mio cluster Amazon OpenSearch Service?

Rivedi la tua strategia di partizione

A seconda delle dimensioni del cluster, le prestazioni del cluster potrebbero peggiorare a causa di troppe partizioni. È consigliabile non avere più di 25 shard per GiB di heap Java.

Per impostazione predefinita, Amazon OpenSearch Service ha una strategia di partizione di 5:1, in cui ogni indice è diviso in cinque partizione principali. All'interno di ogni indice, ogni partizione primario ha anche una propria replica. OpenSearch Service assegna automaticamente gli partizione primari e gli partizione di replica a nodi di dati separati e garantisce che sia disponibile un backup in caso di errore.

Per ulteriori informazioni, consulta Come faccio a ribilanciare la distribuzione irregolare delle partizioni nel mio cluster Amazon OpenSearch Service?

Ottimizza le tue domande

Le aggregazioni pesanti, le query con caratteri jolly (in particolare i caratteri jolly principali) e le query regex potrebbero essere costose dal punto di vista computazionale e causare picchi di utilizzo della CPU. La ricerca di log lenti e l'indicizzazione degli slow log possono aiutarti a diagnosticare query costose e problematiche.

Per ulteriori informazioni, consulta Monitoraggio dei log di OpenSearch con Amazon CloudWatch Logs.

Informazioni correlate

Come faccio a migliorare le prestazioni di indicizzazione sul mio cluster Amazon OpenSearch Service?

Come faccio a risolvere i rifiuti di ricerca o scrittura in Amazon OpenSearch Service?

Dimensionamento dei domini Amazon OpenSearch Service