Wie behebe ich Probleme mit hoher CPU-Auslastung in meinem Amazon OpenSearch Service-Cluster?

Lesedauer: 7 Minute

Meine Datenknoten weisen eine hohe CPU-Auslastung in meinem Amazon OpenSearch Service-Cluster auf.

Kurzbeschreibung

Es hat sich bewährt, die CPU-Auslastung beizubehalten, um sicherzustellen, dass OpenSearch Service über genügend Ressourcen verfügt, um seine Aufgaben auszuführen. Ein Cluster, der konsistent mit hoher CPU-Auslastung arbeitet, kann die Clusterleistung beeinträchtigen. Wenn Ihr Cluster überlastet ist, reagiert OpenSearch Service nicht mehr, was zu einer Timeout-Anfrage führt.

Um eine hohe CPU-Auslastung in Ihrem Cluster zu beheben, sollten Sie die folgenden Ansätze in Betracht ziehen:

Verwenden Sie die Knoten-Hot-Threads-API.
Überprüfen Sie den Schreib-Vorgang oder den Sammel-API-Thread-Pool.
Überprüfen Sie den Such-Thread-Pool.
Überprüfen Sie den Merge-Thread-Pool von Apache Lucene.
Überprüfen Sie den JVM-Speicherdruck.
Überprüfen Sie Ihre Sharding-Strategie.
Optimieren Sie Ihre Abfragen.

Lösung

Verwenden Sie die Knoten-Hot-Threads-API

Wenn in Ihrem OpenSearch Service-Cluster ständige CPU-Spitzen auftreten, verwenden Sie die Knoten-Hot-Threads-API. Die Knoten-Hot-Threads-API fungiert als Task-Manager und zeigt Ihnen die Aufschlüsselung aller ressourcenintensiven Threads an, die in Ihrem Cluster ausgeführt werden.

Beispielausgabe der Knoten-Hot-Threads-API:

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)

Hinweis: Die Knoten-Hot-Thread-Ausgabe listet Informationen für jeden Knoten auf. Die Länge Ihrer Ausgabe hängt davon ab, wie viele Knoten in Ihrem OpenSearch Service-Cluster ausgeführt werden.

Verwenden Sie außerdem die Cat-Knoten-API, um die aktuelle Aufschlüsselung der Ressourcennutzung einzusehen. Mit dem folgenden Befehl können Sie die Teilmenge der Knoten mit der höchsten CPU-Auslastung eingrenzen:

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

In der letzten Spalte in Ihrer Ausgabe wird Ihr Knotenname angezeigt. Weitere Informationen finden Sie unter Cat-Knoten-API auf der Elasticsearch-Website.

Geben Sie dann den entsprechenden Knotennamen an Ihre Hot-Threads-API weiter:

GET _nodes/<node-name>/hot_threads

Weitere Informationen finden Sie unter Hot-Threads-API auf der Elasticsearch-Website.

Beispiel für die Ausgabe von Knoten-Hot-Threads:

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

Der Thread-Name gibt an, welche OpenSearch Service-Prozesse viel CPU-Leistung verbrauchen.

Weitere Informationen finden Sie unter Knoten-Hot-Threads-API auf der Elasticsearch-Website.

Überprüfen Sie den Schreibvorgang oder den Sammel-API-Thread-Pool

Ein Fehler 429 im OpenSearch Service kann darauf hinweisen, dass Ihr Cluster zu viele Sammelindexierungsanfragen verarbeitet. Wenn in Ihrem Cluster ständige CPU-Spitzen auftreten, lehnt OpenSearch Service die Sammelindexierungsanfragen ab.

Der Schreib-Thread-Pool verarbeitet Indexierungsanfragen, zu denen auch Sammel-API-Operationen gehören. Um zu überprüfen, ob Ihr Cluster zu viele Sammelindexierungsanfragen verarbeitet, überprüfen Sie die IndexingRate-Metrik in Amazon CloudWatch.

Wenn Ihr Cluster zu viele Sammelindexierungsanfragen verarbeitet, sollten Sie die folgenden Ansätze in Betracht ziehen:

Reduzieren Sie die Anzahl der Sammelanfragen in Ihrem Cluster.
Reduzieren Sie die Größe jeder Sammelanfrage, damit Ihre Knoten sie effizienter verarbeiten können.
Wenn Logstash verwendet wird, um Daten in Ihren OpenSearch Service-Cluster zu übertragen, reduzieren Sie die Batchgröße oder die Anzahl der Worker.
Wenn sich die Aufnahmerate Ihres Clusters verlangsamt, skalieren Sie Ihren Cluster (entweder horizontal oder vertikal). Um Ihren Cluster hoch zu skalieren, erhöhen Sie die Anzahl der Knoten und den Instance-Typ, damit OpenSearch Service die eingehenden Anfragen verarbeiten kann.

Weitere Informationen finden Sie unter Sammel-API auf der Elasticsearch-Website.

Überprüfen Sie den Such-Thread-Pool

Ein Such-Thread-Pool, der viel CPU-Leistung verbraucht, weist darauf hin, dass Suchanfragen Ihren OpenSearch Service-Cluster überfordern. Ihr Cluster kann durch eine einzige lang andauernde Abfrage überlastet werden. Eine Zunahme der von Ihrem Cluster ausgeführten Abfragen kann sich auch auf Ihren Such-Thread-Pool auswirken.

Um zu überprüfen, ob eine einzelne Abfrage Ihre CPU-Auslastung erhöht, verwenden Sie die Task-Management-API. Zum Beispiel:

GET _tasks?actions=*search&detailed

Die Task-Management-API ruft alle aktiven Suchanfragen ab, die in Ihrem Cluster ausgeführt werden. Weitere Informationen finden Sie unter Task-Management-API auf der Elasticsearch-Website.

Hinweis: Die Ausgabe enthält das Beschreibungsfeld nur dann, wenn eine Such-Aufgabe in der Task-Management-API aufgeführt ist.

Beispiel für eine Ausgabe:

{
    "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": {}
                }
            }
        }
    }
}

Überprüfen Sie das Feld Beschreibung, um festzustellen, welche Anfrage ausgeführt wird. Das Feld running_time_in_nanos gibt an, wie lange eine Anfrage ausgeführt wurde. Um Ihre CPU-Auslastung zu verringern, brechen Sie die Suchanfrage ab, die viel CPU-Leistung beansprucht. Die Task-Management-API unterstützt auch einen**_cancel**-Aufruf.

Hinweis: Stellen Sie sicher, dass Sie die Aufgaben-ID aus Ihrer Ausgabe aufzeichnen, um eine bestimmte Aufgabe abzubrechen. In diesem Beispiel lautet die Aufgaben-ID „U4M_p_x2Rg6YqLujeInPOw:53506997“.

Beispiel für einen task management POST-Aufruf:

POST _tasks/U4M_p_x2Rg6YqLujeInPOw:53506997/_cancel

Der task management POST-Aufruf kennzeichnet die Aufgabe als „abgebrochen“, wodurch alle abhängigen AWS-Ressourcen freigegeben werden. Wenn in Ihrem Cluster mehrere Anfragen ausgeführt werden, verwenden Sie den POST-Aufruf, um Anfragen nacheinander abzubrechen. Brechen Sie jede einzelne Anfrage ab, bis Ihr Cluster in einen normalen Zustand zurückkehrt. Es empfiehlt sich auch, im Abfragetext einen Timeout-Wert festzulegen, um hohe CPU-Spitzen zu vermeiden. Weitere Informationen finden Sie auf der Elasticsearch-Website unter Textsuchparameter für Anfragen. Um zu überprüfen, ob die Anzahl der aktiven Anfragen gesunken ist, überprüfen Sie die SearchRate-Metrik in Amazon CloudWatch.

Hinweis: Das gleichzeitige Abbrechen aller aktiven Suchanfragen in Ihrem OpenSearch Service-Cluster kann zu Fehlern auf Seite der Client-Anwendung führen.

Weitere Informationen finden Sie unter Thread-Pools auf der Elasticsearch-Website.

Überprüfen Sie den Merge-Thread-Pool von Apache Lucene

OpenSearch Service verwendet Apache Lucene für die Indexierung und Suche von Dokumenten in Ihrem Cluster. Apache Lucene führt Merge-Vorgänge durch, um die effektive Anzahl von Segmenten zu reduzieren, die für jeden Shard benötigt werden, und um gelöschte Dokumente zu entfernen. Dieser Prozess wird immer dann ausgeführt, wenn neue Segmente in einem Shard erstellt werden.

Wenn Sie beobachten, dass sich ein Apache Lucene-Merge-Thread-Vorgang auf die CPU-Auslastung auswirkt, erhöhen Sie die Einstellung refresh_interval Ihrer OpenSearch Service-Cluster-Indizes. Die Erhöhung der Einstellung refresh_interval verlangsamt die Segmenterstellung Ihres Clusters.

Hinweis: Ein Cluster, der Indizes zu UltraWarm-Speicher migriert, kann Ihre CPU-Auslastung erhöhen. Eine UltraWarm-Migration beinhaltet normalerweise einen Force-Merge-API-Vorgang, der die CPU intensiv beanspruchen kann.

Verwenden Sie den folgenden Befehl, um nach UltraWarm-Migrationen zu suchen:

GET _ultrawarm/migration/_status?v

Weitere Informationen finden Sie unter Merge auf der Elasticsearch-Website.

Überprüfen Sie den JVM-Speicherdruck

Überprüfen Sie den Prozentsatz des JVM-Speicherdrucks des Java-Heaps in einem Clusterknoten. Wenn der JVM-Speicherdruck 75 % erreicht, löst Amazon OpenSearch Service den Concurrent Mark Sweep (CMS) Garbage Collector aus. Wenn der JVM-Speicherdruck 100 % erreicht, ist die OpenSearch Service-JVM so konfiguriert, dass sie beendet wird und schließlich bei OutOfMemory (OOM) neu gestartet wird.

Im folgenden Beispielprotokoll befindet sich die JVM innerhalb des empfohlenen Bereichs, der Cluster wird jedoch durch die lang andauernde Garbage Collection beeinträchtigt:

[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]

Weitere Informationen finden Sie unter Wie behebe ich einen hohen JVM-Speicherdruck in meinem Amazon OpenSearch Service-Cluster?

Überprüfen Sie Ihre Sharding-Strategie

Abhängig von der Clustergröße kann die Leistung Ihres Clusters durch zu viele Shards beeinträchtigt werden. Es hat sich bewährt, nicht mehr als 25 Shards pro GiB Java-Heap zu nutzen.

Standardmäßig nutzt Amazon OpenSearch Service eine Sharding-Strategie von 5:1, bei der jeder Index in fünf primäre Shards unterteilt ist. Innerhalb jedes Indizes hat jeder primäre Shard zudem sein eigenes Replikat. OpenSearch Service weist primäre Shards und Replikat-Shards automatisch separaten Datenknoten zu und stellt sicher, dass im Falle eines Fehlers ein Backup vorhanden ist.

Weitere Informationen finden Sie unter Wie gleiche ich die ungleichmäßige Shard-Verteilung in meinem Amazon OpenSearch Service-Cluster aus?

Optimieren Sie Ihre Abfragen

Starke Aggregationen, Platzhalterabfragen (insbesondere führende Platzhalter) und Regex-Abfragen können rechenintensiv sein und zu Spitzen bei der CPU-Auslastung führen. Die Suche nach langsamen Protokollen und die Indexierung langsamer Protokolle können Ihnen helfen, teure und problematische Abfragen zu diagnostizieren.

Weitere Informationen finden Sie unter Überwachen von OpenSearch-Protokollen mit Amazon CloudWatch Logs.

Relevanter Inhalt

Wie behebe ich Probleme mit Softwareupdates für OpenSearch?
AWS OFFICIALAktualisiert vor 10 Monaten
Wie behebe ich einen hohen JVM-Speicherdruck in meinem OpenSearch Service-Cluster?
AWS OFFICIALAktualisiert vor einem Jahr
Wie behebe ich feinkörnige Probleme mit der Zugriffskontrolle in meinem OpenSearch Service-Cluster?
AWS OFFICIALAktualisiert vor einem Jahr
Wie behebe ich Probleme mit hoher CPU-Auslastung in Amazon Redshift?
AWS OFFICIALAktualisiert vor 2 Jahren