Wie behebe ich Such- oder Schreibablehnungen bei Amazon OpenSearch Service?

Lesedauer: 9 Minute
0

Wenn ich eine Such- oder Schreibanfrage an meinen Amazon-OpenSearch-Service-Cluster sende, werden die Anfragen abgelehnt. Woran liegt das?

Kurzbeschreibung

Wenn Sie in Ihrem OpenSearch-Service-Cluster nach Daten suchen oder Daten schreiben, wird möglicherweise der folgende HTTP 429-Fehler oder es_rejected_execution_exception angezeigt:

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 es_rejected_execution_exception beitragen:

  • Datenknoten-Instance-Typen und Such- oder Schreiblimits
  • Hohe Werte für Instance-Metriken
  • Aktive und Warteschlangen-Threads

HTTP-429-Fehler können aufgrund von Such- und Schreibanforderungen an Ihren Cluster auftreten. Ablehnungen können auch von einem oder mehreren Knoten Ihres Clusters stammen.

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

Auflösung

Datenknoten-Instance-Typen und Such- oder Schreiblimits

Ein Datenknoten-Instance-Typ hat feste virtuelle CPUs (vCPUs). Schließen Sie die vCPU-Anzahl in Ihre Formel ein, um die gleichzeitigen Such- oder Schreibvorgänge, die Ihr Knoten ausführen kann, abzurufen, bevor der Knoten in eine Warteschlange gelangt. Wenn ein aktiver Thread voll wird, läuft der Thread in eine Warteschlange über und wird schließlich abgelehnt. Weitere Informationen zur Beziehung zwischen vCPUs und Knotentypen finden Sie unter OpenSearch-Service-Preisgestaltung.

Zusätzlich gibt es ein Limit, wie viele Suchvorgänge pro Knoten oder Schreibvorgänge pro Knoten durchgeführt werden können. Dieses Limit basiert auf der Definition des Thread-Pools und der Elasticsearch-Versionsnummer. Weitere Informationen finden Sie unter Thread-Pool auf der Elasticsearch-Website.

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

Verwenden Sie die folgende Formel, um die maximalen aktiven Threads für Suchabfragen zu berechnen:

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

Verwenden Sie die folgende Formel, um die maximalen aktiven Threads für Schreibanforderungen zu berechnen:

int (# of available_processors)

Daher können Sie für einen R5.2xlarge-Knoten maximal 13 Suchvorgänge ausführen:

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

Für einen R5.2xlarge-Knoten können Sie maximal 8 Schreibvorgänge ausführen:

8 VCPUs = 8 operations

Für einen OpenSearch-Service-Cluster mit fünf Knoten können Sie dann maximal 65 Suchvorgänge ausführen:

5 nodes * 13 = 65 operations

Für einen OpenSearch-Service-Cluster mit fünf Knoten können Sie dann maximal 40 Schreibvorgänge ausführen:

5 nodes * 8 = 40 operations

Hohe Werte für Instance-Metriken

Um Ihre 429-Ausnahme zu beheben, überprüfen Sie die folgenden Amazon-CloudWatch-Metriken für Ihren Cluster:

  • IndexingRate: Die Anzahl der Indexierungsvorgänge pro Minute. Ein einzelner Aufruf der _bulk-API, der zwei Dokumente hinzufügt und zwei aktualisiert, zählt als vier Vorgänge, die über einen oder mehrere Knoten verteilt werden können. Wenn dieser Index über eine oder mehrere Replikate verfügt, zeichnen andere Knoten im Cluster ebenfalls insgesamt vier Indexierungsvorgänge auf. Löschungen von Dokumenten werden nicht für die IndexingRate-Metrik angerechnet.
  • SearchRate: Die Gesamtzahl der Suchabfragen pro Minute für alle Shards auf einem Datenknoten. Ein einzelner Aufruf der _search-API kann Ergebnisse von vielen verschiedenen Shards zurückgeben. Wenn sich fünf verschiedene Shards auf einem Knoten befinden, meldet dann der Knoten „5“ für diese Metrik, auch wenn der Client nur eine Abfrage gestellt hat.
  • CoordinatingWriteRejected: Die Gesamtzahl der Ablehnungen, die auf dem koordinierenden Knoten aufgetreten sind. Diese Ablehnungen werden durch den Indexierungsdruck verursacht, der sich seit dem Start des OpenSearch Service angesammelt hat.
  • PrimaryWriteRejected: Die Gesamtzahl der Ablehnungen, die auf den primären Shards aufgetreten sind. Diese Ablehnungen werden durch den Indexierungsdruck verursacht, der sich seit dem letzten Start des OpenSearch Service angesammelt hat.
  • ReplicaWriteRejected: Die Gesamtzahl der Ablehnungen, die aufgrund des Indexierungsdrucks auf den Replikat-Shards aufgetreten sind. Diese Ablehnungen werden durch den Indexierungsdruck verursacht, der sich seit dem letzten Start des OpenSearch Service angesammelt hat.
  • ThreadpoolWriteQueue: Die Anzahl der Aufgaben in der Warteschlange im Schreib-Thread-Pool. Diese Metrik informiert Sie darüber, ob eine Abfrage aufgrund einer hohen CPU-Auslastung oder einer hohen Indexierungs-Parallelität abgelehnt wird.
  • ThreadpoolWriteRejected: Die Anzahl der abgelehnten Aufgaben im Schreib-Thread-Pool.
    Hinweis: Die standardmäßige Größ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. Verwenden Sie die Metriken CoordinatingWriteRejected, PrimaryWriteRejected und ReplicaWriteRejected, um Ablehnungen in den Versionen 7.9 und höher zu überwachen. Weitere Informationen finden Sie unter UltraWarm-Metriken.
  • ThreadpoolSearchQueue: Die Anzahl der Aufgaben in der Warteschlange im Such-Thread-Pool. Wenn die Warteschlangengröße konstant hoch ist, sollten Sie eine Skalierung Ihres Clusters in Betracht ziehen. Die maximale Größe der Suchwarteschlange beträgt 1 000.
  • ThreadpoolSearchRejected: Die Anzahl der abgelehnten Aufgaben im Such-Thread-Pool. Wenn diese Zahl kontinuierlich ansteigt, erwägen Sie eine Skalierung Ihres Clusters.

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

Weitere Informationen zur Überwachung Ihres OpenSearch-Service-Clusters mit Amazon CloudWatch finden Sie unter Instance-Metriken.

Aktive und Warteschlangen-Threads

Wenn es an CPUs oder an Parallelität bei hohen Abfragen mangelt, kann sich eine Warteschlange schnell füllen, was zu einem HTTP-429-Fehler führt. Um Ihre Warteschlangen-Threads zu überwachen, überprüfen Sie die Metriken ThreadpoolSearchQueue und ThreadpoolWriteQueue in Amazon CloudWatch.

Verwenden Sie den folgenden Befehl, um Ihre aktiven und Warteschlangen-Threads auf Suchablehnungen zu überprüfen:

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

Um aktive und Warteschlangen-Threads auf Schreibablehnungen zu überprüfen, ersetzen Sie „Suche“ durch „Schreiben“. Die abgelehnten und abgeschlossenen Werte in der Ausgabe sind kumulative Knotenzähler, die zurückgesetzt werden, wenn neue Knoten gestartet werden. Weitere Informationen finden Sie im Abschnitt Beispiel mit expliziten Spalten der Cat-Thread-Pool-API auf der Elasticsearch-Website.

Hinweis: Die Massenwarteschlange auf jedem Knoten kann zwischen 50 und 200 Abfragen aufnehmen, je nachdem, welche Elasticsearch-Version Sie verwenden. Wenn die Warteschlange voll ist, werden neue Abfragen abgelehnt. Weitere Informationen finden Sie unter Thread-Pool auf der Elasticsearch-Website.

Beispielfehler für Such- und Schreibablehnungen

Suchablehnungen

Ein Suchablehnungsfehler zeigt an, dass aktive Threads ausgelastet sind und Warteschlangen bis zur maximalen Anzahl von Aufgaben gefüllt werden. Somit kann Ihre Suchabfrage abgelehnt werden. Sie können OpenSearch-Service-Protokolle konfigurieren, sodass diese Fehlermeldungen in Ihren langsamen Suchprotokollen angezeigt werden.

Hinweis: Um zusätzlichen Overhead zu vermeiden, legen Sie Ihren Schwellenwert für langsame Protokollierung auf einen großzügigen Betrag fest. Wenn beispielsweise die meisten Ihrer Abfragen 11 Sekunden dauern und Ihr Schwellenwert „10“ beträgt, benötigt dann OpenSearch Service zusätzliche Zeit, um ein Protokoll zu schreiben. Sie können diesen Overhead vermeiden, indem Sie Ihren Schwellenwert für langsame Protokollierung auf 20 Sekunden einstellen. Dann wird nur ein kleiner Prozentsatz der langsameren Abfragen (die länger als 11 Sekunden dauern) protokolliert.

Nachdem Ihr Cluster so konfiguriert ist, dass langsame Suchprotokolle an Amazon CloudWatch übertragen werden, legen Sie einen bestimmten Schwellenwert für die langsame Protokollgenerierung fest. Mit dem folgenden HTTP-POST-Aufruf können Sie 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 schreiben

Eine 429-Fehlermeldung als Schreibablehnung weist auf einen Massenwarteschlangenfehler hin. Die es_rejected_execution_exception [bulk] zeigt an, dass Ihre Warteschlange voll ist und dass alle neuen Abfragen abgelehnt werden. Dieser Massenwarteschlangenfehler tritt auf, wenn die Anzahl der Abfragen an den Cluster die Größe der Massenwarteschlange überschreitet (threadpool.bulk.queue_size). Eine Massenwarteschlange auf jedem Knoten kann zwischen 50 und 200 Abfragen aufnehmen, je nachdem, welche Elasticsearch-Version Sie verwenden.

Sie können OpenSearch-Service-Protokolle konfigurieren, sodass diese Fehlermeldungen in Ihren langsamen Indexprotokollen angezeigt werden.

Hinweis: Um zusätzlichen Overhead zu vermeiden, legen Sie Ihren Schwellenwert für langsame Protokollierung auf einen großzügigen Betrag fest. Wenn beispielsweise die meisten Ihrer Abfragen 11 Sekunden dauern und Ihr Schwellenwert „10“ beträgt, benötigt OpenSearch Service zusätzliche Zeit, um ein Protokoll zu schreiben. Sie können diesen Overhead vermeiden, indem Sie Ihren Schwellenwert für langsame Protokollierung auf 20 Sekunden einstellen. Dann wird nur ein kleiner Prozentsatz der langsameren Abfragen (die länger als 11 Sekunden dauern) protokolliert.

Nachdem Ihr Cluster so konfiguriert ist, dass langsame Suchprotokolle an Amazon CloudWatch übertragen werden, legen Sie einen bestimmten Schwellenwert für die langsame Protokollgenerierung fest. Verwenden Sie 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 bei Schreibablehnungen

Hier sind einige bewährte Methoden zur Minimierung der Zahl von Schreibablehnungen:

  • Wenn Dokumente schneller indexiert werden, ist es weniger wahrscheinlich, dass die Schreibwarteschlange die Kapazität erreicht.
  • Optmieren Sie die Größe entsprechend Ihrer Workload und der gewünschten Leistung. Weitere Informationen finden Sie unter Optimieren der Indexierungsgeschwindigkeit auf der Elasticsearch-Website.
  • Fügen Sie Ihrer Anwendungslogik eine exponentielle Wiederholungslogik hinzu. Die exponentielle Wiederholungslogik stellt sicher, dass fehlgeschlagene Abfragen automatisch wiederholt werden.
    Hinweis: Wenn in Ihrem Cluster kontinuierlich hohe gleichzeitige Anforderungen auftreten, hilft dann die exponentielle Wiederholungslogik nicht dabei, den 429-Fehler zu beheben. Integrieren Sie diese bewährte Methode, wenn plötzliche oder gelegentliche Verkehrsspitzen auftreten.
  • Wenn Sie Daten von Logstash erfassen, optimieren Sie die Anzahl und die Massengröße der Worker. Es ist eine bewährte Methode, Ihre Massengröße zwischen 3 und 5 MB einzustellen.

Weitere Informationen zur Leistungsoptimierung der Indexierung finden Sie unter Wie kann ich die Indizierungsleistung in meinem OpenSearch-Service-Cluster verbessern?

Bewährte Methode bei Suchablehnungen

Hier sind einige bewährte Methoden zur Minimierung der Zahl von Suchablehnungen:

  • Wechseln Sie zu einem größeren Instance-Typ. OpenSearch Service stützt sich stark auf den Dateisystem-Cache, um schnellere Suchergebnisse zu erzielen. Die Anzahl der Threads im Thread-Pool auf jedem Knoten für Suchabfragen entspricht: int ((# of available_processors * 3)/2) + 1. Wechseln Sie zu einer Instance mit mehr vCPUs, um mehr Threads für die Verarbeitung von Suchabfragen zu erhalten.
  • Aktivieren Sie die Option langsame Suchprotokolle für einen bestimmten Index oder für alle Indizes mit einem angemessenen Schwellenwert. Prüfen Sie, welche Abfragen länger zum Ausführen brauchen und implementieren Sie Suchleistungsstrategien für Ihre Abfragen. Weitere Informationen finden Sie unter Fehlerbehebung bei Elasticsearch-Suchen für Anfänger oder Fortgeschrittene Optimierung: Finden und Beheben langsamer Elasticsearch-Abfragen auf der Elasticsearch-Website.

AWS OFFICIAL
AWS OFFICIALAktualisiert vor 2 Jahren