Wie behebe ich Ablehnungen von Such- oder Schreibanforderungen in OpenSearch Service?

Kurzbeschreibung

Wenn du in deinem OpenSearch Service-Cluster Daten schreibst oder danach suchst, erhältst du möglicherweise den folgenden HTTP 429-Fehler oder 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]]"

Die folgenden Variablen können zu einem HTTP 429-Fehler oder zu es_rejected_execution_exception beitragen:

• Instance-Typen von Datenknoten und Such- oder Schreibgrenzen
• Hohe Werte für Instance-Metriken
• Aktive Threads und Threads in der Warteschlange
• Hohe CPU-Auslastung und JVM-Speicherauslastung

HTTP 429-Fehler können aufgrund von **Such **- und Schreib-Anforderungen an deinen Cluster auftreten. Ablehnungen können auch von einem einzelnen Knoten oder mehreren Knoten des Clusters stammen.

Hinweis: Verschiedene Versionen von Elasticsearch verwenden unterschiedliche Thread-Pools, um Aufrufe der _index-API zu verarbeiten. Die Elasticsearch-Versionen 1.5 und 2.3 verwenden den Index-Thread-Pool. Die Elasticsearch-Versionen 5.x, 6.0 und 6.2 verwenden den Massen-Thread-Pool. Elasticsearch-Versionen 6.3 und höher verwenden den Schreib-Thread-Pool. Weitere Informationen findest du unter Thread pool auf der Elasticsearch-Website.

Lösung

Instance-Typen von Datenknoten und Such- oder Schreibgrenzen

Der Instance-Typ eines Datenknotens hat feste virtuelle CPUs (vCPUs). Gib die vCPU-Anzahl in deine Formel ein, um die gleichzeitigen Such- oder Schreib-Vorgänge abzurufen, die dein Knoten ausführen kann, bevor der Knoten in eine Warteschlange eintritt. Wenn ein aktiver Thread voll ist, wird der Thread in eine Warteschlange übertragen und schließlich abgelehnt. Weitere Informationen zur Beziehung zwischen vCPUs und Knotentypen findest du unter OpenSearch Service-Preise.

Darüber hinaus gibt es einen Grenzwert für die Anzahl der Suchen pro Knoten oder Schreibvorgänge pro Knoten, die du durchführen kannst. Dieser Grenzwert basiert auf der Thread-Pool-Definition und der Elasticsearch-Versionsnummer. Weitere Informationen findest du unter Thread pool auf der Elasticsearch-Website.

Wenn du beispielsweise den Knotentyp R5.2xlarge für fünf Knoten in deinem Elasticsearch-Cluster (Version 7.4) wählst, hat der Knoten 8 vCPUs.

Verwende die folgende Formel, um die maximale Anzahl aktiver Threads für Such-Anforderungen zu berechnen:

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

Verwende die folgende Formel, um die maximale Anzahl aktiver Threads für Schreib-Anforderungen zu berechnen:

int (# of available_processors)

Bei einem R5.2xlarge-Knoten kannst du maximal 13 Such-Vorgänge ausführen:

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

Bei einem R5.2xlarge-Knoten kannst du maximal 8 Schreib-Vorgänge ausführen:

8 VCPUs = 8 operations

Bei einem OpenSearch Service-Cluster mit fünf Knoten kannst du maximal 65 **Such-**Vorgänge ausführen:

5 nodes * 13 = 65 operations

Bei einem OpenSearch Service-Cluster mit fünf Knoten kannst du maximal 40 **Schreib-**Vorgänge ausführen:

5 nodes * 8 = 40 operations

Hohe Werte für Instance-Metriken

Überprüfe die folgenden Amazon CloudWatch-Metriken für deinen Cluster, um deine 429-Ausnahme zu beheben:

• IndexingRate: Die Anzahl der Indizierungsvorgänge pro Minute. Ein einziger Aufruf der**_bulk**-API, der zwei Dokumente hinzufügt und zwei aktualisiert, zählt als vier Operationen, die sich über Knoten verteilen können. Wenn dieser Index über ein oder mehrere Replikate verfügt, zeichnen auch andere Knoten im Cluster insgesamt vier Indizierungsvorgänge auf. Das Löschen von Dokumenten wird bei der IndexingRate-Metrik nicht berücksichtigt.
• SearchRate: Die Gesamtzahl der Suchanforderungen pro Minute für alle Shards auf einem Datenknoten. Ein einziger Aufruf der _search-API kann Ergebnisse von vielen verschiedenen Shards zurückgeben. Wenn sich fünf verschiedene Shards auf einem Knoten befinden, meldet der Knoten „5" für diese Metrik, auch wenn der Client nur eine Anforderung gestellt hat.
• CoordinatingWriteRejected: Die Gesamtzahl der Ablehnungen, die auf dem koordinierenden Knoten aufgetreten sind. Diese Ablehnungen werden durch den Indizierungsdruck verursacht, der sich seit dem Start des OpenSearch-Services akkumuliert hat.
• PrimaryWriteRejected: Die Gesamtzahl der Ablehnungen, die bei den primären Shards aufgetreten sind. Diese Ablehnungen werden durch den Indizierungsdruck verursacht, der sich seit dem Start des letzten OpenSearch-Services akkumuliert hat.
• ReplicaWriteRejected: Die Gesamtzahl der Ablehnungen, die aufgrund des Indizierungsdrucks auf den Replikat-Shards aufgetreten sind. Diese Ablehnungen werden durch den Indizierungsdruck verursacht, der sich seit dem Start des letzten OpenSearch-Services akkumuliert hat.
• ThreadpoolWriteQueue: Die Anzahl der Aufgaben in der Warteschlange im Schreib-Thread-Pool. Diese Metrik gibt an, ob eine Anforderung aufgrund einer hohen CPU-Auslastung oder einer hohen Parallelität bei der Indizierung abgelehnt wird.
• ThreadpoolWriteRejected: Die Anzahl der abgelehnten Aufgaben im Schreib-Thread-Pool.
  Hinweis: Die Standardgröße der Schreibwarteschlange wurde in OpenSearch Service Version 7.9 von 200 auf 10 000 erhöht. Daher ist diese Metrik nicht mehr der einzige Indikator für Ablehnungen von OpenSearch Service. Verwende die Metriken CoordinatingWriteRejected, PrimaryWriteRejected und ReplicaWriteRejected, um Ablehnungen in Versionen 7.9 und höher zu überwachen.
• ThreadpoolSearchQueue: Die Anzahl der Aufgaben in der Warteschlange im Such-Thread-Pool. Wenn die Warteschlangengröße konstant hoch ist, solltest du erwägen, den Cluster zu skalieren. Die maximale Größe der Suchwarteschlange beträgt 1 000.
• ThreadpoolSearchRejected: Die Anzahl der abgelehnten Aufgaben im Such-Thread-Pool. Wenn diese Zahl kontinuierlich wächst, solltest du erwägen, den Cluster zu skalieren.
• JVMMemoryPressure: Die JVM-Speicherauslastung gibt den Prozentsatz des Java-Heaps in einem Cluster-Knoten an. Wenn die JVM-Speicherauslastung 75 % erreicht, initiiert OpenSearch Service den Concurrent Mark Sweep (CMS)-Garbage Collector. Die Garbage Collection ist ein CPU-intensiver Prozess. Wenn die JVM-Speicherauslastung einige Minuten lang bei diesem Prozentsatz bleibt, treten möglicherweise Probleme mit der Cluster-Leistung auf. Weitere Informationen findest du unter Wie behebe ich eine hohe JVM-Speicherauslastung in meinem Amazon OpenSearch Service-Cluster?

Hinweis: Die aufgelisteten Thread-Pool-Metriken helfen dabei, dich über IndexingRate und SearchRate zu informieren.

Weitere Informationen zur Überwachung des OpenSearch Service-Clusters mit CloudWatch findest du unter Instance-Metriken.

Aktive Threads und Threads in der Warteschlange

Wenn es an CPUs mangelt oder eine hohe Parallelität von Anforderungen vorliegt, kann sich eine Warteschlange schnell füllen, was zu einem HTTP 429-Fehler führt. Um die Warteschlangen-Threads zu überwachen, überprüfe die Metriken ThreadpoolSearchQueue und ThreadpoolWriteQueue in CloudWatch.

Verwende den folgenden Befehl, um die aktiven Threads und die Threads in der Warteschlange auf Ablehnungen von Suchen zu überprüfen:

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

Um aktive Threads und Threads in der Warteschlange auf Ablehnung von Suchen zu überprüfen, ersetze „search“ durch „write“. Die abgelehnten und abgeschlossenen Werte in der Ausgabe sind kumulative Knotenzähler, die zurückgesetzt werden, wenn neue Knoten gestartet werden. Weitere Informationen findest du im Abschnitt Example with explicit columns (Beispiel mit expliziten Spalten) der Cat-Thread-Pool-API auf der Elasticsearch-Website.

Hinweis: Die Massenwarteschlange auf jedem Knoten kann zwischen 50 und 200 Anforderungen aufnehmen, je nachdem, welche Elasticsearch-Version du verwendest. Wenn die Warteschlange voll ist, werden neue Anforderungen abgelehnt.

Fehler bei Ablehnungen von Suchen und Schreibvorgängen

Ablehnungen von Suchen

Ein Fehler durch die Ablehnung von Suchen weist darauf hin, dass aktive Threads ausgelastet sind und die Warteschlangen bis zur maximalen Anzahl von Aufgaben gefüllt sind. Daher kann deine Suchanforderung abgelehnt werden. Du kannst OpenSearch Service-Protokolle so konfigurieren, dass diese Fehlermeldungen in den Protokollen für langsame Suchen erscheinen.

Hinweis: Um zusätzlichen Mehraufwand zu vermeiden, solltest du den Schwellenwert für langsames Protokollieren auf einen großzügigen Wert festlegen. Wenn beispielsweise die meisten der Anforderungen 11 Sekunden dauern und der Schwellenwert „10" ist, benötigt OpenSearch Service mehr Zeit, um ein Protokoll zu schreiben. Du kannst diesen Mehraufwand vermeiden, indem du den Schwellenwert für langsame Protokollierung auf 20 Sekunden setzt. Dann wird nur ein kleiner Prozentsatz der langsameren Anforderungen (die länger als 11 Sekunden dauern) protokolliert.

Nachdem der Cluster so konfiguriert wurde, dass langsame Suchprotokolle per Push an CloudWatch übertragen werden, lege einen bestimmten Schwellenwert für die langsame Protokollgenerierung fest. Mit dem folgenden HTTP POST-Aufruf kannst du einen bestimmten Schwellenwert für die langsame Protokollgenerierung festlegen:

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

Ablehnungen von Schreibvorgängen

Eine 429-Fehlermeldung als Ablehnung von Schreib-Vorgängen weist auf einen Massenwarteschlangen-Fehler hin. Die es_rejected_execution_exception[bulk] gibt an, dass die Warteschlange voll ist und dass alle neuen Anforderungen abgelehnt werden. Dieser Massenwarteschlangenfehler tritt auf, wenn die Anzahl der Anforderungen an den Cluster die Größe der Massenwarteschlange (threadpool.bulk.queue_size) überschreitet. Eine Massenwarteschlange auf jedem Knoten kann zwischen 50 und 200 Anforderungen aufnehmen, je nachdem, welche Elasticsearch-Version du verwendest.

Du kannst OpenSearch Service-Protokolle so konfigurieren, dass diese Fehlermeldungen in den Protokollen für langsame Indizierungen erscheinen.

Hinweis: Um zusätzlichen Mehraufwand zu vermeiden, solltest du den Schwellenwert für langsames Protokollieren auf einen großzügigen Wert festlegen. Wenn beispielsweise die meisten der Anforderungen 11 Sekunden dauern und der Schwellenwert „10" ist, benötigt OpenSearch Service zusätzliche Zeit, um ein Protokoll zu schreiben. Du kannst diesen Mehraufwand vermeiden, indem du den Schwellenwert für langsame Protokollierung auf 20 Sekunden setzt. Dann wird nur ein kleiner Prozentsatz der langsameren Anforderungen (die länger als 11 Sekunden dauern) protokolliert.

Nachdem der Cluster so konfiguriert wurde, dass langsame Suchprotokolle per Push an CloudWatch übertragen werden, lege einen bestimmten Schwellenwert für die langsame Protokollgenerierung fest. Verwende den folgenden HTTP POST-Aufruf, um einen bestimmten Schwellenwert für die langsame Protokollgenerierung festzulegen:

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

Bewährte Methoden für Ablehnungen von Schreibvorgängen

Im Folgenden findest du einige bewährte Methoden, um Ablehnungen von Schreibvorgängen zu vermeiden:

• Wenn Dokumente schneller indiziert werden, ist es weniger wahrscheinlich, dass die Schreibwarteschlange ihre Kapazität erreicht.
• Passe die Massengröße an die Workload und die gewünschte Leistung an. Weitere Informationen findest du unter Tune for indexing speed (Indizierungsgeschwindigkeit optimieren) auf der Elasticsearch-Website.
• Füge der Anwendungslogik eine exponentielle Wiederholungslogik hinzu. Die exponentielle Wiederholungslogik stellt sicher, dass fehlgeschlagene Anforderungen automatisch wiederholt werden.
  Hinweis: Wenn der Cluster kontinuierlich viele gleichzeitige Anforderungen hat, hilft die exponentielle Wiederholungslogik nicht, den 429-Fehler zu beheben. Verwende diese bewährte Methode, wenn es zu plötzlichen oder gelegentlichen Spitzenwerten im Datenverkehr kommt.
• Wenn du Daten aus Logstash aufnimmst, passe die Anzahl der Worker und die Massengröße an. Es hat sich bewährt, die Massengröße zwischen 3 und 5 MB festzulegen.

Weitere Informationen zur Optimierung der Indizierungsleistung findest du unter Wie kann ich die Indizierungsleistung auf meinem OpenSearch Service-Cluster verbessern?

Bewährte Methoden zur Ablehnung von Suchen

Im Folgenden findest du einige bewährte Methoden, mit denen Ablehnungen von Suchen vermieden werden können:

• Wechsle zu einem größeren Instance-Typ. OpenSearch Service ist stark auf den Dateisystem-Cache angewiesen, um schnellere Suchergebnisse zu erzielen. Die Anzahl der Threads im Thread-Pool auf jedem Knoten für Suchanforderungen entspricht der folgenden: int((# of available_processors * 3) / 2) + 1. Wechsle zu einer Instance mit mehr vCPUs, um mehr Threads zur Verarbeitung von Such-Anforderungen zu erhalten.
• Aktiviere langsame Suchprotokolle für einen bestimmten Index oder für alle Indizes mit einem angemessenen Schwellenwert. Prüfe, welche Abfragen länger brauchen, um ausgeführt zu werden, und implementiere Strategien zur Suchleistung für die Abfragen. Weitere Informationen findest du unter Troubleshooting Elasticsearch searches, for beginners (Problembehandlung bei Elasticsearch-Suchen für Anfänger) oder unter Advanced tuning: Finding and fixing slow Elasticsearch queries (Optimierung für Fortgeschrittene: Langsame Elasticsearch-Abfragen finden und korrigieren) auf der Elasticsearch-Website.