AWS re:Post Knowledge Center Feedback Survey

Help us improve the AWS re:Post Knowledge Center by sharing your feedback in a brief survey. Your input can influence how we create and update our content to better support your AWS journey.

Wie behebe ich Probleme mit hoher Latenz in ElastiCache für Valkey oder ElastiCache für Redis OSS?

Lesedauer: 6 Minute

Ich möchte Probleme mit hoher Latenz in meinem Amazon-ElastiCache-für-Valkey- oder Amazon-ElastiCache-für-Redis-OSS-Cluster beheben.

Kurzbeschreibung

Im Folgenden sind häufige Ursachen für Probleme mit hoher Latenz in ElastiCache-für-Valkey- oder ElastiCache-für-Redis-OSS-Clustern beschrieben:

Langsame Befehle
Erhöhte Swap-Aktivität aufgrund hoher Speicherauslastung
Netzwerkprobleme
Clientseitige Latenzprobleme
Redis-Synchronisierung
Amazon-ElastiCache-Cluster-Ereignisse

Lösung

Langsame Befehle

Aufgrund der Single-Thread-Architektur von Valkey- und Redis-OSS-Clustern kann ElastiCache Clients erst bedienen, wenn die aktuelle Anfrage abgearbeitet wurde. Diese Verlangsamung führt zu einer Erhöhung der Gesamtzeit für Anfragen und verursacht hohe Latenz.

Um die durchschnittliche Latenz im Blick zu behalten, kannst du Amazon-CloudWatch-Metriken für Valkey und Redis verwenden, um bestimmte Befehle zu überwachen. Weitere Informationen findest du unter Metriken für Valkey und Redis OSS.

Verwende den Befehl SLOWLOG GET, um eine Liste von Befehlen abzurufen, deren Verarbeitung durch die Engine länger als 10 ms dauert. Du kannst eine Verbindung zum betroffenen Knoten herstellen, um den Befehl slowlog get 128 in der valkey-cli auszuführen.

ElastiCache berechnet außerdem gängige Redis-Operationen in Mikrosekunden-Latenz. CloudWatch erfasst jede Minute Stichproben von Metriken und stellt Latenzmetriken als Zusammenfassung mehrerer Befehle dar. Ein einziger Befehl kann zu kleineren Problemen wie Timeouts führen, ohne dass dies zu wesentlichen Änderungen der Metrikdiagramme führt.

Langsame Befehle, deren Ausführung einen längeren Zeitraum in Anspruch nimmt, können zu einer erhöhten CPU-Auslastung auf dem ElastiCache-Knoten führen. Wenn die Metrik EngineCPUUtilization steigt, findest du weitere Informationen unter Wie behebe ich eine erhöhte CPU-Auslastung in meinem selbst entworfenen Cluster in ElastiCache für Redis?

Im Folgenden findest du Beispiele für komplexe Befehle, die ElastiCache-Cluster verlangsamen können:

Die Verwendung des KEYS-Befehls in Produktionsumgebungen mit großen Datensätzen: Der Befehl KEYS geht den gesamten Keyspace durch und sucht nach bestimmten Mustern. Weitere Informationen findest du unter KEYS auf der Valkey-Website.
Lua-Skripte, deren Ausführung lange dauert: Je nachdem, wie komplex ein Skript ist oder wie groß ein Datensatz ist, kann die Ausführung von Lua-Skripten lange dauern und Latenzprobleme verursachen.

Erhöhte Swap-Aktivität aufgrund hoher Speicherauslastung

Wenn der Speicherdruck auf dem Cluster zunimmt, lagert Redis Speicherseiten aus. Da Speicherseiten in den Swap-Bereich ein- und ausgelagert werden, kann der Swap-Vorgang die Latenz erhöhen und zu Timeouts führen. Die folgenden Änderungen der CloudWatch-Metriken sind Anzeichen dafür, dass die Swap-Aktivität zunimmt:

Erhöhter Wert für SwapUsage
Niedriger Wert für FreeableMemory
Hohe Metriken für BytesUsedForCache und DatabaseMemoryUsagePercentage

Informationen zur Behebung der erhöhten Swap-Aktivität findest du in den folgenden Artikeln:

Netzwerkprobleme

Netzwerkprobleme können zu einer hohen Latenz bei deinen Clustern führen. Führe je nach Netzwerkproblem die folgenden Aufgaben aus, um Probleme mit hoher Latenz zu beheben.

Netzwerklatenz zwischen dem Client und dem ElastiCache-Cluster

Um die Latenz zwischen dem Client und deinem ElastiCache-Cluster zu reduzieren, kannst du die Netzwerklatenz zwischen dem Client und den Clusterknoten isolieren. Weitere Informationen findest du unter Wie behebe ich Probleme mit der Netzwerkleistung zwischen einer EC2 Linux Instance oder EC2 Windows Instance in einer Virtual Private Cloud (VPC) und einem On-Premises-Host über das Internet-Gateway?

Der Cluster erreicht Netzwerklimits

Ein ElastiCache-Knoten hat dieselben Netzwerklimits wie die zugehörigen Amazon Elastic Compute Cloud (Amazon EC2)-Instances. Beispielsweise sind die Netzwerklimits für den ElastiCache-Knotentyp cache.m6g.large und die Amazon EC2 Instance m6g.large identisch. Weitere Informationen zu unterstützten ElastiCache-Knotentypen und den Limits der Netzwerkbandbreite findest du unter Unterstützte Knotentypen.

Informationen zur Problembehandlung der ElastiCache-Knoten-Netzwerklimits findest du unter Netzwerkbezogene Limits.

Hinweis: Es wird empfohlen, die Netzwerkleistung deiner Amazon EC2 Instance, die Bandbreitenkapazität, die Leistung von Paketen pro Sekunde (PPS) und die verfolgten Verbindungen zu überwachen.

TCP/SSL-Handshake-Latenz

Wenn Clients eine Verbindung zu Redis-Clustern herstellen, kann es einige Millisekunden dauern, bis die TCP-Verbindung steht. In dieser Zeit kann die Verzögerung zu einer zusätzlichen Belastung deiner Redis-Operationen und deiner ElastiCache-Node-CPU führen. Wenn viele neue Verbindungen hergestellt werden, kann die Belastung zu einer hohen Latenz für dein Netzwerk führen.

Um das Volumen deiner Verbindungen im Blick zu behalten und die Latenz zu reduzieren, kannst du einen Verbindungspool verwenden, um etablierte TCP-Verbindungen in einem Pool zwischenzuspeichern. Verwende deine Redis-Clientbibliothek, um einen Verbindungspool zu konfigurieren. Du kannst deinen Verbindungspool manuell erstellen.

Um deinen Verbindungspool zu optimieren, kannst du auch aggregierte Befehle wie MSET oder MGET oder Redis-Pipelines verwenden. Weitere Informationen findest du unter Redis-Pipelining auf der Redis-Website.

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

Wenn ein ElastiCache-Knoten eine große Anzahl von TCP-Verbindungen aufgebaut hat, schöpfst du das Limit für maxclients möglicherweise aus. Wenn du dieses Limit erreichst, wird der Fehler „ERR max number of clients reached“ angezeigt und es kann zu Timeouts bei den Verbindungen kommen.

Es hat sich bewährt, die CloudWatch-Metriken CurrConnections und NewConnections im Auge zu behalten. Anhand dieser Metriken kannst du die Anzahl der TCP-Verbindungen deines ElastiCache-Knotens feststellen. Informationen zur Behebung von Problemen, wenn du dein Limit für maxclients ausgeschöpft hast, findest du im Abschnitt **Große Anzahl von Verbindungen unter **Bewährte Methoden: Redis clients and Amazon ElastiCache for Redis.

Clientseitige Latenzprobleme

Wenn du für Client-Ressourcen zu niedrige Timeout-Werte einstellst, werden möglicherweise Timeout-Fehlermeldungen angezeigt. Um festzustellen, ob clientseitige Ressourcen Latenzprobleme verursachen, überprüfe die clientseitige Speicher-, CPU- und Netzwerkauslastung. Wenn sich diese Ressourcen nahe ihrer Limits bewegen, erhöhe die clientseitigen Timeout-Werte, damit die Ressource reagieren kann.

Wenn deine Anwendung auf einer Amazon EC2 Instance ausgeführt wird, verwende CloudWatch-Metriken, um Probleme detaillierter zu untersuchen. Oder du nutzt ein Überwachungstool in der Amazon EC2 Instance, z. B. atop oder CloudWatch-Agent.

Um festzustellen, ob der Client die hohe Latenz verursacht, achte auf die folgenden Probleme:

Stelle fest, ob die Timeouts häufig oder zu einer bestimmten Tageszeit auftreten.
Prüfe, ob die Timeouts bei einem bestimmten Client oder bei mehreren Clients auftreten.
Stelle fest, ob die Timeouts bei einem bestimmten Valkey- oder Redis-Knoten oder bei mehreren Knoten auftreten.
Prüfe, ob die Timeouts bei einem bestimmten Cluster oder bei mehreren Clustern auftreten.

Redis-Synchronisierung

Die Redis-Synchronisierung wird bei Sicherungs-, Knotenwechsel- und Skalierungsereignissen initiiert. Dieser Vorgang stellt eine rechenintensive Workload dar, die zu Latenzen führen kann.

Um zu überprüfen, ob eine Synchronisierung die Leistung deines Knotens beeinträchtigt hat, wirf einen Blick auf die Metrik SaveInProgress in CloudWatch.

Hinweis: Um die Auswirkungen auf den Benutzerverkehr zu minimieren, empfiehlt es sich, Synchronisierungsereignisse außerhalb der Spitzenzeiten zu planen.

ElastiCache-Cluster-Ereignisse

Im Falle eines Cluster-Ereignisses in deinem ElastiCache-Cluster kann sich die Latenz während des Ereignisses erhöhen. Du kannst während des Zeitraums mit höherer Latenz die ElastiCache-Konsole verwenden, um nach Ereignissen zu suchen. Achte auf Hintergrundaktivitäten, wie zum Beispiel Knotenwechsel- oder Failover-Ereignisse durch von ElastiCache verwaltete Wartungs- und Service-Updates.

Wenn du der Meinung bist, dass unerwartete Hardwarefehler zu einem Anstieg der Latenz geführt haben, wende dich an den AWS-Support.

Hinweis: Du kannst Benachrichtigungen zu geplanten Ereignissen im AWS-Servicestatus-Dashboard einsehen.

Beispiel für ein Ereignisprotokoll:

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