Come posso risolvere i problemi di utilizzo elevato della CPU nel mio cluster del Servizio OpenSearch di Amazon?

Breve descrizione

È consigliabile controllare l'utilizzo della CPU in modo che il Servizio OpenSearch disponga di risorse sufficienti per eseguire le proprie attività. Un cluster che utilizza costantemente molta CPU può ridurre le prestazioni del cluster. Quando il cluster è sovraccarico, il Servizio OpenSearch smette di rispondere, con conseguente richiesta di timeout.

Per risolvere i problemi relativi all'utilizzo elevato della CPU da parte di cluster, intraprendi le seguenti azioni:

• Utilizza un runbook di automazione.
• Utilizza l'API nodes hot threads.
• 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.
• Esamina la strategia di sharding.
• Ottimizza le query.

Risoluzione

Utilizza un runbook di automazione

Utilizza il runbook di automazione AWSSupport-TroubleshootOpenSearchHighCPU di AWS Systems Manager per risolvere l'utilizzo elevato della CPU nel Servizio OpenSearch.

Nota: prima di utilizzare il runbook, consulta le sezioni Required AWS Identity and Access Management (IAM) permissions (Autorizzazioni AWS Identity and Access Management (AWS IAM) richieste) e Instructions (Istruzioni) in AWSSupport-TroubleshootOpenSearchHighCPU.

L'output mostra le seguenti informazioni:

• Thread attivi.
• Attività attualmente in esecuzione.
• Statistiche del pool di thread per ogni nodo del dominio.
• Informazioni sui nodi del dominio ordinate in base all'utilizzo della CPU.
• Allocazione di shard a ciascun nodo di dati e relativo spazio su disco.
• Stato di integrità e informazioni sullo stato di integrità del dominio del Servizio OpenSearch.

Utilizza l'output del runbook per identificare la causa dell'utilizzo elevato della CPU.

Utilizza l'API nodes hot threads

Se sono presenti picchi costanti nell'utilizzo della CPU da parte del cluster del Servizio OpenSearch, utilizza l'API nodes hot threads. Per ulteriori informazioni, consulta Nodes hot threads API (API nodes hot threads) sul sito web di Elastic.

Esempio di output:

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 informazioni per ogni nodo. La lunghezza dell'output dipende dal numero di nodi in esecuzione nel cluster del Servizio OpenSearch.

Puoi anche utilizzare l'API cat nodes per visualizzare l'attuale ripartizione dell'utilizzo delle risorse. Puoi restringere il sottoinsieme di nodi con il massimo utilizzo della CPU utilizzando il seguente comando:

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

L'ultima colonna dell'output mostra il nome del nodo. Per ulteriori informazioni, consulta Cat nodes API (API cat nodes) sul sito web di Elastic.

Passa il nome del nodo corrispondente all'API hot threads:

GET _nodes/<node-name>/hot_threads

Per ulteriori informazioni, consulta Hot threads API (API hot threads) sul sito web di Elastic.

Esempio di output:

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

Il nome del thread indica i processi del Servizio OpenSearch con un utilizzo elevato della CPU.

Controlla il pool di thread di scrittura o delle operazioni API in blocco

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

Il pool di thread di scrittura gestisce le richieste di indicizzazione, comprese le operazioni API in blocco. Per verificare se il cluster sta gestendo troppe richieste di indicizzazione in blocco, controlla la metrica IndexingRate in Amazon CloudWatch.

Se il cluster sta gestendo troppe richieste di indicizzazione in blocco, intraprendi le seguenti azioni:

• Riduci il numero di richieste in blocco sul cluster.
• Riduci le dimensioni di ogni richiesta in blocco, in modo che i nodi possano elaborarle in maniera più efficiente.
• Se utilizzi Logstash per inviare dati al cluster del Servizio OpenSearch, riduci la dimensione del batch o il numero di worker.
• Se la velocità di assimilazione del cluster diminuisce, aumenta verticalmente od orizzontalmente il cluster. Per aumentare verticalmente il cluster, aumenta il numero di nodi e il tipo di istanza in modo che il Servizio OpenSearch possa elaborare le richieste in arrivo.

Per ulteriori informazioni, consulta Bulk API (API in blocco) sul sito web di Elastic.

Controlla il pool di thread di ricerca

Un pool di thread di ricerca che ha un utilizzo elevato della CPU indica che le query di ricerca stanno sovraccaricando il cluster del Servizio OpenSearch. Una singola query di lunga durata può sovraccaricare il cluster. Analogamente, un aumento delle query eseguite dal cluster può influire sul pool di thread di ricerca.

Per verificare se una singola query aumenta l'utilizzo della CPU, utilizza l'API task management:

GET _tasks?actions=*search&detailed

L'API task management recupera tutte le query di ricerca attive in esecuzione sul cluster. Per ulteriori informazioni, consulta Task management API (API task management) sul sito web di Elastic.

Nota: se è presente un'attività di ricerca che viene elencata dall'API task management, l'output include solo il campo della descrizione.

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 description per identificare la query in esecuzione. Il campo running_time_in_nanos indica la durata dell'esecuzione della query. Per ridurre l'utilizzo della CPU, annulla la query di ricerca che utilizza troppa CPU. L'API task management supporta anche una chiamata _cancel.

Nota: per annullare un'attività, annota l'ID dell'attività indicato nell'output. Nell'esempio seguente, l'ID dell'attività è U4M_p_x2Rg6YqLujeInPOw:53506997.

Esempio di chiamata:

POST _tasks/U4M_p_x2Rg6YqLujeInPOw:53506997/_cancel

La chiamata Task Management POST contrassegna l'attività come "annullata", liberando tutte le risorse AWS dipendenti. Se sul cluster sono in esecuzione più query, utilizza la chiamata POST per annullare ogni query fino a quando il cluster non torna a uno stato normale.

È inoltre consigliabile impostare un valore di timeout nel corpo della query per evitare picchi di utilizzo della CPU. Per ulteriori informazioni, consulta Parameters (Parametri) sul sito web di Elastic. Per verificare se il numero di query attive è diminuito, controlla la metrica SearchRate in CloudWatch. Per ulteriori informazioni, consulta Thread pools (Pool di thread) sul sito web di Elastic.

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

Controlla il pool di thread di unione di Apache Lucene

Il Servizio OpenSearch utilizza Apache Lucene per indicizzare e cercare documenti nel cluster. Quando si creano nuovi segmenti di shard, Apache Lucene esegue operazioni di unione (merge9 per ridurre il numero effettivo di segmenti per ogni shard e rimuovere i documenti eliminati.

Se un'operazione merge di Apache Lucene influisce sull'utilizzo della CPU, aumenta l'impostazione refresh_interval degli indici del cluster del Servizio OpenSearch. L'aumento dell'impostazione refresh_interval rallenta la creazione di segmenti del cluster. Per ulteriori informazioni, consulta index.refresh_interval sul sito web di Elastic.

Nota: un cluster che esegue la migrazione degli indici verso lo storage UltraWarm può comportare un aumento dell'utilizzo della CPU. Una migrazione UltraWarm di solito implica un'operazione API di forzatura dell'unione (force merge), che può richiedere un utilizzo intensivo della CPU. Per ulteriori informazioni, consulta l'API force merge sul sito web di Elastic.

Per verificare le migrazioni verso UltraWarm, utilizza il seguente comando:

GET _ultrawarm/migration/_status?v

Per ulteriori informazioni, consulta Merge (Unione) sul sito web di Elastic.

Controlla l'utilizzo della memoria JVM

Esamina la percentuale di pressione della memoria JVM dell'heap Java in un nodo del cluster. Se la pressione della memoria JVM raggiunge il 75%, il Servizio OpenSearch di Amazon avvia la rimozione di oggetti inutili (garbage collector) CMS (Concurrent Mark Sweep). Se la pressione della memoria JVM raggiunge il 100%, la JVM del Servizio OpenSearch si chiude e infine si riavvia per una condizione OOM (OutOfMemory).

Nel seguente esempio di log, la JVM è nell'intervallo consigliato, ma una rimozione di oggetti inutili (garbage collection a lungo termine sta influendo sul cluster:

[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 posso risolvere l'elevata pressione della memoria JVM sul mio cluster del Servizio OpenSearch di Amazon?

Rivedi la strategia di sharing

A seconda delle dimensioni del cluster, le prestazioni del cluster potrebbero ridursi a causa del numero eccessivo di shard. È consigliabile avere solamente fino a un massimo di 25 shard per GiB di heap Java.

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

Per maggiori informazioni, consulta In che modo posso riequilibrare la distribuzione non uniforme degli shard nel mio cluster del Servizio OpenSearch di Amazon?

Ottimizza le query

Le aggregazioni pesanti, le query con caratteri jolly come i caratteri jolly iniziali e le query regex potrebbero causare picchi di utilizzo della CPU. Per diagnosticare le query, cerca e indicizza i log lenti. Per ulteriori informazioni, consulta Monitoraggio dei log 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