Anhaltende Verbindungsprobleme - Amazon ElastiCache
SicherheitsgruppenNetzwerk ACLsRouting-TabellenDNS-AuflösungIdentifizieren von Problemen mit serverseitiger DiagnoseNetzwerkkonnektivitätNetzwerkbezogene GrenzenCPU-VerwendungVerbindungen, die von der Serverseite beendet werdenClientseitige Fehlerbehebung für Amazon-Instances EC2 Aufschlüsselung der Zeit, die zum Abschließen einer einzelnen Anfrage benötigt wird

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Anhaltende Verbindungsprobleme

Bei der Behebung anhaltender Verbindungsprobleme mit müssen die folgenden Punkte überprüft werden ElastiCache:

Sicherheitsgruppen

Sicherheitsgruppen sind virtuelle Firewalls, die Ihren ElastiCache Client (EC2 Instance, AWS Lambda Funktion, Amazon ECS-Container usw.) und Ihren ElastiCache Cache schützen. Sicherheitsgruppen sind statusbehaftet, was bedeutet, dass nach dem Zulassen des eingehenden oder ausgehenden Datenverkehrs die Antworten für diesen Datenverkehr automatisch im Kontext dieser bestimmten Sicherheitsgruppe autorisiert werden.

Die Statusfunktion erfordert, dass die Sicherheitsgruppe alle autorisierten Verbindungen verfolgt, und es gibt ein Limit für verfolgte Verbindungen. Wenn das Limit erreicht ist, schlagen neue Verbindungen fehl. Im Abschnitt zur Fehlerbehebung finden Sie Hilfe dazu, wie Sie feststellen können, ob die Grenzwerte auf dem Client oder auf der ElastiCache Seite erreicht wurden.

Sie können dem Client und dem ElastiCache Cluster eine einzelne Sicherheitsgruppe gleichzeitig oder einzelne Sicherheitsgruppen für jede Gruppe zuweisen.

In beiden Fällen müssen Sie den ausgehenden TCP-Verkehr auf dem ElastiCache Port von der Quelle und den eingehenden Verkehr auf demselben Port zulassen. ElastiCache Der Standardport ist 11211 für Memcached und 6379 für Valkey oder Redis OSS. Standardmäßig gestatten Sicherheitsgruppen allen ausgehenden Datenverkehr. In diesem Fall ist nur die eingehende Regel in der Zielsicherheitsgruppe erforderlich.

Weitere Informationen finden Sie unter Zugriffsmuster für den Zugriff auf einen ElastiCache Cluster in einer Amazon VPC.

Netzwerk ACLs

Network Access Control Lists (ACLs) sind statuslose Regeln. Der Datenverkehr muss in beide Richtungen (Eingehend und Ausgehend) zugelassen sein, um erfolgreich zu sein. Netzwerke ACLs werden Subnetzen zugewiesen, nicht bestimmten Ressourcen. Es ist möglich, dass der Client-Ressource dieselbe ACL zugewiesen ElastiCache wird, insbesondere wenn sie sich im selben Subnetz befinden.

Standardmäßig lässt das Netzwerk den gesamten ACLs Datenverkehr zu. Es ist jedoch möglich, sie anzupassen, um Datenverkehr zu verweigern oder zu erlauben. Darüber hinaus erfolgt die Auswertung der ACL-Regeln sequenziell, was bedeutet, dass die Regel mit der niedrigsten Zahl, die dem Datenverkehr entspricht, dies zulässt oder verweigert. Die Mindestkonfiguration, um den Valkey- oder Redis-OSS-Verkehr zuzulassen, ist:

Clientseitige Netzwerk-ACL:

  • Regeln für eingehenden Datenverkehr:

  • Regelnummer: vorzugsweise niedriger als jede Ablehnungsregel;

  • Type (Typ): Custom TCP Rule (TCP-Regel anpassen);

  • Protokoll: TCP

  • Portbereich: 1024-65535

  • Quelle: 0.0.0.0/0 (oder erstellen Sie individuelle Regeln für die Cluster-Subnetze) ElastiCache

  • Erlauben/Verweigern

  • Regeln für ausgehenden Datenverkehr:

  • Regelnummer: vorzugsweise niedriger als jede Ablehnungsregel;

  • Type (Typ): Custom TCP Rule (TCP-Regel anpassen);

  • Protokoll: TCP

  • Portbereich: 6379

  • Quelle: 0.0.0.0/0 (oder die Cluster-Subnetze. ElastiCache Beachten Sie, dass die Verwendung bestimmter Optionen im Falle eines Failovers oder der Skalierung des Clusters zu Problemen führen IPs kann.

  • Erlauben/Verweigern

ElastiCache Netzwerk-ACL:

  • Regeln für eingehenden Datenverkehr:

  • Regelnummer: vorzugsweise niedriger als jede Ablehnungsregel;

  • Type (Typ): Custom TCP Rule (TCP-Regel anpassen);

  • Protokoll: TCP

  • Portbereich: 6379

  • Quelle: 0.0.0.0/0 (oder erstellen Sie individuelle Regeln für die Cluster-Subnetze) ElastiCache

  • Erlauben/Verweigern

  • Regeln für ausgehenden Datenverkehr:

  • Regelnummer: vorzugsweise niedriger als jede Ablehnungsregel;

  • Type (Typ): Custom TCP Rule (TCP-Regel anpassen);

  • Protokoll: TCP

  • Portbereich: 1024-65535

  • Quelle: 0.0.0.0/0 (oder die Cluster-Subnetze. ElastiCache Beachten Sie, dass die Verwendung bestimmter Optionen im Falle eines Failovers oder der Skalierung des Clusters zu Problemen führen IPs kann.

  • Erlauben/Verweigern

Weitere Informationen finden Sie unter Netzwerk ACLs.

Routing-Tabellen

Ähnlich wie beim Netzwerk ACLs kann jedes Subnetz unterschiedliche Routing-Tabellen haben. Wenn sich Clients und der ElastiCache Cluster in unterschiedlichen Subnetzen befinden, stellen Sie sicher, dass ihre Routing-Tabellen es ihnen ermöglichen, einander zu erreichen.

Bei komplexeren Umgebungen mit mehreren VPCs dynamischen Routing- oder Netzwerk-Firewalls kann es schwierig werden, Fehler zu beheben. Siehe Netzwerkkonnektivität, um zu bestätigen, dass Ihre Netzwerkeinstellungen angemessen sind.

DNS-Auflösung

ElastiCache stellt die Dienstendpunkte auf der Grundlage von DNS-Namen bereit. Die verfügbaren Endpunkte sindConfiguration,Primary,Reader, undNode-Endpunkte. Weitere Informationen finden Sie unter Verbindungsendpunkte ermitteln.

Im Falle eines Failovers oder einer Clusteränderung kann sich die dem Endpunktnamen zugeordnete Adresse ändern und wird automatisch aktualisiert.

Benutzerdefinierte DNS-Einstellungen (d. h. wenn der VPC-DNS-Dienst nicht verwendet wird) kennen die von ElastiCache -bereitgestellten DNS-Namen möglicherweise nicht. Stellen Sie sicher, dass Ihr System die ElastiCache Endpunkte mithilfe von Systemtools wie dig (wie unten gezeigt) oder erfolgreich auflösen kann. nslookup

$ dig +short example.xxxxxx.ng.0001.use1.cache.amazonaws.com
example-001.xxxxxx.0001.use1.cache.amazonaws.com.
1.2.3.4

Sie können die Namensauflösung auch über den VPC DNS-Dienst erzwingen:

$ dig +short example.xxxxxx.ng.0001.use1.cache.amazonaws.com @169.254.169.253
example-001.tihewd.0001.use1.cache.amazonaws.com.
1.2.3.4

Identifizieren von Problemen mit serverseitiger Diagnose

CloudWatch Metriken und Laufzeitinformationen von der ElastiCache Engine sind gängige Informationsquellen zur Identifizierung potenzieller Ursachen von Verbindungsproblemen. Eine gute Analyse beginnt üblicherweise mit den folgenden Elementen:

  • CPU-Auslastung: Valkey und Redis OSS sind Multithread-Anwendungen. Die Ausführung jedes Befehls erfolgt jedoch in einem einzigen (Haupt-) Thread. Aus diesem Grund ElastiCache bietet es die Metriken und. CPUUtilization EngineCPUUtilization EngineCPUUtilizationliefert die CPU-Auslastung, die für den Valkey- oder Redis-OSS-Prozess vorgesehen ist, und CPUUtilization die Nutzung für alle V. CPUs Knoten mit mehr als einer vCPU haben normalerweise unterschiedliche Werte für CPUUtilization undEngineCPUUtilization, wobei der zweite Wert in der Regel höher ist. HochEngineCPUUtilizationkann durch eine erhöhte Anzahl von Anforderungen oder komplexe Vorgänge verursacht werden, die eine erhebliche CPU-Zeit in Anspruch nehmen. Sie können beide folgendermaßen identifizieren:

    • Erhöhte Anzahl von Anforderungen: Prüfen Sie auf Erhöhungen für andere Metriken, die den EngineCPUUtilization-Muster. Nützliche Metriken sind:

      • CacheHitsundCacheMisses: Die Anzahl der erfolgreichen Anforderungen oder Anforderungen, die kein gültiges Element im Cache gefunden haben. Wenn das Verhältnis von Fehlern im Vergleich zu Treffern hoch ist, verschwendet die Anwendung Zeit und Ressourcen mit unfruchtbaren Anfragen.

      • SetTypeCmds und GetTypeCmds: Diese Metriken, die mit EngineCPUUtilization korreliert sind, können helfen zu verstehen, ob die Last für Schreibanforderungen signifikant höher ist, gemessen durch SetTypeCmds, oder liest, gemessen durch GetTypeCmds. Wenn die Last überwiegend Lesevorgänge ist, kann die Verwendung mehrerer Read-Replicas die Anforderungen über mehrere Knoten hinweg ausgleichen und die primäre für Schreibvorgänge ersparen. In Clustern mit deaktiviertem Clustermodus können Read-Replicas verwendet werden, indem in der Anwendung mithilfe des Reader-Endpunkts eine zusätzliche Verbindungskonfiguration erstellt wird. ElastiCache Weitere Informationen finden Sie unter Verbindungsendpunkte ermitteln. Die Lesevorgänge müssen an diese zusätzliche Verbindung gesendet werden. Schreibvorgänge werden über den regulären primären Endpunkt durchgeführt. Im Clustermodus ist es ratsam, eine Bibliothek zu verwenden, die Read Replicas nativ unterstützt. Mit den richtigen Flags kann die Bibliothek automatisch die Cluster-Topologie und die Replikatknoten erkennen, die Lesevorgänge über den Befehl READONLY Valkey oder Redis OSS aktivieren und die Leseanfragen an die Replikate senden.

    • Erhöhte Anzahl von Verbindungen:

      • CurrConnectionsundNewConnections:CurrConnectionist die Anzahl der etablierten Verbindungen zum Zeitpunkt der Datenpunkt-Sammlung, währendNewConnectionszeigt an, wie viele Verbindungen in der Periode erstellt wurden.

        Das Erstellen und Behandeln von Verbindungen bedeutet einen erheblichen CPU-Overhead. Darüber hinaus wirkt sich der TCP-3-Wege-Handshake, der zum Erstellen neuer Verbindungen erforderlich ist, negativ auf die Gesamtreaktionszeiten aus.

        Ein ElastiCache Knoten mit Tausenden NewConnections pro Minute bedeutet, dass eine Verbindung mit nur wenigen Befehlen hergestellt und verwendet wird, was nicht optimal ist. Es ist eine bewährte Vorgehensweise, Verbindungen herzustellen und sie für neue Vorgänge wiederzuverwenden. Dies ist möglich, wenn die Clientanwendung Verbindungspooling oder persistente Verbindungen unterstützt und ordnungsgemäß implementiert. Beim Verbindungspooling wird die Anzahl dercurrConnectionshat keine großen Variationen, und dieNewConnectionssollte so niedrig wie möglich sein. Valkey und Redis OSS bieten eine optimale Leistung mit einer geringen Anzahl von CurrConnections. Wenn Sie CurrConnection in der Größenordnung von zehn oder Hunderten halten, wird die Nutzung von Ressourcen minimiert, um einzelne Verbindungen wie Clientpuffer und CPU-Zyklen zu unterstützen, um die Verbindung zu bedienen.

    • Netzwerkdurchsatz:

      • Ermitteln Sie die Bandbreite: Die Netzwerkbandbreite der ElastiCache Knoten ist proportional zur Knotengröße. Da Anwendungen unterschiedliche Merkmale aufweisen, können die Ergebnisse je nach Workload variieren. Beispiele dafür sind Anwendungen mit einer hohen Rate kleiner Anforderungen eher die CPU-Auslastung als der Netzwerkdurchsatz, während größere Schlüssel eine höhere Netzwerkauslastung verursachen. Aus diesem Grund ist es ratsam, die Knoten mit der tatsächlichen Workload zu testen, um die Grenzen besser zu verstehen.

        Die Simulation der Last aus der Anwendung würde genauere Ergebnisse liefern. Benchmark-Tools können jedoch eine gute Vorstellung von den Grenzen geben.

      • In Fällen, in denen die Anforderungen überwiegend Lesevorgänge sind, verringert die Verwendung von Replikaten für Lesevorgänge die Belastung des primären Knotens. Wenn der Anwendungsfall überwiegend Schreibvorgänge ist, wird die Verwendung vieler Replikate die Netzwerknutzung verstärken. Für jedes Byte, das auf den primären Knoten geschrieben wird, werden N Bytes an die Replikate gesendet, wobei N die Anzahl der Replikate ist. Die bewährte Methode für schreibintensive Workloads ist die Verwendung von ElastiCache Redis OSS mit aktiviertem Cluster-Modus, sodass die Schreibvorgänge auf mehrere Shards verteilt oder auf einen Knotentyp mit mehr Netzwerkfähigkeiten skaliert werden können.

      • Die CloudWatchmetrics NetworkBytesIn und NetworkBytesOut geben jeweils die Datenmenge an, die in den Knoten eingeht oder ihn verlässt. ReplicationBytesist der Verkehr, der der Datenreplikation gewidmet ist.

      Weitere Informationen finden Sie unter Netzwerkbezogene Grenzen.

    • Komplexe Befehle: Redis OSS-Befehle werden in einem einzigen Thread bedient, was bedeutet, dass Anfragen sequentiell bedient werden. Ein einzelner langsamer Befehl kann sich auf andere Anforderungen und Verbindungen auswirken, was zu Timeouts führt. Die Verwendung von Befehlen, die auf mehrere Werte, Schlüssel oder Datentypen wirken, muss sorgfältig durchgeführt werden. Verbindungen können abhängig von der Anzahl der Parameter oder der Größe der Ein- oder Ausgabewerte blockiert oder beendet werden.

      Ein berüchtigtes Beispiel ist dieKEYS-Befehl. Es fegt den gesamten Schlüsselraum auf der Suche nach einem bestimmten Muster und blockiert die Ausführung anderer Befehle während der Ausführung. Redis OSS verwendet die Notation „Big O“, um die Komplexität seiner Befehle zu beschreiben.

      Keys Befehl hat O (N) Zeitkomplexität, wobei N die Anzahl der Schlüssel in der Datenbank ist. Je größer die Anzahl der Schlüssel ist, desto langsamer wird der Befehl.KEYSkann auf verschiedene Arten Probleme verursachen: Wenn kein Suchmuster verwendet wird, gibt der Befehl alle verfügbaren Schlüsselnamen zurück. In Datenbanken mit tausend oder Millionen von Elementen wird eine riesige Ausgabe erstellt und die Netzwerkpuffer überflutet.

      Wenn ein Suchmuster verwendet wird, werden nur die Schlüssel, die dem Muster entsprechen, an den Client zurückgegeben. Die Engine wird jedoch immer noch den gesamten Schlüsselraum durchsucht, und die Zeit, um den Befehl abzuschließen, ist gleich.

      Eine Alternative fürKEYSist dieSCAN-Befehl. Es iteriert über den Schlüsselraum und begrenzt die Iterationen in einer bestimmten Anzahl von Elementen, wodurch längere Blöcke auf der Engine vermieden werden.

      Der Scan hat dieCOUNT, der zum Festlegen der Größe der Iterationsblöcke verwendet wird. Der Standardwert ist 10 (10 Elemente pro Iteration).

      Abhängig von der Anzahl der Elemente in der Datenbank sind kleineCOUNT-Werte-Blöcke erfordern mehr Iterationen, um einen vollständigen Scan abzuschließen, und größere Werte halten die Engine bei jeder Iteration länger beschäftigt. Während kleine Zählwerte SCAN langsamer in großen Datenbanken machen, können größere Werte die gleichen Probleme verursachen, die für KEYS beschrieben sind.

      Als Beispiel wird das Ausführen desSCANBefehl mit Zählwert als 10 erfordert 100.000 Wiederholungen in einer Datenbank mit 1 Million Schlüsseln. Wenn die durchschnittliche Netzwerk-Roundtrip-Zeit 0,5 Millisekunden beträgt, werden etwa 50.000 Millisekunden (50 Sekunden) für die Übertragung von Anforderungen ausgegeben.

      Auf der anderen Seite, wenn der Zählwert 100,0000 wäre, wäre eine einzelne Iteration erforderlich und nur 0,5 ms würden ausgegeben, um sie zu übertragen. Die Engine wäre jedoch für andere Operationen vollständig blockiert, bis der Befehl den gesamten Schlüsselraum beendet hat.

      AußerdemKEYS, sind einige andere Befehle potenziell schädlich, wenn sie nicht korrekt verwendet werden. Eine Liste aller Befehle und ihrer jeweiligen Zeitkomplexität finden Sie unter Valkey- und Redis OSS-Befehle.

      Beispiele für mögliche Probleme:

      • Lua-Skripte: Valkey und Redis OSS bieten einen eingebetteten Lua-Interpreter, der die Ausführung von Skripten auf der Serverseite ermöglicht. Lua-Skripte auf Valkey und Redis OSS werden auf Engine-Ebene ausgeführt und sind per Definition atomar, was bedeutet, dass kein anderer Befehl oder Skript ausgeführt werden darf, während ein Skript ausgeführt wird. Lua-Skripte bieten die Möglichkeit, mehrere Befehle, Entscheidungsalgorithmen, Datenanalyse und andere direkt auf der Engine auszuführen. Während die Atomizität von Skripten und die Möglichkeit, die Anwendung zu entladen, verlockend sind, müssen Skripte mit Sorgfalt und für kleine Operationen verwendet werden. Bei ElastiCache aktivierter Option ist die Ausführungszeit von Lua-Skripten auf 5 Sekunden begrenzt. Skripte, die nicht in den Schlüsselraum geschrieben wurden, werden nach Ablauf der 5 Sekunden automatisch beendet. Um Datenbeschädigungen und Inkonsistenzen zu vermeiden, wird der Knoten ein Failover ausgeführt, wenn die Skriptausführung nicht innerhalb von 5 Sekunden abgeschlossen wurde und während der Ausführung Schreibvorgänge stattfand. Transaktionen sind die Alternative, um die Konsistenz mehrerer verwandter wichtiger Änderungen in Redis OSS zu gewährleisten. Eine Transaktion ermöglicht die Ausführung eines Blocks von Befehlen und überwacht vorhandene Schlüssel auf Änderungen. Wenn sich einer der überwachten Schlüssel vor Abschluss der Transaktion ändert, werden alle Änderungen verworfen.

      • Massenlöschung von Elementen: DieDELakzeptiert mehrere Parameter, bei denen es sich um die Schlüsselnamen handelt, die gelöscht werden sollen. Löschvorgänge sind synchron und erfordern erhebliche CPU-Zeit, wenn die Liste der Parameter groß ist oder eine große Liste, eine Menge, eine sortierte Menge oder einen Hash enthält (Datenstrukturen, die mehrere Unterelemente enthalten). Mit anderen Worten, selbst das Löschen eines einzelnen Schlüssels kann erhebliche Zeit in Anspruch nehmen, wenn es viele Elemente enthält. Die Alternative zu DEL isUNLINK, einem asynchronen Befehl, der seit Redis OSS 4 verfügbar ist. UNLINKmuss, DEL wann immer möglich, vorgezogen werden. Ab ElastiCache Redis OSS 6.x verhält sich der DEL Befehl aufgrund des lazyfree-lazy-user-del Parameters so, UNLINK als ob er aktiviert wäre. Weitere Informationen finden Sie unter Redis OSS 6.0-Parameteränderungen.

      • Befehle, die auf mehrere Tasten wirken:DELwurde zuvor als Befehl erwähnt, der mehrere Argumente akzeptiert und seine Ausführungszeit wird direkt proportional dazu sein. Redis OSS bietet jedoch viele weitere Befehle, die ähnlich funktionieren. Als BeispieleMSETundMGETermöglichen das gleichzeitige Einfügen oder Abrufen mehrerer String-Schlüssel. Ihre Nutzung kann vorteilhaft sein, um die Netzwerklatenz zu reduzieren, die mehreren einzelnenSEToderGET-Befehle. Eine umfangreiche Liste von Parametern wirkt sich jedoch auf die CPU-Auslastung aus.

        Obwohl die CPU-Auslastung allein nicht die Ursache für Konnektivitätsprobleme ist, kann es zu viel Zeit für die Verarbeitung einzelner oder einiger Befehle über mehrere Schlüssel zu einem Ausfall anderer Anforderungen führen und die CPU-Gesamtauslastung erhöhen.

        Die Anzahl der Schlüssel und ihre Größe beeinflussen die Komplexität des Befehls und damit die Fertigstellungszeit.

        Weitere Beispiele für Befehle, die auf mehrere Tasten wirken können: HMGET, HMSET, MSETNX, PFCOUNT, PFMERGE, SDIFF, SDIFFSTORE, SINTER, SINTERSTORE, SUNION, SUNIONSTORE, TOUCH, ZDIFF, ZDIFFSTORE, ZINTER oder ZINTERSTORE.

      • Befehle, die auf mehrere Datentypen einwirken: Redis OSS bietet auch Befehle, die auf einen oder mehrere Schlüssel wirken, unabhängig von ihrem Datentyp. ElastiCache für Redis bietet OSS die Metrik KeyBasedCmds zur Überwachung solcher Befehle. Diese Metrik summiert die Ausführung der folgenden Befehle im ausgewählten Zeitraum:

        • Komplexität von O (N):

          • KEYS

        • O(1)

          • EXISTS

          • OBJECT

          • PTTL

          • RANDOMKEY

          • TTL

          • TYPE

          • EXPIRE

          • EXPIREAT

          • MOVE

          • PERSIST

          • PEXPIRE

          • PEXPIREAT

          • UNLINK (O(N), um Speicher zurückzugewinnen. Die Speicherwiederherstellungsaufgabe geschieht jedoch in einem getrennten Thread und blockiert die Engine nicht

        • Unterschiedliche Komplexitätszeiten je nach Datentyp:

          • DEL

          • DUMP

          • RENAMEwird als Befehl mit O (1) -Komplexität betrachtet, führt aberDELintern. Die Ausführungszeit hängt von der Größe des umbenannten Schlüssels ab.

          • RENAMENX

          • RESTORE

          • SORT

        • Große Hashes: Hash ist ein Datentyp, der einen einzelnen Schlüssel mit mehreren Schlüssel-Wert-Unterelementen erlaubt. Jeder Hash kann 4.294.967.295 Elemente speichern und Operationen auf großen Hashes können teuer werden. Ähnlich wieKEYS, haben Hashes dieHKEYSBefehl mit O (N) Zeitkomplexität, wobei N die Anzahl der Elemente im Hash ist.HSCANhat Vorrang vorHKEYS, um lange laufende Befehle zu vermeiden.HDEL,HGETALL,HMGET,HMSETundHVALSsind Befehle, die bei großen Hashes mit Vorsicht verwendet werden sollten.

      • Andere Big-Data-Strukturen: Neben Hashes können andere Datenstrukturen CPU-intensiv sein. Auch Sets, Listen, Sortierte Sets und Hyperloglogs können abhängig von ihrer Größe und den verwendeten Befehlen viel Zeit in Anspruch nehmen. Weitere Informationen zu diesen Befehlen finden Sie unter Valkey- und Redis OSS-Befehle.

Netzwerkkonnektivität

Nach der Überprüfung der Netzwerkkonfigurationen in Bezug auf DNS-Auflösung, Sicherheitsgruppen ACLs, Netzwerk- und Routingtabellen kann die Konnektivität mit dem VPC Reachability Analyzer und den Systemtools überprüft werden.

Reachability Analyzer testet die Netzwerkkonnektivität und bestätigt, ob alle Anforderungen und Berechtigungen erfüllt sind. Für die folgenden Tests benötigen Sie die ENI-ID (Elastic Network Interface Identification) eines der in Ihrer VPC verfügbaren ElastiCache Knoten. Gehen Sie dazu wie folgt vor:

  1. Zu https://console.aws.amazon.com/ec2/v2/home gehen? #NIC:

  2. Filtern Sie die Schnittstellenliste nach Ihrem ElastiCache Clusternamen oder der IP-Adresse, die Sie zuvor bei den DNS-Validierungen erhalten haben.

  3. Notieren oder auf andere Weise speichern Sie die ENI ID. Wenn mehrere Schnittstellen angezeigt werden, überprüfen Sie die Beschreibung, um sicherzustellen, dass sie zum richtigen ElastiCache Cluster gehören, und wählen Sie eine davon aus.

  4. Fahren Sie mit dem nächsten Schritt fort.

  5. Zu https://console.aws.amazon.com/vpc/Hause einen Analysepfad erstellen? # ReachabilityAnalyzer und wählen Sie die folgenden Optionen:

    • Quelltyp: Wählen Sie die Instance, wenn Ihr ElastiCache Client auf einer EC2 Amazon-Instance läuft, oder eine Netzwerkschnittstelle (falls er einen anderen Service verwendet, z. B. AWS Fargate Amazon ECS mit awsvpc-Netzwerk AWS Lambda usw.) und die entsprechende Ressourcen-ID (EC2 Instance- oder ENI-ID);

    • Typ Ziel: Wählen Sie ausNetzwerkschnittstelleund wählen Sie das KontrollkästchenElasticache ENIaus der Liste.

    • Zielport: Geben Sie 6379 für Redis OSS oder 11211 ElastiCache für Memcached an. ElastiCache Dies sind die Ports, die mit der Standardkonfiguration definiert sind, und in diesem Beispiel wird davon ausgegangen, dass sie nicht geändert werden.

    • Protocol (Protokoll): TCP

Erstellen Sie den Analyse-Pfad und warten Sie ein paar Augenblicke auf das Ergebnis. Wenn der Status nicht erreichbar ist, öffnen Sie die Analysedetails und überprüfen Sie dieAnalyse-Explorerfür Details, in denen die Anfragen blockiert wurden.

Wenn die Erreichbarkeitstests bestanden haben, fahren Sie mit der Überprüfung auf Betriebssystemebene fort.

Um die TCP-Konnektivität auf dem ElastiCache Service-Port zu überprüfen: Auf Amazon Linux Nping ist es im Paket enthalten nmap und kann die TCP-Konnektivität auf dem ElastiCache Port testen sowie die Netzwerk-Round-Trip-Zeit für den Verbindungsaufbau bereitstellen. Verwenden Sie dies, um die Netzwerkkonnektivität und die aktuelle Latenz zum ElastiCache Cluster zu überprüfen, wie im Folgenden dargestellt: 

$ sudo nping --tcp -p 6379 example.xxxxxx.ng.0001.use1.cache.amazonaws.com

Starting Nping 0.6.40 ( http://nmap.org/nping ) at 2020-12-30 16:48 UTC
SENT (0.0495s) TCP ...
(Output suppressed )

Max rtt: 0.937ms | Min rtt: 0.318ms | Avg rtt: 0.449ms
Raw packets sent: 5 (200B) | Rcvd: 5 (220B) | Lost: 0 (0.00%)
Nping done: 1 IP address pinged in 4.08 seconds

In der Standardeinstellungnpingsendet 5 Sonden mit einer Verzögerung von 1 Sekunde zwischen ihnen. Sie können die Option „-c“ verwenden, um die Anzahl der Prüfpunkte zu erhöhen und „—delay“, um die Zeit für das Senden eines neuen Tests zu ändern.

Wenn die Tests mitnpingschlägt fehl und dieVPC Reachability Analyzer-Tests bestanden haben, bitten Sie Ihren Systemadministrator, mögliche hostbasierte Firewall-Regeln, asymmetrische Routingregeln oder andere mögliche Einschränkungen auf Betriebssystemebene zu überprüfen.

Überprüfen Sie auf der ElastiCache Konsole, ob die Verschlüsselung während der Übertragung in Ihren ElastiCache Clusterdetails aktiviert ist. Wenn die Verschlüsselung bei der Übertragung aktiviert ist, bestätigen Sie, ob die TLS-Sitzung mit folgendem Befehl eingerichtet werden kann:

openssl s_client -connect example.xxxxxx.use1.cache.amazonaws.com:6379

Eine umfangreiche Ausgabe wird erwartet, wenn die Verbindung und TLS-Verhandlung erfolgreich sind. Überprüfen Sie den in der letzten Zeile verfügbaren Rückgabecode, der Wert muss 0 (ok) sein. Wenn openssl etwas anderes zurückgibt, überprüfen Sie den Grund für den Fehler unter https://www.openssl.org/docs/man1.0.2/man1/verify.html #DIAGNOSTICS.

Wenn alle Infrastruktur- und Betriebssystemtests bestanden wurden, Ihre Anwendung aber immer noch keine Verbindung herstellen kann ElastiCache, überprüfen Sie, ob die Anwendungskonfigurationen den ElastiCache Einstellungen entsprechen. Häufige Fehler sind:

  • Ihre Anwendung unterstützt den ElastiCache Clustermodus nicht und der Clustermodus ElastiCache ist aktiviert;

  • Ihre Anwendung unterstützt TLS/SSL nicht und die Verschlüsselung bei der Übertragung ElastiCache ist aktiviert;

  • Anwendung unterstützt TLS/SSL, verfügt aber nicht über die richtigen Konfigurationsflags oder vertrauenswürdige Zertifizierungsstellen;

Netzwerkbezogene Grenzen

  • Maximale Anzahl von Verbindungen: Es gibt harte Grenzen für gleichzeitige Verbindungen. Jeder ElastiCache Knoten ermöglicht bis zu 65.000 gleichzeitige Verbindungen zwischen allen Clients. Dieses Limit kann mithilfe der eingeschalteten CurrConnections Metriken überwacht werden. CloudWatch Clients haben jedoch auch ihre Grenzen für ausgehende Verbindungen. Überprüfen Sie unter Linux den zulässigen flüchtigen Portbereich mit folgendem Befehl:

    # sysctl net.ipv4.ip_local_port_range
net.ipv4.ip_local_port_range = 32768 60999

    Im vorherigen Beispiel sind 28231 Verbindungen von derselben Quelle zu derselben Ziel-IP (ElastiCache Knoten) und demselben Zielport zulässig. Der folgende Befehl zeigt, wie viele Verbindungen für einen bestimmten ElastiCache Knoten (IP 1.2.3.4) bestehen:

    ss --numeric --tcp state connected "dst 1.2.3.4 and dport == 6379" | grep -vE '^State' | wc -l

    Wenn die Zahl zu hoch ist, wird Ihr System möglicherweise überlastet und versucht, die Verbindungsanforderungen zu verarbeiten. Es ist ratsam, Techniken wie Verbindungspooling oder persistente Verbindungen zu implementieren, um die Verbindungen besser zu handhaben. Wenn möglich, konfigurieren Sie den Verbindungspool so, dass die maximale Anzahl von Verbindungen auf einige hundert begrenzt wird. Außerdem wäre eine Back-Off-Logik zur Behandlung von Timeouts oder anderen Verbindungsausnahmen ratsam, um im Falle von Problemen eine Verbindungsabwanderung zu vermeiden.

  • Grenzwerte für den Netzwerkverkehr: Überprüfen Sie die folgenden CloudWatch Metriken für Redis OSS, um mögliche Netzwerklimits zu identifizieren, die auf dem Knoten erreicht werden: ElastiCache

    • NetworkBandwidthInAllowanceExceeded/NetworkBandwidthOutAllowanceExceeded: Netzwerkpakete geformt, weil der Durchsatz das aggregierte Bandbreitenlimit überschritten hat.

      Es ist wichtig zu beachten, dass jedes Byte, das auf den primären Knoten geschrieben wird, auf N Replikate repliziert wird, wobei N die Anzahl der Replikate ist. Cluster mit kleinen Knotentypen, mehreren Replikaten und intensiven Schreibanforderungen können den Replikationsrückstand möglicherweise nicht bewältigen. In solchen Fällen ist es eine bewährte Methode, hochzuskalieren (Knoten-Typ ändern), aufzuskalieren (Shards in Cluster mit aktiviertem Cluster-Modus hinzufügen), die Anzahl der Replikate zu reduzieren oder die Anzahl der Schreibvorgänge zu minimieren.

    • NetworkConntrackAllowanceExceeded: Pakete geformt, weil die maximale Anzahl von Verbindungen, die über alle dem Knoten zugewiesenen Sicherheitsgruppen nachverfolgt werden, überschritten wurde. Neue Verbindungen werden in diesem Zeitraum wahrscheinlich fehlschlagen.

    • NetworkPackets PerSecondAllowanceExceeded: Maximale Anzahl von Paketen pro Sekunde überschritten. Arbeitslasten, die auf einer hohen Rate von sehr kleinen Anforderungen basieren, können diese Grenze vor der maximalen Bandbreite erreichen.

    Die oben genannten Metriken sind der ideale Weg, um zu bestätigen, dass Knoten ihre Netzwerklimits erreichen. Grenzwerte können jedoch auch von Plateaus in Netzwerkmetriken identifiziert werden.

    Wenn die Plateaus über längere Zeiträume beobachtet werden, folgen sie wahrscheinlich Replikationsverzögerung, Zunahme der Bytes, die für den Cache verwendet werden, Drop auf freien Speicher, hohe Swap und CPU-Auslastung. EC2 Amazon-Instances haben auch Netzwerklimits, die anhand von ENA-Treibermetriken verfolgt werden können. Linux-Instances mit erweiterter Netzwerkunterstützung und ENA-Treibern 2.2.10 oder höher können die Limitindikatoren mit folgendem Befehl überprüfen:

    # ethtool -S eth0 | grep "allowance_exceeded"

CPU-Verwendung

Die Metrik zur CPU-Auslastung ist der Ausgangspunkt der Untersuchung, und die folgenden Punkte können dabei helfen, mögliche Probleme ElastiCache einzugrenzen:

  • Redis OSS SlowLogs: In der ElastiCache Standardkonfiguration werden die letzten 128 Befehle beibehalten, deren Ausführung mehr als 10 Millisekunden gedauert hat. Der Verlauf der langsamen Befehle wird während der Motorlaufzeit beibehalten und geht im Falle eines Fehlers oder eines Neustarts verloren. Wenn die Liste 128 Einträge erreicht, werden alte Ereignisse entfernt, um Raum für neue zu öffnen. Die Größe der Liste der langsamen Ereignisse und die Ausführungszeit, die als langsam betrachtet wird, kann durch die Parameter slowlog-max-len und slowlog-log-slower-thanin einer Benutzerdefinierte Parametergruppe angepasst werden. Die slowlogs-Liste kann abgerufen werden, indemSLOWLOG GET 128auf dem Motor, 128 sind die letzten 128 langsamen Befehle gemeldet. Jeder Spielereintrag hat folgende Felder:

    1) 1) (integer) 1 -----------> Sequential ID
   2) (integer) 1609010767 --> Timestamp (Unix epoch time)of the Event
   3) (integer) 4823378 -----> Time in microseconds to complete the command.
   4) 1) "keys" -------------> Command
      2) "*" ----------------> Arguments 
   5) "1.2.3.4:57004"-> Source

    Das obige Ereignis geschah am 26. Dezember um 19:26:07 UTC, dauerte 4,8 Sekunden (4,823 ms) und wurde durch dieKEYSBefehl vom Client 1.2.3.4 angefordert.

    Unter Linux kann der Zeitstempel mit dem Befehlsdatum konvertiert werden:

    $ date --date='@1609010767'
Sat Dec 26 19:26:07 UTC 2020

    Mit Python:

    >>> from datetime import datetime
>>> datetime.fromtimestamp(1609010767)
datetime.datetime(2020, 12, 26, 19, 26, 7)

    Oder unter Windows mit: PowerShell

    PS D:\Users\user> [datetimeoffset]::FromUnixTimeSeconds('1609010767')
DateTime      : 12/26/2020 7:26:07 PM
UtcDateTime  
                : 12/26/2020 7:26:07 PM
LocalDateTime : 12/26/2020 2:26:07 PM
Date          : 12/26/2020 12:00:00 AM
Day           : 26
DayOfWeek    
                : Saturday
DayOfYear     : 361
Hour          : 19
Millisecond   : 0
Minute        : 26
Month        
                : 12
Offset        : 00:00:00Ticks         : 637446075670000000
UtcTicks     
                : 637446075670000000
TimeOfDay     : 19:26:07
Year          : 2020

    Viele langsame Befehle in kurzer Zeit (gleiche Minute oder weniger) sind ein Grund zur Besorgnis. Überprüfen Sie die Art der Befehle und wie sie optimiert werden können (siehe vorangegangene Beispiele). Wenn Befehle mit O (1) -Zeitkomplexität häufig gemeldet werden, überprüfen Sie die anderen Faktoren für eine hohe CPU-Auslastung, die zuvor erwähnt wurden.

  • Latenzmetriken: ElastiCache Für Redis bietet OSS CloudWatch Metriken zur Überwachung der durchschnittlichen Latenz für verschiedene Befehlsklassen. Der Datenpunkt wird berechnet, indem die Gesamtzahl der Ausführungen von Befehlen in der Kategorie durch die gesamte Ausführungszeit in der Periode dividiert wird. Es ist wichtig zu verstehen, dass Latenzmetrikergebnisse ein Aggregat mehrerer Befehle sind. Ein einzelner Befehl kann unerwartete Ergebnisse wie Timeouts verursachen, ohne signifikante Auswirkungen auf die Metriken zu haben. In solchen Fällen wären die Slowlog-Ereignisse eine genauere Informationsquelle. Die folgende Liste enthält die verfügbaren Latenzmetriken und die entsprechenden Befehle, die sie betreffen.

    • EvalBasedCmdsLatency: bezieht sich auf Lua-Script-Befehle,,; eval evalsha

    • GeoSpatialBasedCmdsLatency: geodist, geohash, geopos, georadius, georadiusbymember, geoadd;

    • GetTypeCmdsLatency: Befehle lesen, unabhängig vom Datentyp;

    • HashBasedCmdsLatency: hexists, hget, hgetall, hkeys, hlen, hmget, hvals, hstrlen, hdel, hincrby, hincrbyfloat, hmset, hset, hsetnx;

    • HyperLogLogBasedCmdsLatency: pfselftest, pfcount, pfdebug, pfadd, pfmerge;

    • KeyBasedCmdsLatency: Befehle, die auf verschiedene Datentypen einwirken können:dump,,exists,keys,object,pttl,randomkey,ttl,type,del,,expire,expireat,move,persist,pexpire,pexpireat,rename,,renamenx,restoreK,sort,unlink;

    • ListBasedCmdsLatency: lindex, len, lrange, blpop, brpop, brpoplpush, linsert, lpop, push, pushx, lrem, let, ltrim, rpop, rpoplpush, rpush, rpushx;

    • PubSubBasedCmdsLatency: abonnieren, veröffentlichen, pubsub, abbestellen, abonnieren, abbestellen;

    • SetBasedCmdsLatency: scard, sdiff, sinter, sismember, smembers, srandmember, sunion, sadd, sdiffstore, sinterstore, smove, spop, srem, sunionstore;

    • SetTypeCmdsLatency: Befehle schreiben, unabhängig vom Datentyp;

    • SortedSetBasedCmdsLatency: zcard, zcount, zrange, zrangebyscore, zrank, zrevrange, zrevrangebyscore, zrevrank, zscore, zrangebylex, zrevrangebylex, zlexcount, zadd. zincrby, zinterstore, zrem, zremrangebyrank, zremrangebyscore, zunionstore, zremrangebylex, zpopmax, zpopmin, bzpopmin, bzpopmax;

    • StringBasedCmdsLatency: bitcount, get, getbit, getrange, mget, strlen, substr, bitpos, append, bitop, bitfield, decr, decrby, getset, incr, incrby, incrbyfloat, mset, msetnx, psetex, set, setbit, setex, setnx, setrange;

    • StreamBasedCmdsLatency: xrange, xrevrange, xlen, xread, xpending, xinfo, xadd, xgroup, readgroup, xack, xclaim, xdel, xtrim, xsetid;

  • Redis OSS-Laufzeitbefehle:

    • info commandstats: Stellt eine Liste der Befehle bereit, die seit dem Start der Engine ausgeführt wurden, ihre kumulative Anzahl der Ausführungen, die Gesamtausführungszeit und die durchschnittliche Ausführungszeit pro Befehl;

    • Client-Liste: Bietet eine Liste der aktuell verbundenen Clients und relevante Informationen wie Pufferverwendung, zuletzt ausgeführter Befehl usw.;

  • Backup und Replikation: Verwenden Sie ElastiCache für Redis OSS-Versionen vor 2.8.22 einen Fork-Prozess, um Backups zu erstellen und vollständige Synchronisationen mit den Replikaten durchzuführen. Diese Methode kann in erheblichem Speicheraufwand für schreibintensive Anwendungsfälle auftreten.

    Beginnend mit ElastiCache Redis OSS 2.8.22 wurde eine Sicherungs- und Replikationsmethode ohne Forkless eingeführt. AWS Die neue Methode kann Schreibvorgänge verzögern, um Fehler zu vermeiden. Beide Methoden können Perioden höherer CPU-Auslastung verursachen, zu höheren Reaktionszeiten führen und somit zu Client-Timeouts während ihrer Ausführung führen. Überprüfen Sie immer, ob die Client-Fehler während des Backup-Fensters oder derSaveInProgress-Metrik war 1 in der Periode. Es ist ratsam, das Backup-Fenster für Zeiten geringer Auslastung zu planen, um die Möglichkeit von Problemen mit Clients oder Backup-Fehlern zu minimieren.

Verbindungen, die von der Serverseite beendet werden

Die Standardeinstellung ElastiCache für die Redis OSS-Konfiguration sorgt dafür, dass die Client-Verbindungen auf unbestimmte Zeit hergestellt werden. In einigen Fällen kann eine Verbindungsbeendigung jedoch wünschenswert sein. Zum Beispiel:

  • Fehler in der Client-Anwendung können dazu führen, dass Verbindungen vergessen und im Leerlauf gehalten werden. Dies wird als „Verbindungsleck „bezeichnet und die Folge ist eine stetige Zunahme der Anzahl etablierter Verbindungen, die auf der CurrConnections-Metrik beobachtet werden. Dieses Verhalten kann zu einer Überlastung des Clients oder ElastiCache der Seite führen. Wenn eine sofortige Korrektur von der Client-Seite aus nicht möglich ist, legen einige Administratoren in ihrer ElastiCache Parametergruppe einen Wert für das“ Timeout „fest. Das Timeout ist die Zeit in Sekunden, die erlaubt ist, dass Verbindungen im Leerlauf bestehen bleiben. Wenn der Client innerhalb dieses Zeitraums keine Anfrage stellt, beendet die Engine die Verbindung, sobald die Verbindung den Timeout-Wert erreicht. Kleine Zeitüberschreitungswerte können zu unnötigen Trennungen führen, und Clients müssen sie ordnungsgemäß behandeln und eine erneute Verbindung herstellen, was zu Verzögerungen führt.

  • Der Speicher, der zum Speichern von Schlüsseln verwendet wird, wird für Clientpuffer freigegeben. Langsame Clients mit großen Anfragen oder Antworten benötigen möglicherweise eine beträchtliche Menge an Speicher, um ihre Puffer zu verarbeiten. Die Standardeinstellung ElastiCache für Redis OSS-Konfigurationen schränkt die Größe der regulären Client-Ausgabepuffer nicht ein. Wenn das Symbolmaxmemory-Limit erreicht wird, versucht die Engine, Elemente zu vertreiben, um die Pufferverwendung zu erfüllen. Bei extrem wenig Arbeitsspeicher kann sich OSS ElastiCache für Redis dazu entscheiden, die Verbindung von Clients zu trennen, die große Client-Ausgabepuffer verbrauchen, um Speicherplatz freizugeben und den Zustand des Clusters zu erhalten.

    Es ist möglich, die Größe von Clientpuffern mit benutzerdefinierten Konfigurationen zu begrenzen, und Clients, die das Limit erreichen, werden getrennt. Clients sollten jedoch in der Lage sein, unerwartete Trennungen zu verarbeiten. Die Parameter für die Puffergröße für reguläre Clients sind die folgenden:

    • client-query-buffer-limit: Maximale Größe einer einzelnen Eingabeanforderung;

    • client-output-buffer-limit-normal-soft-limit: Soft-Limit für Client-Verbindungen. Die Verbindung wird beendet, wenn sie länger als die für client-output-buffer-limit - definierte Zeit in Sekunden über dem Soft-Limit bleibt normal-soft-seconds oder wenn sie das Hard-Limit erreicht;

    • client-output-buffer-limit-normal-soft-seconds: Zulässige Zeit für Verbindungen, die den Wert von client-output-buffer-limit - überschreitennormal-soft-limit;

    • client-output-buffer-limit-normal-hard-limit: Eine Verbindung, die dieses Limit erreicht, wird sofort beendet.

    Neben den regulären Client-Puffern steuern die folgenden Optionen den Puffer für Replikatknoten (und) Clients: Pub/Sub (Publish/Subscribe

    • client-output-buffer-limit-replica-hard-limit;

    • client-output-buffer-limit-replica-soft-seconds;

    • client-output-buffer-limit-replica-hard-limit;

    • client-output-buffer-limit-pubsub-soft-limit;

    • client-output-buffer-limit-pubsub-soft-seconds;

    • client-output-buffer-limit-pubsub-hard-limit;

Clientseitige Fehlerbehebung für Amazon-Instances EC2

Die Auslastung und Reaktionsfähigkeit auf der Client-Seite können sich auch auf die Anfragen an auswirken. ElastiCache EC2 Bei der Behebung von zeitweiligen Verbindungs- oder Timeout-Problemen müssen die Beschränkungen für Instanzen und Betriebssysteme sorgfältig geprüft werden. Einige wichtige Punkte zu beachten:

  • CPU:

    • EC2 CPU-Auslastung der Instanz: Stellen Sie sicher, dass die CPU nicht ausgelastet ist oder fast zu 100 Prozent ausgelastet ist. Historische Analysen können wie folgt durchgeführt werden. Beachten Sie jedoch CloudWatch, dass die Granularität der Datenpunkte entweder 1 Minute (bei aktivierter detaillierter Überwachung) oder 5 Minuten beträgt;

    • Wenn Sie EC2 Burstable-Instances verwenden, stellen Sie sicher, dass ihr CPU-Guthaben nicht aufgebraucht ist. Diese Informationen sind in der Metrik verfügbar. CPUCreditBalance CloudWatch

    • Kurze Perioden mit hoher CPU-Auslastung können zu Timeouts führen, ohne dass eine 100-prozentige Auslastung berücksichtigt wird. CloudWatch Solche Fälle erfordern eine Echtzeitüberwachung mit Betriebssystem-Tools wie top,ps und mpstat.

  • Netzwerk

    • Überprüfen Sie, ob der Netzwerkdurchsatz gemäß den Instance-Funktionen unter akzeptablen Werten liegt. Weitere Informationen finden Sie unter EC2 Amazon-Instance-Typen

    • Bei Instances mit Erweiterten ena-Netzwerktreiber, überprüfen Sie die EN-Statistiken für Timeouts oder überschritten Limits. Die folgenden Statistiken sind nützlich, um die Sättigung der Netzwerklimits zu bestätigen:

      • bw_in_allowance_exceeded/bw_out_allowance_exceeded: Anzahl der Pakete, die durch übermäßigen eingehenden oder ausgehenden Durchsatz geformt werden;

      • conntrack_allowance_exceeded: Anzahl der Pakete, die aufgrund von Sicherheitsgruppen Verbindungsverfolgung von Grenzen gelöscht wurden. Neue Verbindungen werden fehlschlagen, wenn diese Grenze gesättigt ist;

      • linklocal_allowance_exceeded: Anzahl der Pakete, die aufgrund übermäßiger Anfragen an Instance-Meta-Daten gelöscht wurden, NTP über VPC DNS. Das Limit beträgt 1024 Pakete pro Sekunde für alle Dienste;

      • pps_allowance_exceeded: Anzahl der Pakete, die aufgrund übermäßiger Pakete pro Sekunde verworfen wurden. Das PPS-Limit kann erreicht werden, wenn der Netzwerkverkehr aus Tausenden oder Millionen sehr kleiner Anfragen pro Sekunde besteht. ElastiCache Der Datenverkehr kann optimiert werden, um Netzwerkpakete über Pipelines oder Befehle, die beispielsweise MGET mehrere Operationen gleichzeitig ausführen, besser zu nutzen. GET

Aufschlüsselung der Zeit, die zum Abschließen einer einzelnen Anfrage benötigt wird

  • Im Netzwerk sind: Tcpdump und Wireshark (tshark auf der Befehlszeile) praktische Tools, um zu verstehen, wie viel Zeit die Anfrage benötigt hat, um das Netzwerk zu erreichen, die ElastiCache Engine zu starten und eine Antwort zu erhalten. Im folgenden Beispiel wird eine einzelne Anforderung hervorgehoben, die mit dem folgenden Befehl erstellt wurde: 

    $ echo ping | nc example.xxxxxx.ng.0001.use1.cache.amazonaws.com 6379
+PONG

    Parallel zum obigen Befehl wurde tcpdump ausgeführt und zurückgegeben:

    $ sudo tcpdump -i any -nn port 6379 -tt
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
1609428918.917869 IP 172.31.11.142.40966
    > 172.31.11.247.6379: Flags [S], seq 177032944, win 26883, options [mss 8961,sackOK,TS val 27819440 ecr 0,nop,wscale 7], length 0
1609428918.918071 IP 172.31.11.247.6379 > 172.31.11.142.40966: Flags [S.], seq 53962565, ack 177032945, win
    28960, options [mss 1460,sackOK,TS val 3788576332 ecr 27819440,nop,wscale 7], length 0
1609428918.918091 IP 172.31.11.142.40966 > 172.31.11.247.6379: Flags [.], ack 1, win 211, options [nop,nop,TS val 27819440 ecr 3788576332], length 0
1609428918.918122
    IP 172.31.11.142.40966 > 172.31.11.247.6379: Flags [P.], seq 1:6, ack 1, win 211, options [nop,nop,TS val 27819440 ecr 3788576332], length 5: RESP "ping"
1609428918.918132 IP 172.31.11.142.40966 > 172.31.11.247.6379: Flags [F.], seq 6, ack
    1, win 211, options [nop,nop,TS val 27819440 ecr 3788576332], length 0
1609428918.918240 IP 172.31.11.247.6379 > 172.31.11.142.40966: Flags [.], ack 6, win 227, options [nop,nop,TS val 3788576332 ecr 27819440], length 0
1609428918.918295
    IP 172.31.11.247.6379 > 172.31.11.142.40966: Flags [P.], seq 1:8, ack 7, win 227, options [nop,nop,TS val 3788576332 ecr 27819440], length 7: RESP "PONG"
1609428918.918300 IP 172.31.11.142.40966 > 172.31.11.247.6379: Flags [.], ack 8, win
    211, options [nop,nop,TS val 27819441 ecr 3788576332], length 0
1609428918.918302 IP 172.31.11.247.6379 > 172.31.11.142.40966: Flags [F.], seq 8, ack 7, win 227, options [nop,nop,TS val 3788576332 ecr 27819440], length 0
1609428918.918307
    IP 172.31.11.142.40966 > 172.31.11.247.6379: Flags [.], ack 9, win 211, options [nop,nop,TS val 27819441 ecr 3788576332], length 0
^C
10 packets captured
10 packets received by filter
0 packets dropped by kernel

    Aus der obigen Ausgabe können wir bestätigen, dass der TCP-3-Wege-Handshake in 222 Mikrosekunden (918091 - 917869) abgeschlossen wurde und der Ping-Befehl in 173 Mikrosekunden (918295 - 918122) zurückgegeben wurde.

    Es dauerte 438 Mikrosekunden (918307 - 917869) vom Anfordern bis zum Schließen der Verbindung. Diese Ergebnisse würden bestätigen, dass Netz- und Triebwerksreaktionszeiten gut sind und sich die Untersuchung auf andere Komponenten konzentrieren kann.

  • Auf dem Betriebssystem:Stracekann helfen, Zeitlücken auf Betriebssystemebene zu identifizieren. Die Analyse der tatsächlichen Anwendungen wäre viel umfangreicher und spezialisierte Anwendungsprofiler oder Debugger sind ratsam. Das folgende Beispiel zeigt nur, ob die Basisbetriebssystemkomponenten wie erwartet funktionieren, andernfalls können weitere Untersuchungen erforderlich sein. Wenn wir denselben Redis PING OSS-Befehl verwenden, erhalten strace wir:

    $ echo ping | strace -f -tttt -r -e trace=execve,socket,open,recvfrom,sendto nc example.xxxxxx.ng.0001.use1.cache.amazonaws.com (http://example.xxxxxx.ng.0001.use1.cache.amazonaws.com/)
    6379
1609430221.697712 (+ 0.000000) execve("/usr/bin/nc", ["nc", "example.xxxxxx.ng.0001.use"..., "6379"], 0x7fffede7cc38 /* 22 vars */) = 0
1609430221.708955 (+ 0.011231) socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
1609430221.709084
    (+ 0.000124) socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
1609430221.709258 (+ 0.000173) open("/etc/nsswitch.conf", O_RDONLY|O_CLOEXEC) = 3
1609430221.709637 (+ 0.000378) open("/etc/host.conf", O_RDONLY|O_CLOEXEC) = 3
1609430221.709923
    (+ 0.000286) open("/etc/resolv.conf", O_RDONLY|O_CLOEXEC) = 3
1609430221.711365 (+ 0.001443) open("/etc/hosts", O_RDONLY|O_CLOEXEC) = 3
1609430221.713293 (+ 0.001928) socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 3
1609430221.717419
    (+ 0.004126) recvfrom(3, "\362|\201\200\0\1\0\2\0\0\0\0\rnotls20201224\6tihew"..., 2048, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("172.31.0.2")}, [28->16]) = 155
1609430221.717890 (+ 0.000469) recvfrom(3, "\204\207\201\200\0\1\0\1\0\0\0\0\rnotls20201224\6tihew"...,
    65536, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("172.31.0.2")}, [28->16]) = 139
1609430221.745659 (+ 0.027772) socket(AF_INET, SOCK_STREAM, IPPROTO_TCP) = 3
1609430221.747548 (+ 0.001887) recvfrom(0, 0x7ffcf2f2ca50, 8192,
    0, 0x7ffcf2f2c9d0, [128]) = -1 ENOTSOCK (Socket operation on non-socket)
1609430221.747858 (+ 0.000308) sendto(3, "ping\n", 5, 0, NULL, 0) = 5
1609430221.748048 (+ 0.000188) recvfrom(0, 0x7ffcf2f2ca50, 8192, 0, 0x7ffcf2f2c9d0, [128]) = -1 ENOTSOCK
    (Socket operation on non-socket)
1609430221.748330 (+ 0.000282) recvfrom(3, "+PONG\r\n", 8192, 0, 0x7ffcf2f2c9d0, [128->0]) = 7
+PONG
1609430221.748543 (+ 0.000213) recvfrom(3, "", 8192, 0, 0x7ffcf2f2c9d0, [128->0]) = 0
1609430221.752110
    (+ 0.003569) +++ exited with 0 +++

    Im obigen Beispiel dauerte der Befehl etwas mehr als 54 Millisekunden (752110 - 697712 = 54398 Mikrosekunden).

    Eine beträchtliche Zeit, etwa 20 ms, wurde benötigt, um nc zu instanziieren und die Namensauflösung durchzuführen (von 697712 bis 717890), danach waren 2 ms erforderlich, um den TCP-Socket zu erstellen (745659 bis 747858) und 0,4 ms (747858 bis 748330), um die Antwort für die Anfrage zu senden und zu erhalten.