Anhaltende Verbindungsprobleme - Amazon ElastiCache
SicherheitsgruppenNetzwerk ACLsRouting-TabellenDNSLösungIdentifizieren von Problemen mit serverseitiger DiagnoseNetzwerkkonnektivitätNetzwerkbezogene GrenzenCPUVerwendungVerbindungen, die von der Serverseite beendet werdenClientseitige Fehlerbehebung für Amazon-Instances EC2Aufschlü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 (EC2Instance, AWS Lambda Funktion, ECS Amazon-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 TCP ausgehenden 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 einem 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 dieselben Ressourcen ElastiCache und die Client-Ressource ACL zugewiesen werden, 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 sequentiell, was bedeutet, dass die Regel, deren niedrigste Zahl dem Verkehr entspricht, sie zulässt oder verweigert. Die Mindestkonfiguration, um den Valkey- oder OSS Redis-Verkehr zuzulassen, ist:

Clientseitiges Netzwerk: ACL

  • Regeln für eingehenden Datenverkehr:

  • Regelnummer: vorzugsweise niedriger als jede Ablehnungsregel;

  • Typ: Benutzerdefinierte TCP Regel;

  • 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;

  • TypTCP: Benutzerdefinierte Regel;

  • 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 NetzwerkACL:

  • Regeln für eingehenden Datenverkehr:

  • Regelnummer: vorzugsweise niedriger als jede Ablehnungsregel;

  • Typ: Benutzerdefinierte TCP Regel;

  • 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;

  • TypTCP: Benutzerdefinierte Regel;

  • 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.

DNSLö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 der ElastiCache Engine sind gängige Informationsquellen, um mögliche Ursachen für Verbindungsprobleme zu identifizieren. Eine gute Analyse beginnt üblicherweise mit den folgenden Elementen:

  • CPUVerwendung: 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 EngineCPUUtilizationbietet die CPU Nutzung, die für den Valkey- oder OSS Redis-Prozess vorgesehen ist, und CPUUtilization die Nutzung für alle. vCPUs Knoten mit mehr als einem V haben CPU normalerweise unterschiedliche Werte für CPUUtilization undEngineCPUUtilization, wobei der zweite Wert in der Regel höher ist. Ein hoher Wert EngineCPUUtilization kann durch eine erhöhte Anzahl von Anfragen oder durch komplexe Vorgänge verursacht werden, deren Ausführung viel CPU Zeit in Anspruch nimmt. 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 OSS Befehl READONLYValkey oder Redis 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 Verarbeiten von Verbindungen ist mit erheblichem Aufwand verbunden. CPU Darüber hinaus wirkt sich der TCP Drei-Wege-Handshake, der zum Herstellen neuer Verbindungen erforderlich ist, negativ auf die Gesamtantwortzeiten 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 optimale Leistung bei einer geringen Anzahl von. currConnections Wenn Sie die currConnection Reihenfolge von zehn oder hundert einhalten, wird der Ressourcenverbrauch für die Unterstützung einzelner Verbindungen wie Client-Puffer und CPU Zyklen zur Bereitstellung der Verbindung minimiert.

    • 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. Beispielsweise wirken sich Anwendungen mit einer hohen Anzahl kleiner Anfragen tendenziell stärker auf die CPU Nutzung als auf den Netzwerkdurchsatz aus, während größere Schlüssel zu einer höheren Netzwerkauslastung führen. 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 (RedisOSS) mit aktiviertem Clustermodus, sodass die Schreibvorgänge auf mehrere Shards verteilt werden können, oder die Skalierung auf einen Knotentyp mit mehr Netzwerkfunktionen.

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

      Weitere Informationen finden Sie unter Netzwerkbezogene Grenzen.

    • Komplexe Befehle: OSS Redis-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 OSS Redis-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 OSS Redis 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 nehmen CPU viel Zeit in Anspruch, wenn die Liste der Parameter umfangreich ist oder eine große Liste, einen Satz, eine sortierte Menge oder einen Hash (Datenstrukturen mit mehreren Unterelementen) enthält. 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 dazu DEL ist ein asynchroner BefehlUNLINK, der seit Redis 4 verfügbar ist. OSS UNLINKmuss, DEL wann immer möglich, vorgezogen werden. Ab ElastiCache (RedisOSS) 6.x sorgt der lazyfree-lazy-user-del Parameter dafür, dass sich der DEL Befehl so verhält, 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 Verwendung aus.

        Die CPU Auslastung allein ist zwar nicht die Ursache für Verbindungsprobleme, aber wenn zu viel Zeit für die Verarbeitung einzelner oder weniger Befehle über mehrere Schlüssel aufgewendet wird, kann dies dazu führen, dass andere Anfragen fehlschlagen und die CPU Gesamtauslastung erhöht wird.

        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 bietet OSS auch Befehle, die auf einen oder mehrere Schlüssel wirken, unabhängig von ihrem Datentyp. ElastiCache (RedisOSS) stellt die Metrik KeyBasedCmds zur Überwachung solcher Befehle bereit. 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 auch andere Datenstrukturen intensiv sein. CPU 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-Befehle. OSS

Netzwerkkonnektivität

Nach der Überprüfung der Netzwerkkonfigurationen in Bezug auf DNS Auflösung, SicherheitsgruppenACLs, 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 Ihrem System verfügbaren ElastiCache Knoten. VPC Gehen Sie dazu wie folgt vor:

  1. Gehen Sie zu https://console.aws.amazon.com/ec2/v2/home? #: 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 Sie sich die ID oder speichern Sie sie auf andere Weise. ENI 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 usw.), und die entsprechende Ressourcen-ID (EC2Instance oder ENI ID); AWS Lambda

    • Zieltyp: Wählen Sie Network Interface und wählen Sie den Elasticache ENI aus der Liste aus.

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

    • 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 angeben. Verwenden Sie diese Option, 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 mit nping fehlschlagen und die VPCReachability Analyzer-Tests bestanden haben, bitten Sie Ihren Systemadministrator, mögliche hostbasierte Firewallregeln, asymmetrische Routing-Regeln 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 Clusterdetails aktiviert ist. ElastiCache Wenn die Verschlüsselung bei der Übertragung aktiviert ist, überprüfen Sie mit dem folgenden Befehl, ob die TLS Sitzung eingerichtet werden kann:

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

Wenn die Verbindung und die TLS Verhandlung erfolgreich sind, wird eine umfangreiche Ausgabe erwartet. Ü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ütztTLS/SSLnicht und die Verschlüsselung bei der Übertragung ElastiCache ist aktiviert;

  • Die Anwendung unterstütztTLS/SSL, verfügt aber nicht über die richtigen Konfigurationsflags oder vertrauenswürdigen 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 diese Plateaus über einen längeren Zeitraum beobachtet werden, wird es wahrscheinlich zu Verzögerungen bei der Replikation, einer Zunahme der für den Cache verwendeten Byte, einem Rückgang des freien Speichers, einem hohen Auslagerungsgrad und hoher Auslastung kommen. CPU EC2Amazon-Instances haben auch Netzwerklimits, die anhand von ENATreibermetriken verfolgt werden können. Linux-Instances mit erweiterter Netzwerkunterstützung und ENA Treibern 2.2.10 oder neuer können die Limit-Zähler mit dem folgenden Befehl überprüfen:

    # ethtool -S eth0 | grep "allowance_exceeded"

CPUVerwendung

Die CPU Nutzungsmetrik ist der Ausgangspunkt für die 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 oben genannte Ereignis ereignete sich am 26. Dezember um 19:26:07 UTC Uhr. Es dauerte 4,8 Sekunden (4,823 ms) und wurde durch den vom Client angeforderten Befehl 1.2.3.4 verursacht. KEYS

    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 PowerShell unter Windows mit:

    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 häufig Befehle mit O (1) -Zeitkomplexität gemeldet werden, überprüfen Sie die anderen oben genannten Faktoren für eine hohe CPU Auslastung.

  • Latenzmetriken: ElastiCache (RedisOSS) bietet CloudWatch Metriken zur Überwachung der durchschnittlichen Latenz für verschiedene Klassen von Befehlen. 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;

  • OSSRedis-Laufzeitbefehle:

    • info commandstats: Stellt eine Liste der Befehle bereit, die seit dem Start der OSS Redis-Engine ausgeführt wurden, ihre kumulative Anzahl an 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: ElastiCache (Redis-OSS) Versionen vor 2.8.22 verwenden 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 Forkless-Backup- und Replikationsmethode eingeführt. AWS Die neue Methode kann Schreibvorgänge verzögern, um Fehler zu vermeiden. Beide Methoden können zu Zeiten höherer CPU Auslastung, zu längeren Antwortzeiten und folglich zu Timeouts beim Client 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 Standardkonfiguration ElastiCache (RedisOSS) 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 einreicht, beendet die OSS Redis-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 Standardkonfigurationen ElastiCache (RedisOSS) schränken 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 entscheidet sich ElastiCache (RedisOSS) möglicherweise dafür, 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 Clientpuffern steuern die folgenden Optionen den Puffer für Replikatknoten und Pub/Sub (Publish/Sub) Clients:

    • 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 EC2Bei 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:

    • EC2CPUNutzung der Instance: Stellen Sie sicher, dass CPU die Auslastung nicht erreicht wurde oder fast zu 100 Prozent erreicht ist. Die historische Analyse kann 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 EC2Burstable-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 EC2Amazon-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-Metadaten verworfen wurden, NTP via. 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 mehrere Operationen gleichzeitig ausführen, besser zu nutzen, MGET anstatt 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

    Anhand der obigen Ausgabe können wir bestätigen, dass der TCP Drei-Wege-Handshake in 222 Mikrosekunden (918091 — 917869) abgeschlossen wurde und der Ping-Befehl innerhalb von 173 Mikrosekunden (918295 — 918122) gesendet und 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 OSS PING strace wir denselben Redis-Befehl verwenden, erhalten 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).

    Für die Instanziierung von nc und die Namensauflösung (von 697712 bis 717890) wurde eine beträchtliche Zeit, etwa 20 ms, benötigt. Danach waren 2 ms erforderlich, um den TCP Socket zu erstellen (745659 bis 747858) und 0,4 ms (747858 bis 748330), um die Antwort auf die Anfrage zu senden und zu empfangen.