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

Kurzbeschreibung

Bei Suchanforderungen berechnet OpenSearch Service die Roundtriptrip-Zeit mit der folgenden Formel:

Roundtrip = Zeit, welche die Abfrage in der Abfragephase verbringt + Zeit in der Abrufphase + Zeit in der Warteschlange + Netzwerklatenz

Die SearchLatency-OpenSearch-Service-Metrik in Amazon CloudWatch zeigt die Zeit an, die die Abfrage in der Abfragephase verbracht hat.

Gehe wie folgt vor, um Suchlatenzspitzen im OpenSearch-Service-Cluster zu beheben:

• Prüfe Infrastrukturmetriken wie CPU-Auslastung, Festplattennutzung und Arbeitsspeicher sowohl für die Speicherauslastung der Java Virtual Machine (JVM) als auch für die Garbage Collection.
• Suche nach Spitzen in der SearchRate-Metrik.
• Verwende die ThreadpoolSearchRejected-Metrik, um nach Suchablehnungen zu suchen.
• Verwende Slow-Protokolle, um Abfragen mit langer Laufzeit zu identifizieren.
• Behebe die Fehler „504 gateway timeout“.
• Optimiere die Konfiguration, um die Latenz zu reduzieren.

Lösung

Infrastrukturmetriken überprüfen

Eine häufige und lange Garbage Collection auf den Datenknoten des Betriebssystems erfolgt, wenn die Ressourcennutzung hoch ist. Wenn du im Cluster nicht genügend Ressourcen bereitstellst, kann es zu Latenzspitzen bei der Suche kommen.

Problembehandlung bei hoher Ressourcennutzung

Stelle sicher, dass die Metriken CPUUtilization und JVMMemoryPressure für den Cluster unter 80 % liegen. Wenn die Metrikwerte in CloudWatch höher als 80 % sind, behebe die hohe CPU-Auslastung oder den hohen JVM-Speicherdruck.

Um die Ressourcennutzung proaktiv zu überwachen, richte CloudWatch-Alarme für OpenSearch Service ein.

Um Statistiken auf Knotenebene für deinen Cluster zu erhalten, führe die folgende Abfrage mehrmals in Intervallen von 5 Minuten aus:

GET /_nodes/stats

Achte in der Ausgabe auf signifikante Änderungen der Cache-Nutzung, des Felddatenspeichers und der JVM-Heap-Werte zwischen den Ausführungen. Konsistente Werte zeigen einen normalen Betrieb. Bei Problemen kann es zu plötzlichen Spitzen oder Abnahmen kommen.

Die Cache-Einstellungen überprüfen

OpenSearch Service verwendet die folgenden Caches, um seine Leistung und die Antwortzeit von Anfragen zu verbessern:

• Den Dateisystemcache oder Seitencache, der auf Betriebssystemebene vorhanden ist
• Den Anforderungscache und den Abfragecache auf Shard-Ebene, die beide auf der Ebene des OpenSearch Services vorhanden sind

Führe die folgende Abfrage aus, um Informationen zum Dateisystemcache anzuzeigen:

GET /_nodes/stats/indices/request_cache?human

Führe die folgende Abfrage aus, um Informationen zum Anforderungscache auf Shard-Ebene anzuzeigen:

GET /_nodes/stats/indices/query_cache?human

Suche in der Ausgabe nach Cache-Bereinigungen. Eine hohe Anzahl von Cache-Bereinigungen bedeutet, dass der Cache zu klein ist, um die Anforderung zu bearbeiten. Verwende größere Knoten mit mehr Speicher, um die Bereinigungen zu reduzieren. Weitere Informationen zur Preisgestaltung von Knotengrößen findest du unter OpenSearch-Service-Preise. Weitere Informationen zu OpenSearch-Caches findest du unter Detaillierter Einblick in das Elasticsearch-Caching: Boosting query speed one cache at a time (Detaillierter Einblick in das Elasticsearch-Caching: Erhöhung der Abfragegeschwindigkeit um jeweils einen Cache) auf der Elastic-Website.

Informationen zum Löschen des Caches findest du unter Clear cache API (API zum Löschen von Caches) auf der OpenSearch-Website.

Aggregationen auf Feldern, die sehr eindeutige Werte enthalten, können zu einer Erhöhung der Heap-Nutzung führen. Suchvorgänge bei Aggregationsabfragen verwenden Felddaten. Felddaten sortieren auch die Feldwerte im Skript und greifen darauf zu. Die Bereinigung von Felddaten hängt von der Größe der Datei indices.fielddata.cache.size ab, die 20 % des JVM-Heaps ausmacht.

Führe die folgende Abfrage aus, um zu überprüfen, wie viel Speicher Felddaten auf allen Knoten im Cluster verwenden:

GET /_nodes/stats/indices/fielddata?human

Nach Spitzen in der SearchRate-Metrik suchen

Mehrere Suchanforderungen in einem kurzen Zeitraum können die Ressourcen eines Clusters belasten und zu Verzögerungen bei der Abfrageverarbeitung und zu langsameren Antwortzeiten bei einzelnen Suchen führen. Eine hohe Suchrate in OpenSearch Service kann zu einer erhöhten Suchlatenz führen. Wenn die SearchRate-Metrik Spitzen erreicht, überprüfe, ob die Spitzen gleichzeitig mit den Spitzen der Suchlatenz auftreten. Wenn die Spitzen gleichzeitig auftreten, musst du dem Cluster weitere Ressourcen hinzufügen oder Abfragen optimieren, um die Suchlast zu bewältigen.

Nach Suchablehnungen suchen

Verwende die Metrik ThreadpoolSearchRejected, um Suchablehnungen zu identifizieren und zu beheben.

Slow-Protokolle verwenden, um Abfragen mit langer Laufzeit zu identifizieren

Verwende Slow-Protokolle, um Abfragen mit langer Laufzeit und die Zeit zu identifizieren, die eine Abfrage für einen bestimmten Shard aufgewendet hat. Du kannst Schwellenwerte für die Abfragephase festlegen und dann die Phase für jeden Index abrufen.

Setze für einen detaillierten Überblick über die Zeit, die deine Suchabfrage in der Abfragephase verbringt, profile auf wahr.

Beispielabfrage:

GET /my_index/_search
{
  "profile": true,
  "query": {
    "match": {
      "field": "value"
    }
  }
}

Hinweis: Wenn du den Schwellenwert für die Protokollierung zu niedrig festlegst, erhöhen sich möglicherweise der JVM-Speicherdruck und die Cluster-Latenz. Wenn du mehr Abfragen protokollierst, erhöhst du auch die Kosten. Eine große Ausgabe für eine Abfrage, bei der profile auf wahr gesetzt ist, erhöht den Overhead bei anderen Suchabfragen. Infolgedessen verlangsamen sich andere Suchen vorübergehend.

Fehler „504 gateway timeout“ beheben

Voraussetzung: Aktiviere Fehlerprotokolle, um bestimmte HTTP-Fehlercodes zu identifizieren.

Verwende die Anwendungsprotokolle des OpenSearch-Service-Clusters, um die spezifischen HTTP-Fehlercodes für einzelne Anforderungen zu überprüfen. Informationen zum Beheben von HTTP-Fehlern „504 gateway timeout“ findest du unter Wie kann ich HTTP-Fehler „504 gateway timeout“ in OpenSearch Service verhindern?

Optimieren der Konfiguration

Die Garbage Collection verwalten

Häufige Garbage-Collection-Aktivitäten oder solche mit langer Laufzeit können zu Problemen mit der Suchleistung führen, Threads anhalten oder die Suchlatenz erhöhen. Bewährte Methoden zur Verkürzung der Zeit der Garbage Collection findest du unter Ein Haufen Probleme: Verwaltung des verwalteten Heaps von Elasticsearch auf der Elastic-Website.

Den Instance-Speicher optimieren

Der Amazon Elastic Compute Cloud (Amazon EC2)-Instance-Typ kann entweder Amazon Elastic Block Store (Amazon EBS)-optimierte Speicher-Volumes oder Instance-Speicher-Volumes verwenden. Instance-Speicher-Volumes können dabei helfen, E/A-Engpässe zu beheben, da sie direkt angeschlossenen Speicher und höhere IOPS-Funktionen bieten. Amazon-EBS-optimierte Instances bieten jedoch persistenten Speicher mit gleichbleibender Leistung. Wähle einen Speichertyp, der den Konfigurationsanforderungen auf der Grundlage von E/A, Datenpersistenz und Kosten entspricht.

Bevor du den Instance-Typ änderst, empfiehlt es sich, die Leistung zwischen verschiedenen Instance-Typen zu testen, um sicherzustellen, dass sie deinen Workload-Anforderungen entsprechen. Eine Liste der verfügbaren OpenSearch-Service-Instance-Typen findest du unter Kostenloses Kontingent und On-Demand-Instance-Preise auf OpenSearch-Service-Preise.

Hinweis: Wenn sich der Cluster in einer Virtual Private Cloud (VPC) befindet, empfiehlt es sich, die Anwendungen in derselben VPC auszuführen.

Die Shard- und Segmentkonfiguration vereinfachen

Ein Cluster mit zu vielen Shards kann die Ressourcennutzung erhöhen, selbst wenn der Cluster inaktiv ist. Zu viele Shards verlangsamen auch die Abfrageleistung. Obwohl eine größere Anzahl von Replikat-Shards schnellere Suchen ermöglicht, solltest du nicht mehr als 1000 Shards auf einem einzelnen Knoten verwenden. Stelle außerdem sicher, dass die Shard-Größen zwischen 10 GiB und 50 GiB liegen. Es hat sich bewährt, die maximale Anzahl von Shards auf einem Knoten auf das 20-fache der Größe des Heaps festzulegen. Informationen darüber, wie du die Shard-Strategie neu indizieren und ändern kannst, findest du unter Optimize OpenSearch index shard sizes (Die Größen der OpenSearch-Index-Shards optimieren) auf der OpenSearch-Website.

Zu viele Segmente oder zu viele gelöschte Dokumente können sich ebenfalls auf die Suchleistung auswirken. Um die Leistung zu verbessern, verwende die erzwungene Zusammenführung für schreibgeschützte Indizes und erhöhe das Aktualisierungsintervall für aktive Indizes. Weitere Informationen findest du unter Force merge API (Force-Merge-API) und Optimize OpenSearch refresh interval (OpenSearch-Aktualisierungsintervall optimieren) auf der OpenSearch-Website.

Bevor du allen Knoten Replikat-Shards hinzufügst, prüfe die Anforderungen der Anwendung. Wenn die Anwendung alle Daten von einem beliebigen Knoten aus durchsuchen muss, erhöhe die Anzahl der Replikat-Shards, um die Datenverfügbarkeit zu erhöhen. Andernfalls benötigst du möglicherweise nicht auf jedem Knoten Replikat-Shards.

Hinweis: Replikat-Shards ermöglichen es Clustern, die Parallelverarbeitung zu nutzen und Suchanforderungen auf mehrere Kopien der Daten zu verteilen. Infolgedessen verbessert sich die Suchleistung. Indizierungsvorgänge werden jedoch langsamer und du benötigst zusätzlichen Speicherplatz für jede vollständige Datenkopie.

Verwende für Indizes mit vielen Shards benutzerdefiniertes Routing, um die Suchleistung zu verbessern. Beim benutzerdefinierten Routing fragst du nur die Shards ab, die deine Daten enthalten, und nicht alle Shards. Informationen zur Konfiguration von benutzerdefiniertem Routing findest du unter Anpassen des Dokument-Routings auf der Elastic-Website.

UltraWarm-Speicher für schreibgeschützte Daten verwenden

Hot-Speicher bietet die schnellste Leistung bei der Indizierung und Suche nach neuen Daten. UltraWarm-Knoten bieten jedoch eine kostengünstige Möglichkeit, große Mengen schreibgeschützter Daten im Cluster zu speichern. Verwende für schreibgeschützte Indizes, die keine hohe Leistung erfordern, UltraWarm- anstelle von Hot-Datenspeicher.

Erhöhen der Suchgeschwindigkeit

Durchsuche möglichst wenige Felder und vermeide Skripte und Platzhalterabfragen. Weitere Informationen findest du unter Tune for search speed (Suchgeschwindigkeit optimieren) auf der Elastic-Website.