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

Kurzbeschreibung

Im Folgenden sind häufige Ursachen für Probleme mit hoher Latenz in ElastiCache für Redis aufgeführt:

• Langsame Befehle
• Erhöhte Swap-Aktivität, die durch hohe Speicherauslastung verursacht wird
• Probleme mit dem Netzwerk
• Clientseitige Latenzprobleme
• Redis-Synchronisierung
• ElastiCache-Cluster-Ereignisse

Behebung

Beheben Sie Ihre Probleme mit hoher Latenz anhand der folgenden Ursachen:

Langsame Befehle

Redis wird als Single-Thread ausgeführt. Wenn also eine Anfrage langsam bearbeitet wird, müssen andere Clients warten, bis ihre eigene Anfrage verarbeitet werden kann. Diese Verlangsamung führt zu einer Verlängerung der Gesamtzeit der Bearbeitung von Anfragen. Verwenden Sie Amazon CloudWatch-Metriken für Redis, um die durchschnittliche Latenz für verschiedene Befehlsklassen zu überwachen. Außerdem werden gängige Redis-Operationen in Mikrosekunden-Latenz berechnet. CloudWatch-Metriken werden jede Minute abgetastet und Latenzmetriken werden als Aggregat mehrerer Befehle angezeigt. Ein einziger Befehl kann zu unerwarteten Ergebnissen führen, z. B. zu Timeouts, ohne dass signifikante Änderungen in den Metrikdiagrammen auftreten. Verwenden Sie SLOWLOG GET, um eine Liste von Befehlen abzurufen, deren Ausführung lange dauert. Führen Sie außerdem den Befehl slowlog get 128 in der redis-cli aus. Weitere Informationen finden Sie unter SLOWLOG GET auf der Redis-Website. Weitere Informationen finden Sie unter Wie aktiviere ich Redis Slow Log in einem ElastiCache für Redis-Cache-Cluster?

Wenn die Metrik EngineCPUUtilization steigt, finden Sie weitere Informationen unter Wie behebe ich eine erhöhte CPU-Auslastung in meinem selbst entworfenen Cluster in ElastiCache für Redis?

Im Folgenden finden Sie Beispiele für komplexe Befehle:

• KEYS, die sich in Produktionsumgebungen mit großen Datensätzen befinden. KEYS durchsucht den gesamten Keyspace und sucht nach bestimmten Mustern. Weitere Informationen finden Sie unter KEYS auf der Redis-Website.
• Lua-Skripte, deren Ausführung lange dauert. Weitere Informationen finden Sie unter Scripting mit Lua auf der Redis-Website.

Erhöhte Swap-Aktivität, die durch hohe Speicherauslastung verursacht wird

Redis tauscht Speicherseiten aus, wenn der Speicherdruck auf dem Cluster erhöht ist. Dies kann dazu führen, dass die Latenz ansteigt und es aufgrund von Speicherseiten, die zum und vom Swap-Bereich übertragen werden, zu Timeouts kommt. Folgendes weist auf eine erhöhte Swap-Aktivität in CloudWatch-Metriken hin:

• Erhöhter Wert für SwapUsage
• Sehr niedriger Wert für FreeableMemory
• Hohe Metriken für BytesUsedForCache und DatabaseMemoryUsagePercentage

Informationen zur Behebung Ihrer erhöhten Swap-Aktivität finden Sie in den folgenden Ressourcen:

• Wie behebe ich die erhöhte CPU-Auslastung in meinem selbst entworfenen Cluster in ElastiCache für Redis?
• Wie behebe ich den Anstieg der Swap-Aktivität in meinen ElastiCache-Instances?

Probleme mit dem Netzwerk

Um Probleme mit hoher Latenz zu beheben, die durch Netzwerkprobleme verursacht werden, sehen Sie sich die folgenden Szenarien an:

Netzwerklatenz zwischen dem Client und dem ElastiCache-Cluster
Informationen zum Isolieren der Netzwerklatenz zwischen den Client- und Clusterknoten finden Sie unter Wie behebe ich Probleme mit der Netzwerkleistung zwischen EC2-Linux- oder Windows-Instances in einer VPC und einem lokalen 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 hat der Knotentyp cache.m6g.large dieselben Netzwerklimits wie die Amazon-EC2-Instance m6g.large. Informationen zur Problembehandlung Ihrer ElastiCache-Knoten-Netzwerklimits finden Sie unter Netzwerkbezogene Grenzwerte. Außerdem ist es eine bewährte Methode, die Netzwerkleistung Ihrer Amazon-EC2-Instance zu überwachen und Ihre Bandbreitenkapazität, die Leistung von Paketen pro Sekunde (PPS) und die verfolgten Verbindungen zu überprüfen.

TCP/SSL-Handshake-Latenz

Clients verwenden eine TCP-Verbindung, um eine Verbindung zu Redis-Clustern herzustellen. Die Erstellung von TCP-Verbindungen kann einige Millisekunden dauern. Diese Verzögerung kann zu zusätzlichem Overhead für die Redis-Operationen Ihrer Anwendung führen. Außerdem wird die CPU durch den ElastiCache-Knoten zusätzlich belastet. Stellen Sie sicher, dass Sie das Volumen neuer Verbindungen kontrollieren, insbesondere wenn Ihr Cluster die ElastiCache-Funktion für die In-Transitverschlüsselung (TLS) verwendet. Eine große Anzahl von Verbindungen, die geöffnet (NewConnections) und geschlossen werden, kann die Leistung des Knotens beeinträchtigen. Verwenden Sie für eine große Anzahl von Verbindungen Verbindungspooling, um etablierte TCP-Verbindungen in einem Pool zwischenzuspeichern. Um Verbindungspooling zu implementieren, verwenden Sie Ihre Redis-Clientbibliothek (falls unterstützt) oder erstellen Sie Ihren Verbindungspool manuell. Sie können auch aggregierte Befehle wie MSET/MGET oder Redis-Pipelines als Optimierungstechnik verwenden. Weitere Informationen finden Sie unter Redis-Pipelining auf der Redis-Website.

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

Es hat sich bewährt, die CloudWatch-Metriken CurrConnections und NewConnections zu verfolgen. Diese Metriken überwachen die Anzahl der TCP-Verbindungen, die von Redis akzeptiert werden. Eine große Anzahl von TCP-Verbindungen kann dazu führen, dass das Limit von 65.000 maxclients ausgeschöpft wird. Dieses Limit ist die maximale Anzahl gleichzeitiger Verbindungen, die Sie pro Knoten haben können. Weitere Informationen finden Sie auf der Redis-Website unter Maximale Anzahl gleichzeitig verbundener Clients. Wenn Sie das Limit von 65.000 erreichen, wird der Fehler ERR max number of clients reached angezeigt. Wenn mehr Verbindungen hinzugefügt werden, die das Linux-Serverlimit oder die maximale Anzahl der verfolgten Verbindungen überschreiten, treten Verbindungstimeouts auf. Weitere Informationen darüber, wie Sie eine große Anzahl von Verbindungen verhindern können, finden Sie unter Bewährte Methoden für Redis-Clients.

Clientseitige Latenzprobleme

Um festzustellen, ob clientseitige Ressourcen Latenzprobleme verursachen, überprüfen Sie die Speicher-, CPU- und Netzwerkauslastung auf der Clientseite. Stellen Sie sicher, dass sich diese Ressourcen nicht ihrem Limit nähern. Wenn Ihre Anwendung auf einer Amazon-EC2-Instance ausgeführt wird, verwenden Sie CloudWatch-Metriken, um Probleme zu identifizieren. Verwenden Sie außerdem ein Überwachungstool in der Amazon-EC2-Instance, z. B. atop oder CloudWatch Agent.

Wenn die in der Anwendung eingerichteten Timeout-Konfigurationswerte zu klein sind, erhalten Sie möglicherweise unnötige Timeout-Fehler. Um diese Fehler zu beheben, konfigurieren Sie den clientseitigen Timeout so, dass der Server genügend Zeit hat, Anfragen zu verarbeiten und Antworten zu generieren. Weitere Informationen finden Sie unter Bewährte Methoden für Redis-Clients. Außerdem werden bei Timeout-Fehlern zusätzliche Informationen angezeigt. Vergewissern Sie sich, dass Sie die Details des Timeout-Fehlers überprüfen, um die Ursache Ihrer Latenz zu ermitteln. Suchen Sie nach den folgenden Mustern, um festzustellen, ob die Latenz von der Clientseite, dem ElastiCache-Knoten oder dem Netzwerk verursacht wird:

• Prüfen Sie, ob die Timeouts häufig oder zu einer bestimmten Tageszeit auftreten.
• Prüfen Sie, ob die Timeouts bei einem bestimmten Client oder bei mehreren Clients auftreten.
• Prüfen Sie, ob die Timeouts an einem bestimmten Redis-Knoten oder an mehreren Knoten auftreten.
• Prüfen Sie, ob die Timeouts bei einem bestimmten Cluster oder bei mehreren Clustern auftreten.

Redis-Synchronisierung

Die Redis-Synchronisierung wird bei Sicherungs-, Knotenwechsel- und Skalierungsereignissen initiiert. Dies ist eine rechenintensive Arbeitslast, die zu Latenzen führen kann. Verwenden Sie die CloudWatch-Metrik SaveInProgress, um zu überprüfen, ob die Synchronisierung läuft. Weitere Informationen finden Sie unter So werden Synchronisation und Backup implementiert.

ElastiCache-Cluster-Ereignisse

Um den Zeitraum zu überprüfen, in dem die Latenz aufgetreten ist, sehen Sie sich den Abschnitt Ereignisse in der ElastiCache-Konsole an. Suchen Sie nach Hintergrundaktivitäten, wie Knotenwechsel- oder Failover-Ereignissen, die durch von ElastiCache verwaltete Wartungs- und Service-Updates verursacht werden könnten. Suchen Sie außerdem nach unerwarteten Hardwarefehlern. Benachrichtigungen über geplante Ereignisse werden über das AWS-Servicestatus-Dashboard und per E-Mail empfangen.

Beispiel für ein Ereignisprotokoll:

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

Ähnliche Informationen

Überwachung bewährter Methoden mit Amazon ElastiCache für Redis mithilfe von Amazon CloudWatch

Zusätzliche Schritte zur Fehlerbehebung https://kcs.support.aws.dev/article/elasticache-redis-correct-high-latency/2