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

Kurzbeschreibung

Für Suchanfragen berechnet OpenSearch Service die Roundtrip-Zeit wie folgt:

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

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

Um Latenzspitzen bei der Suche in Ihrem OpenSearch Service-Cluster zu beheben, können Sie mehrere Schritte unternehmen:

• Überprüfen, ob nicht genügend Ressourcen im Cluster bereitgestellt werden
• Suchen mithilfe der ThreadPoolSearchRejected-Metrik in CloudWatch nach Ablehnungen von Suchanfragen
• Verwenden der Search-Slow-Logs-API und der Profile-API
• Beheben aller 504-Gateway-Fehler

Behebung

Überprüfen, ob nicht genügend Ressourcen im Cluster bereitgestellt werden

Wenn in Ihrem Cluster nicht genügend Ressourcen bereitgestellt werden, kann es zu Latenzspitzen bei der Suche kommen. Verwenden Sie die folgenden bewährten Methoden, um sicherzustellen, dass Sie über ausreichend Ressourcen verfügen.

1.Überprüfen Sie die CPUUtilization-Metrik und den JVMMemory-Druck des Clusters mithilfe von CloudWatch. Vergewissern Sie sich, dass sie innerhalb der empfohlenen Schwellenwerte liegen. Weitere Informationen finden Sie unter Empfohlene CloudWatch-Alarme für Amazon OpenSearch Service.

2.Verwenden Sie die Knoten-Statistik-API, um Statistiken auf Knoten-Ebene für Ihren Cluster abzurufen:

GET /_nodes/stats

Überprüfen Sie in der Ausgabe die folgenden Abschnitte: Caches, Felddaten und JVM. Um die Ausgaben zu vergleichen, führen Sie diese API mehrmals mit einer gewissen Verzögerung zwischen den einzelnen Ausgaben aus.

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

• Der Dateisystem-Cache oder Seiten-Cache, der auf Betriebssystemebene vorhanden ist
• Der Anfrage-Cache und der Abfrage-Cache auf Shard-Ebene, die beide auf der Ebene des OpenSearch Services vorhanden sind

Überprüfen Sie die API-Ausgabe der Knoten-Statistiken auf Cache-Bereinigungen. Eine hohe Anzahl von Cache-Bereinigungen in der Ausgabe bedeutet, dass die Cache-Größe nicht ausreicht, um die Anfrage zu bearbeiten. Um Ihre Bereinigungen zu reduzieren, verwenden Sie größere Knoten mit mehr Speicher.

Verwenden Sie die folgenden Anforderungen, um bestimmte Cache-Informationen mit der Knoten-Statistik-API anzuzeigen. Die zweite Anfrage betrifft einen Anfrage-Cache auf Shard-Ebene:

GET /_nodes/stats/indices/request_cache?human

GET /_nodes/stats/indices/query_cache?human

Weitere Informationen zu OpenSearch-Caches finden Sie unter Detaillierter Einblick in das Elasticsearch-Caching: Erhöhung der Abfragegeschwindigkeit um jeweils einen Cache auf der Elastic-Website.

Schritte zum Löschen der verschiedenen Caches finden Sie unter Index- oder Datenstrom-Cache leeren auf der OpenSearch-Website.

4.Das Durchführen von Aggregationen für Felder, die sehr eindeutige Werte enthalten, kann zu einem Anstieg der Heap-Nutzung führen. Wenn Aggregationsabfragen bereits verwendet werden, verwenden Suchvorgänge 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-Heap-Space ausmacht. Wenn der Cache überschritten wird, beginnt die Bereinigung.

Verwenden Sie diese Anfrage, um den Felddaten-Cache anzuzeigen:

GET /_nodes/stats/indices/fielddata?human

Weitere Informationen zur Fehlerbehebung bei hohem JVM-Speicher finden Sie unter Wie behebe ich hohen JVM-Speicherdruck in meinem Amazon OpenSearch Service-Cluster?
Informationen zur Fehlerbehebung bei hoher CPU-Auslastung finden Sie unter Wie behebe ich eine hohe CPU-Auslastung in meinem Amazon OpenSearch Service-Cluster?

Suchen mithilfe der ThreadPoolSearchRejected-Metrik in CloudWatch nach Ablehnungen von Suchanfragen

Um mit CloudWatch nach Ablehnungen von Suchanfragen zu suchen, befolgen Sie die Schritte unter Wie löse ich Ablehnungen von Such- oder Schreibanfragen in Amazon OpenSearch Service?

Verwenden von langsamen Suchprotokollen zur Identifizierung von Abfragen mit langer Laufzeit

Verwenden Sie langsame Protokolle, um sowohl Abfragen mit langer Laufzeit als auch die Zeit zu ermitteln, die eine Abfrage auf einem bestimmten Shard verbracht hat. 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 des Amazon Elasticsearch Service.Um eine detaillierte Aufschlüsselung der Zeit zu erhalten, die Ihre Abfrage in der Abfragephase benötigt, legen Sie "profile":true für Ihre Suchabfrage fest.

**Hinweis:**Wenn Sie den Schwellenwert für die Protokollierung auf einen sehr niedrigen Wert festlegen, kann sich Ihr JVM-Speicherdruck erhöhen. Dies kann zu einer häufigeren Garbage Collection führen, die wiederum die CPU-Auslastung und die Cluster-Latenz erhöht. Wenn Sie mehr Abfragen protokollieren, können sich auch Ihre Kosten erhöhen. Eine lange Ausgabe der Profile-API erhöht außerdem den Aufwand für alle Suchanfragen.

Beheben aller 504-Gateway-Fehler

In den Anwendungsprotokollen Ihres OpenSearch Service-Clusters können Sie bestimmte HTTP-Fehlercodes für einzelne Anfragen sehen. Weitere Informationen zur Behebung von HTTP 504-Gateway-Timeout-Fehlern finden Sie unter Wie kann ich HTTP 504-Gateway-Timeout-Fehler in Amazon OpenSearch Service verhindern?

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

Andere Faktoren, die zu einer hohen Suchlatenz führen können

Es gibt eine Reihe anderer Faktoren, die zu einer hohen Suchlatenz führen können. Verwenden Sie die folgenden Tipps, um die hohe Suchlatenz weiter zu beheben:

• Häufige oder lang andauernde Garbage Collection-Aktivitäten können zu Problemen mit der Suchleistung führen. Durch die Garbage Collection-Aktivität können Threads angehalten und die Suchlatenz erhöht werden. Weitere Informationen finden Sie unter Ein Haufen Probleme: Verwalten des verwalteten Heaps von Amazon OpenSearch Service auf der Elastic-Website.
• Bereitgestellte IOPS (oder i3-Instances) können Ihnen dabei helfen, Engpässe im Amazon Elastic Block Store (Amazon EBS) zu beheben. In den meisten Fällen benötigen Sie sie nicht. Bevor Sie eine Instance auf i3 verschieben, empfiehlt es sich, die Leistung zwischen i3-Knoten und R5-Knoten zu testen.
• Ein Cluster mit zu vielen Shards kann die Ressourcen-Auslastung erhöhen, selbst wenn der Cluster inaktiv ist. Zu viele Shards verlangsamen die Abfrageleistung. Obwohl Sie durch Erhöhen der Replikat-Shard-Anzahl schnellere Suchvorgänge erzielen können, sollten Sie auf einem bestimmten Knoten nicht mehr als 1.000 Shards verwenden. Stellen Sie außerdem sicher, dass die Shard-Größen zwischen 10 GB und 50 GB liegen. Im Idealfall beträgt die maximale Anzahl von Shards auf einem Knoten-Heap * 20.
• Zu viele Segmente oder zu viele gelöschte Dokumente können die Suchleistung beeinträchtigen. Um die Leistung zu verbessern, verwenden Sie Force Merge für schreibgeschützte Indizes. Erhöhen Sie nach Möglichkeit auch die interne Aktualisierung der aktiven Indizes. Weitere Informationen finden Sie unter Lucenes Umgang mit gelöschten Dokumenten auf der Elastic-Website.
• Wenn sich Ihr Cluster in einer Virtual Private Cloud (VPC) befindet, empfiehlt es sich, Ihre Anwendungen in derselben VPC auszuführen.
• Verwenden Sie UltraWarm-Knoten oder Hot-Data-Knoten für schreibgeschützte Daten. Hot Storage bietet die schnellstmögliche Leistung für die Indizierung und Suche nach neuen Daten. UltraWarm-Knoten sind jedoch eine kostengünstige Möglichkeit, große Mengen schreibgeschützter Daten in Ihrem Cluster zu speichern. Für Indizes, in die Sie nicht schreiben müssen und die keine hohe Leistung erfordern, bietet UltraWarm deutlich niedrigere Kosten pro GB an Daten.
• Ermitteln Sie, ob Ihre Workload davon profitiert, dass die Daten, nach denen Sie suchen, auf allen Knoten verfügbar sind. Einige Anwendungen profitieren von diesem Ansatz, insbesondere wenn Ihr Cluster nur wenige Indizes enthält. Erhöhen Sie dazu die Anzahl der Replikat-Shards.
  Hinweis: Dies könnte die Latenz bei der Indizierung erhöhen. Außerdem benötigen Sie möglicherweise zusätzlichen Amazon EBS-Speicher, um die von Ihnen hinzugefügten Replikate unterzubringen. Dadurch erhöhen sich Ihre EBS-Volume-Kosten.
• Durchsuchen Sie möglichst wenige Felder und vermeiden Sie Skripte und Platzhalterabfragen. Weitere Informationen finden Sie unter Suchgeschwindigkeit optimieren auf der Elastic-Website.
• Verwenden Sie für Indizes mit vielen Shards benutzerdefiniertes Routing, um die Suche zu beschleunigen. Benutzerdefiniertes Routing stellt sicher, dass Sie nur die Shards abfragen, die Ihre Daten enthalten, anstatt die Anfrage an alle Shards zu senden. Weitere Informationen finden Sie unter Anpassen Ihres Dokument-Routings auf der Elastic-Website.

Verwandte Informationen

Empfohlene CloudWatch-Alarme für Amazon OpenSearch Service