Wie behebe ich Probleme mit hoher Latenz bei der Verwendung von ElastiCache for Redis?

Kurzbeschreibung

Im Folgenden sind häufige Gründe für erhöhte Latenzen oder Timeoutprobleme in ElastiCache for Redis aufgeführt:

• Latenz durch langsame Befehle.
• Hoher Speicherverbrauch führt zu erhöhtem Swapping.
• Latenz aufgrund von Netzwerkproblemen.
• Probleme mit der clientseitigen Latenz.
• ElastiCache-Cluster-Ereignisse

Auflösung

Latenz durch langsame Befehle

Redis ist meistens Singlethread. Wenn also eine Anfrage nur langsam bearbeitet wird, müssen alle anderen Clients warten, bis sie bedient werden. Dieses Warten erhöht die Befehlslatenzen. Redis-Befehle haben auch eine Zeitkomplexität, die mit der Big O-Notation definiert wird.

Verwenden Sie von ElastiCache bereitgestellte Amazon CloudWatch-Metriken, um die durchschnittliche Latenz für verschiedene Befehlsklassen zu überwachen. Es ist wichtig zu beachten, dass gängige Redis-Operationen in einer Latenz von Mikrosekunden berechnet werden. CloudWatch-Metriken werden alle 1 Minute abgetastet, wobei die Latenzmetriken eine Gesamtheit mehrerer Befehle anzeigen. Ein einzelner Befehl kann also zu unerwarteten Ergebnissen wie Timeouts führen, ohne dass wesentliche Änderungen in den Metrikdiagrammen angezeigt werden. Verwenden Sie in diesen Situationen den Befehl SLOWLOG, um festzustellen, welche Befehle länger dauern. Stellen Sie eine Verbindung zum Cluster her und führen Sie den Befehl slowlog get 128 in der redis-cli aus, um die Liste abzurufen. Weitere Informationen finden Sie unter Wie aktiviere ich Redis Slow Log in einem Cache-Cluster von ElastiCache für Redis?

Sie können auch einen Anstieg der Metrik EngineCPUUtilization in CloudWatch feststellen, da langsame Befehle die Redis-Engine blockieren. Weitere Informationen finden Sie unter Warum sehe ich eine hohe oder steigende CPU-Auslastung in meinem ElastiCache-for-Redis-Cluster?

Beispiele für komplexe Befehle sind:

• SCHLÜSSEL in Produktionsumgebungen über große Datasets hinweg, da es den gesamten Schlüsselraum durchsucht und nach einem bestimmten Muster sucht.
• Lang laufende LUA-Skripte.

Hoher Speicherverbrauch führt zu erhöhtem Swapping

Redis beginnt mit dem Auswechseln von Seiten, wenn der Speicherdruck auf dem Cluster erhöht ist, da mehr Speicher als verfügbar verwendet wird. Latenz- und Timeout-Probleme nehmen zu, wenn Speicherseiten in den und aus dem Auslagerungsbereich übertragen werden. Im Folgenden finden Sie Hinweise in CloudWatch-Metriken für vermehrtes Swapping:

• Erhöhung der SwapNutzung.
• Sehr niedriger FreeableMemory.
• Hohe BytesUsedForCache und DatabaseMemoryUsagePercentage-Metriken.

SwapUsage ist eine Metrik auf Host-Ebene, die die Menge des ausgetauschten Speichers angibt. Es ist normal, dass diese Metrik Werte ungleich Null anzeigt, da sie vom zugrunde liegenden Betriebssystem gesteuert wird und durch viele dynamische Faktoren beeinflusst werden kann. Zu diesen Faktoren gehören die Betriebssystemversion, Aktivitätsmuster usw. Linux tauscht proaktiv inaktive Schlüssel (auf die Clients selten zugreifen) als Optimierungstechnik auf die Festplatte aus, um Speicherplatz für häufiger verwendete Schlüssel freizugeben.

Das Austauschen wird zu einem Problem, wenn nicht genügend Speicher verfügbar ist. In diesem Fall beginnt das System, Seiten zwischen Festplatte und Speicher hin und her zu verschieben. Insbesondere eine SwapUsage von weniger als einigen hundert Megabyte wirkt sich nicht negativ auf die Leistung von Redis aus. Es gibt Leistungseinbußen, wenn die SwapUsage hoch ist und sich aktiv ändert und nicht genügend Speicher auf dem Cluster verfügbar ist. Weitere Informationen finden Sie unter:

• Warum sehe ich eine hohe oder steigende Speicherauslastung in meinem ElastiCache-Cluster?
• Warum findet das Austauschen in ElastiCache statt?

Durch Netzwerk verursachte Latenz

Netzwerklatenz zwischen dem Client und dem ElastiCache-Cluster

Um die Netzwerklatenz zwischen den Client- und Clusterknoten zu isolieren, verwenden Sie TCP-Traceroute- oder MTR-Tests aus der Anwendungsumgebung. Oder verwenden Sie ein Debugging-Tool wie das Dokument AWSSupport-SetupIPMonitoringFromVPC AWS Systems Manager (SSM-Dokument), um Verbindungen aus dem Client-Subnetz zu testen.

Der Cluster erreicht Netzwerkgrenzen

Ein ElastiCache-Knoten hat dieselben Netzwerkgrenzen wie der entsprechende Typ Amazon Elastic Compute Cloud (Amazon EC2) -Instances. Beispielsweise hat der Knotentyp cache.m6g.large dieselben Netzwerkgrenzen wie die m6g.large EC2-Instance. Informationen zur Überprüfung der drei wichtigsten Netzwerkleistungskomponenten Bandbreitenfähigkeit, Paket-pro-Sekunden-Leistung (PPS) und verfolgte Verbindungen finden Sie unter Überwachen der Netzwerkleistung für Ihre EC2-Instance.

Informationen zur Behebung von Problemen mit Netzwerkbeschränkungen auf Ihrem ElastiCache-Knoten finden Sie unter Fehlerbehebung — Netzwerkbezogene Grenzwerte.

TCP/SSL-Handshake-Latenz

Clients verbinden sich über eine TCP-Verbindung mit Redis-Clustern. Das Erstellen einer TCP-Verbindung dauert einige Millisekunden. Die zusätzlichen Millisekunden erzeugen zusätzlichen Overhead bei Redis-Vorgängen, die von Ihrer Anwendung ausgeführt werden, und zusätzlichen Druck auf die Redis-CPU. Es ist wichtig, das Volumen neuer Verbindungen zu kontrollieren, wenn Ihr Cluster die ElastiCache-Verschlüsselung bei der Übertragung verwendet, da zusätzliche Zeit und CPU-Auslastung für einen TLS-Handshake erforderlich sind. Ein hohes Volumen an schnell geöffneten (NewConnections) und geschlossenen Verbindungen kann die Leistung des Knotens beeinträchtigen. Sie können Verbindungs-Pooling verwenden, um etablierte TCP-Verbindungen in einem Pool zwischenzuspeichern. Die Verbindungen werden dann jedes Mal wiederverwendet, wenn ein neuer Client versucht, eine Verbindung zum Cluster herzustellen. Sie können das Verbindungs-Pooling mithilfe Ihrer Redis-Clientbibliothek (falls unterstützt) mit einem für Ihre Anwendungsumgebung verfügbaren Framework implementieren oder es von Grund auf erstellen. Sie können auch aggregierte Befehle wie MSET/MGET als Optimierungstechnik verwenden.

Es gibt eine große Anzahl von Verbindungen auf dem ElastiCache-Knoten

Es ist eine bewährte Methode, die CloudWatch-Metriken CurrConnections und NewConnections zu verfolgen. Diese Metriken überwachen die Anzahl der von Redis akzeptierten TCP-Verbindungen. Eine große Anzahl von TCP-Verbindungen kann dazu führen, dass das Limit von 65.000 maxclients ausgeschöpft wird. Diese Grenze ist die maximale Anzahl gleichzeitiger Verbindungen, die Sie pro Knoten haben können. Wenn Sie das Limit von 65.000 erreichen, erhalten Sie den Fehler ERR max. Anzahl der erreichten Clients. Wenn mehr Verbindungen hinzugefügt werden, die über das Limit des Linux-Servers oder die maximale Anzahl der verfolgten Verbindungen hinausgehen, führen zusätzliche Clientverbindungen zu Verbindungsfehlern bei der Zeitüberschreitung. Empfehlungen zum Umgang mit einer großen Anzahl von Verbindungen finden Sie unter Bewährte Methoden: Redis-Clients und Amazon ElastiCache for Redis.

Probleme mit der clientseitigen Latenz

Latenz und Timeouts können vom Client selbst ausgehen. Überprüfen Sie die Speicher-, CPU- und Netzwerkauslastung auf der Clientseite, um festzustellen, ob eine dieser Ressourcen an ihre Grenzen stößt. Wenn die Anwendung auf einer EC2-Instance ausgeführt wird, verwenden Sie dieselben CloudWatch-Metriken, die zuvor besprochen wurden, um nach Engpässen zu suchen. Latenz kann in einem Betriebssystem auftreten, das mit den standardmäßigen CloudWatch-Metriken nicht gründlich überwacht werden kann. Erwägen Sie die Installation eines Überwachungstools innerhalb der EC2-Instance, z. B. atop oder CloudWatch Agent.

Wenn die auf der Anwendungsseite eingerichteten Timeout-Konfigurationswerte zu klein sind, erhalten Sie möglicherweise unnötige Timeout-Fehler. Konfigurieren Sie das clientseitige Timeout entsprechend, damit der Server ausreichend Zeit hat, die Anforderung zu verarbeiten und die Antwort zu generieren. Weitere Informationen finden Sie unter Bewährte Methoden: Redis-Clients und Amazon ElastiCache for Redis.

Der Timeout-Fehler, der von Ihrer Anwendung erhalten wurde, zeigt zusätzliche Details. Zu diesen Details gehören, ob ein bestimmter Knoten beteiligt ist, der Name des Redis-Datentyps, der Timeouts verursacht, der genaue Zeitstempel, wann das Timeout aufgetreten ist usw. Diese Informationen helfen Ihnen, das Muster des Problems zu finden. Verwenden Sie diese Informationen, um Fragen wie die folgenden zu beantworten:

• Kommen Timeouts häufig zu einer bestimmten Tageszeit vor?
• Ist das Timeout bei einem oder mehreren Kunden aufgetreten?
• Ist das Timeout bei einem Redis-Knoten oder bei mehreren Knoten aufgetreten?
• Ist das Timeout bei einem Cluster oder mehreren Clustern aufgetreten?

Verwenden Sie diese Muster, um den wahrscheinlichsten Client oder ElastiCache-Knoten zu untersuchen. Sie können auch Ihr Anwendungsprotokoll und VPC Flow Logs verwenden, um zu ermitteln, ob die Latenz auf der Clientseite, dem ElastiCache-Knoten oder im Netzwerk aufgetreten ist.

Synchronisation von Redis

Die Synchronisierung von Redis wird bei Sicherungs-, Ersatz- und Skalierungsereignissen initiiert Dies ist ein rechenintensiver Workload, der Latenzen verursachen kann. Verwenden Sie die SaveInProgress-CloudWatch-Metrik, um zu ermitteln, ob die Synchronisierung läuft. Weitere Informationen finden Sie unter So werden Synchronisation und Sicherung implementiert.

ElastiCache Cluster-Ereignisse

Überprüfen Sie den Abschnitt Ereignisse in der ElastiCache-Konsole auf den Zeitraum, in dem Latenz beobachtet wurde. Überprüfen Sie auf Hintergrundaktivitäten wie Knotenersatz- oder Failover-Ereignisse, die durch ElastiCache Managed Maintenance und Service-Updates verursacht werden könnten, oder auf unerwartete Hardwarefehler. Sie erhalten Benachrichtigungen über geplante Veranstaltungen über das PHD-Dashboard und per E-Mail.

Das Folgende ist ein Beispiel für ein Musterereignisprotokoll:

Finished recovery for cache nodes 0001
Recovering cache nodes 0001
Failover from master node <cluster_node> to replica node <cluster_node> completed

---

Relevante Informationen

Bewährte Methoden zur Überwachung mit Amazon ElastiCache für Redis mithilfe von Amazon CloudWatch.

Latenzprobleme diagnostizieren - Redis

Problembehandlung – Amazon ElastiCache für Redis