Wie behebe ich Suchlatenzspitzen in meinem Amazon-OpenSearch-Service-Cluster?

Letzte Aktualisierung: 05.08.2021

In meinem Amazon-OpenSearch-Service-Cluster (Nachfolger von Amazon Elasticsearch Service) treten Suchlatenzspitzen auf. Wie kann ich diese Suchlatenzspitzen beheben?

Kurzbeschreibung

Bei Suchabfragen wird die Zeit für Roundtrips wie folgt berechnet:

Round trip = Time the query spends in the query phase + time in the fetch phase + time spent in the queue + network latency

Die SearchLatency-Metrik auf Amazon CloudWatch gibt die Zeit an, die eine Abfrage in der Abfragephase verbracht hat.

Es gibt eine Reihe von Schritten zur Fehlerbehebung, die Sie unternehmen können, um die Suche nach Latenzspitzen in Ihrem OpenSearch-Service-Cluster zu beheben, darunter:

  • Prüfen Sie, ob auf dem Cluster unzureichend Ressourcen bereitgestellt wurden
  • Mithilfe der Metrik ThreadpoolSearchRejected in CloudWatch Suchablehnungen identifizieren
  • Verwenden Sie Search Slow Logs und die Profile API
  • Beheben Sie alle 504-GatewayTimeout-Fehler

Behebung

Prüfen, ob auf dem Cluster unzureichend Ressourcen bereitgestellt wurden

Es kann zu Suchlatenzspitzen kommen, wenn auf Ihrem Cluster nicht genug Ressourcen bereitgestellt wurden. Anhand der folgenden bewährten Methoden können Sie sicherstellen, dass Sie genug Ressourcen bereitgestellt haben.

1.    Überprüfen Sie die CPUUtilization-Metrik und den JVMMemory-Druck des Clusters mit Amazon CloudWatch, um herauszufinden, ob diese die empfohlenen Schwellenwerte einhalten. Weitere Informationen finden Sie unter Empfohlene CloudWatch-Alarme.

2.    Verwenden Sie die Node Stats API, um Statistiken auf Knotenebene zu Ihrem Cluster abzurufen:

GET /_nodes/stats

Überprüfen Sie in der Ausgabe die folgenden Bereiche: caches, fielddata und jvm. Führen Sie diese API mehrmals mit einiger Verzögerung aus, um die Ausgaben zu vergleichen.

3.    OpenSearch Service verwendet den Dateisystem-Cache, um schnellere Suchabfragen zu stellen. Überprüfen Sie die Ausgabe der NodeStats API auf Cache-Bereinigungen. Eine hohe Anzahl von Cache-Bereinigungen in der Ausgabe bedeutet, dass die Cache-Größe nicht ausreicht, um die Abfrage zu bearbeiten. Erwägen Sie in diesem Fall, größere Knoten mit mehr Speicherplatz.

4.    Das Ausführen von Aggregationen für Felder mit sehr eindeutigen Werten kann zu einer Steigerung der Heap-Nutzung führen. Wenn bereits Aggregationsabfragen verwendet werden, verwenden Suchvorgänge FieldData. FieldData wird auch verwendet, um die Feldwerte im Skript zu sortieren und darauf zuzugreifen. FieldData-Bereinigungen hängen von der Größe der indices.fielddata.cache.size-Datei ab. Dies macht 20 % des JVM-Heap-Speicherplatzes aus. Bereinigungen beginnen, wenn der Cache überschritten wird.

Weitere Informationen zur Behebung von hohem JVM-Speicherdruck finden Sie unter Wie behebe ich einen hohen JVM-Speicherdruck auf meinem Amazon-OpenSearch-Service-Cluster?

Informationen zur Behebung hoher CPU-Auslastung finden Sie unter Wie kann ich eine hohe CPU-Auslastung auf meinem Amazon-OpenSearch-Service-Cluster beheben?

Mithilfe der Metrik ThreadpoolSearchRejected in CloudWatch Suchablehnungen identifizieren

Um Suchablehnungen mit CloudWatch zu identifizieren, befolgen Sie die Schritte unter Wie behebe ich Such- oder Schreibablehnungen in Amazon OpenSearch Service?

Search Slow Logs verwenden, um lang laufende Abfragen zu identifizieren

Verwenden Sie langsame Protokolle, um sowohl lang laufende Abfragen als auch die Abfragezeit in Bezug auf einen bestimmten Shard zu identifizieren. Sie können Schwellenwerte für die Abfragephase festlegen und dann die Phase für jeden Index abrufen. Weitere Informationen zum Einrichten langsamer Protokolle finden Sie unter Anzeigen langsamer Protokolle in Amazon OpenSearch Service. Legen Sie für die Suchabfrage "profile":true fest, um detaillierte Angaben dazu zu erhalten, wie lange sich Ihre Abfrage in der Abfragephase befunden hat.

Hinweis: Wenn Sie den Schwellenwert für die Protokollierung auf einen sehr niedrigen Wert einstellen, kann der JVM-Speicherdruck steigen. Dies kann zu einer häufigeren Garbage Collection führen, die wiederum die CPU-Auslastung erhöht und eine höhere Latenz auf dem Cluster zur Folge hat. Das Protokollieren weiterer Abfragen kann zudem zu höheren Kosten führen. Die Ausgabe der Profile API kann lang sein, was den Aufwand für alle Suchabfragen erheblich erhöht.

Alle 504-Gateway-Timeout-Fehler beheben

In den Anwendungsprotokollen Ihres OpenSearch-Service-Clusters werden bestimmte HTTP-Fehlercodes für einzelne Abfragen angezeigt. Weitere Informationen zur Behebung von Gateway-Zeitüberschreitungsfehlern vom Typ HTTP 504 finden Sie unter Wie verhindere ich Gateway-Zeitüberschreitungsfehler vom Typ HTTP 504 in Amazon OpenSearch Service?

Hinweis: Sie müssen Fehlerprotokolle aktivieren, um bestimmte HTTP-Fehlercodes zu identifizieren. Weitere Informationen zu HTTP-Fehlercodes finden Sie unter Anzeigen von Fehlerprotokollen in Amazon OpenSearch Service.

Weitere Faktoren, die eine hohe Suchlatenz verursachen können

Es gibt eine Reihe weiterer Faktoren, die eine hohe Suchlatenz verursachen können. Folgende Tipps können Ihnen ebenfalls helfen, eine hohe Suchlatenz zu beheben:

  • Häufige oder lang anhaltende Aktivitäten zur Garbage Collection können zu Problemen bei der Suchleistung führen. Garbage-Collection-Aktivitäten können Threads anhalten und die Suchlatenz erhöhen. Weitere Informationen finden Sie unter Verwaltung von verwalteten Elasticsearch-Heaps auf der Elasticsearch-Website.
  • Bereitgestellte IOPS (oder i3-Instances) können Ihnen helfen, Engpässe in Amazon Elastic Block Store (Amazon EBS) zu beseitigen. In den meisten Fällen benötigen Sie sie nicht. Es ist eine bewährte Methode, die Leistung zwischen i3-Knoten und r5-Knoten zu testen, bevor Sie direkt zu i3 wechseln.
  • Ein Cluster mit zu vielen Shards kann zu einer Erhöhung der Ressourcenauslastung führen, selbst wenn der Cluster inaktiv ist. Zu viele Shards verlangsamen die Abfrageleistung. Die Erhöhung der Anzahl der Replikat-Shards kann zu schnelleren Suchen führen. Ein Knoten sollte dabei aber nicht mehr als 1 000 Shards haben. Stellen Sie außerdem sicher, dass die Shard-Größen zwischen 10 GiB und 50 GiB liegen. Idealerweise sollte die maximale Anzahl von Shards auf einem Knoten Heap x 20 betragen.
  • Zu viele Segmente oder zu viele gelöschte Dokumente können die Suchleistung beeinträchtigen. Die Verwendung von „force merge“ für schreibgeschützte Indizes kann in diesem Fall hilfreich sein. Wenn Ihr Anwendungsfall dies zulässt, erhöhen Sie die interne Aktualisierung der aktiven Indizes. Weitere Informationen finden Sie unter Verarbeitung gelöschter Dokumente durch Lucene auf der Elasticsearch-Website.
  • Wenn sich Ihr Cluster in einer VPC befindet, sollten Sie erwägen, Ihre Anwendungen innerhalb derselben VPC auszuführen.
  • Für schreibgeschützte Daten können UltraWarm-Knoten oder Hot-Datenknoten die richtige Wahl sein. Hot Storage bietet die schnellstmögliche Leistung für die Indexierung und Suche nach neuen Daten. UltraWarm-Knoten hingegen sind eine kostengünstige Möglichkeit, große Mengen schreibgeschützter Daten in Ihrem Cluster zu speichern. Für Indizes, auf die Sie nicht aktiv schreiben und von denen Sie nicht dieselbe Leistung benötigen, bietet UltraWarm deutlich niedrigere Kosten pro GiB an Daten.
  • Testen Sie Ihren Workload, um festzustellen, ob es sinnvoll ist, dass die gesuchten Daten auf allen Knoten verfügbar sind. Für einige Anwendungen kann dies sinnvoll sein, zum Beispiel wenn es nur wenige Indizes auf Ihrem Cluster gibt. Erhöhen Sie dazu die Anzahl der Replikat-Shards. Bedenken Sie, dass dies die Indexierungslatenz erhöhen kann. Außerdem benötigen Sie möglicherweise zusätzlichen Amazon-EBS-Speicher, um die von Ihnen hinzugefügten Replikate unterzubringen. Dies erhöht Ihre EBS-Volume-Kosten.
  • Durchsuchen Sie so wenige Felder wie möglich und vermeiden Sie Skripts und Platzhalter-Abfragen. Weitere Informationen finden Sie unter Optimierung der Suchgeschwindigkeit auf der Elasticsearch-Website.
  • Für Indizes mit vielen Shards können Sie benutzerdefiniertes Routing verwenden, um die Suche zu beschleunigen. Benutzerdefiniertes Routing stellt sicher, dass nur die Shards, die Ihre Daten enthalten, abgefragt werden, anstatt die Abfrage an alle Shards des Index zu senden. Weitere Informationen finden Sie unter Anpassen des Dokumentenroutings auf der Elasticsearch-Website.

War dieser Artikel hilfreich?


Benötigen Sie Hilfe zur Fakturierung oder technischen Support?