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
Die folgenden Punkte müssen bei der Behebung anhaltender Verbindungsprobleme überprüft werden mit ElastiCache:
Sicherheitsgruppen
Sicherheitsgruppen sind virtuelle Firewalls, die Ihren ElastiCache Client (EC2-Instance, AWS Lambda Funktion, Amazon ECS-Container usw.) und ElastiCache den 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 ElastiCache auf der Seite überschritten wurden.
Sie können dem Client und dem ElastiCache Cluster gleichzeitig eine einzelne Sicherheitsgruppe zuweisen oder für jede einzelne Sicherheitsgruppe.
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. Für Amazon ElastiCache Serverless müssen Sie sowohl Port 6379 als auch Port 6380 zulassen. Port 6379 ist der primäre Endpunkt für Lese- und Schreibvorgänge, und Port 6380 ist der leseoptimierte Endpunkt. Viele Clientbibliotheken stellen eine Verbindung zu beiden Ports her, auch wenn Sie Read From Replica nicht aktiv verwenden. Daher müssen Sie beide Ports zugänglich machen. 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
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. Netzwerk-ACLs werden Subnetzen zugewiesen, nicht bestimmten Ressourcen. Es ist möglich, der Client-Ressource dieselbe ACL ElastiCache zuzuweisen, insbesondere wenn sie sich im selben Subnetz befinden.
Standardmäßig erlauben Netzwerk-ACLs alle Trafic. 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
Allow/Deny: Erlauben
Regeln für ausgehenden Datenverkehr:
Regelnummer: vorzugsweise niedriger als jede Ablehnungsregel;
Type (Typ): Custom TCP Rule (TCP-Regel anpassen);
Protokoll: TCP
Portbereich: 6379 (oder 6379—6380 für Amazon Serverless) ElastiCache
Quelle: 0.0.0. 0/0 (oder die ElastiCache Cluster-Subnetze. Beachten Sie, dass die Verwendung bestimmter IP-Adressen im Falle eines Failovers oder der Skalierung des Clusters zu Problemen führen kann.)
Allow/Deny: Erlauben
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 (oder 6379—6380 für Amazon Serverless) ElastiCache
Quelle: 0.0.0. 0/0 (oder erstellen Sie individuelle Regeln für die ElastiCache Cluster-Subnetze)
Allow/Deny: Erlauben
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 ElastiCache Cluster-Subnetze. Beachten Sie, dass die Verwendung bestimmter IP-Adressen im Falle eines Failovers oder der Skalierung des Clusters zu Problemen führen kann.)
Allow/Deny: Erlauben
Weitere Informationen finden Sie unter Netzwerk-ACLs.
Routing-Tabellen
Ähnlich wie Netzwerk-ACLs kann jedes Subnetz unterschiedliche Routentabellen haben. Wenn sich die Clients und der ElastiCache Cluster in unterschiedlichen Subnetzen befinden, stellen Sie sicher, dass ihre Routing-Tabellen es ihnen ermöglichen, sich gegenseitig zu erreichen.
Komplexere Umgebungen, die mehrere VPCs, dynamisches Routing oder Netzwerk-Firewalls umfassen, können schwierig zu beheben sein. 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 Sie den VPC-DNS-Dienst nicht verwenden) kennen die ElastiCache-provided 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 aus der ElastiCache Engine sind gängige Quellen oder Informationen 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 die Metriken und.
CPUUtilizationEngineCPUUtilizationEngineCPUUtilizationstellt die CPU-Auslastung für den Valkey- oder Redis OSS-Prozess sowieCPUUtilizationdie Auslastung aller vCPUs bereit. Knoten mit mehr als einer vCPU haben normalerweise unterschiedliche Werte fürCPUUtilizationundEngineCPUUtilization, die zweite ist allgemein höher. 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.SetTypeCmdsundGetTypeCmds: Diese Metriken, die mitEngineCPUUtilizationkorreliert sind, können helfen zu verstehen, ob die Last für Schreibanforderungen signifikant höher ist, gemessen durchSetTypeCmds, oder liest, gemessen durchGetTypeCmds. 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 Flaggen kann die Bibliothek automatisch die Cluster-Topologie und die Replikatknoten erkennen, die Lesevorgänge über den Befehl READONLYValkey oder Redis OSS aktivieren und die Leseanforderungen 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 von Befehlen
NewConnectionspro Minute weist darauf hin, 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 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 beste 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 Netzwerkfunktionen hochskaliert werden können.
Die CloudWatchmetrics
NetworkBytesInundNetworkBytesOutgeben die Datenmenge an, die den Knoten erreicht bzw. verlässt.ReplicationBytesist der Datenverkehr, der der Datenreplikation gewidmet ist.
Weitere Informationen finden Sie unter Network-related Grenzwerte.
Komplexe Befehle: Redis OSS-Befehle werden in einem einzigen Thread ausgeführt, was bedeutet, dass Anfragen sequentiell bearbeitet 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 die
KEYS-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 „Big O“ -Notation, 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ür
KEYSist 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 die
COUNT, 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 kleine
COUNT-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ählwerteSCANlangsamer in großen Datenbanken machen, können größere Werte die gleichen Probleme verursachen, die fürKEYSbeschrieben sind.Als Beispiel wird das Ausführen des
SCANBefehl 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ßerdem
KEYS, 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 kein anderes Skript ausgeführt werden darf, während ein Skript ausgeführt wird. Lua-Skripte bieten die Möglichkeit, mehrere Befehle, Entscheidungsalgorithmen, Datenanalyse und andere Befehle 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. An ElastiCache, die Ausführungszeit von Lua-Skripten ist 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: Die
DELakzeptiert 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 dazuDEList ein asynchroner BefehlUNLINK, der seit Redis OSS 4 verfügbar ist.UNLINKmuss wann immer möglich vorgezogenDELwerden. Ab Redis OSS 6x sorgt derlazyfree-lazy-user-delParameter ElastiCache dafür, dass sich derDELBefehl so verhält,UNLINKals 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,ZINTERoderZINTERSTORE.Befehle, die auf mehrere Datentypen einwirken: Redis OSS bietet auch Befehle, die unabhängig von ihrem Datentyp auf einen oder mehrere Schlüssel einwirken. ElastiCache für Redis bietet OSS die Metrik
KeyBasedCmdszur Überwachung solcher Befehle. Diese Metrik summiert die Ausführung der folgenden Befehle im ausgewählten Zeitraum:Komplexität von O (N):
KEYS
O(1)
EXISTSOBJECTPTTLRANDOMKEYTTLTYPEEXPIREEXPIREATMOVEPERSISTPEXPIREPEXPIREATUNLINK (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:
DELDUMPRENAMEwird 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.RENAMENXRESTORESORT
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 wie
KEYS, 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 im Zusammenhang mit DNS-Auflösung, Sicherheitsgruppen, Netzwerk-ACLs und Routen-Tabellen 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 ElastiCache VPC verfügbaren Knoten. Gehen Sie dazu wie folgt vor:
Gehe zu? https://console.aws.amazon.com/ec2/v2/home #NIC:
Filtern Sie die Schnittstellenliste nach Ihrem ElastiCache Clusternamen oder der IP-Adresse, die Sie bei den DNS-Validierungen zuvor erhalten haben.
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.
Fahren Sie mit dem nächsten Schritt fort.
Erstellen Sie einen Analysepfad unter https://console.aws.amazon.com/vpc/home? # ReachabilityAnalyzer
und wählen Sie die folgenden Optionen: Quelltyp: Wählen Sie eine Instance aus, wenn Ihr ElastiCache Client auf einer Amazon EC2-Instance läuft, oder Network Interface, wenn er einen anderen Service verwendet, wie AWS Fargate Amazon ECS mit awsvpc-Netzwerk usw.) AWS Lambda, 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 ElastiCache 11211 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 am ElastiCache Service-Port zu überprüfen: Nping Ist auf Amazon Linux im Paket enthalten nmap und kann die TCP-Konnektivität auf dem ElastiCache Port testen sowie die Netzwerk-Round-Trip-Zeit angeben, um die Verbindung herzustellen. 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 nping fehlschlagen und die VPC Reachability Analyzer-Tests bestanden wurden, bitten Sie Ihren Systemadministrator, mögliche Host-based Firewallregeln, asymmetrische Routing-Regeln oder andere mögliche Einschränkungen auf Betriebssystemebene zu überprüfen.
Prüfen Sie auf der ElastiCache Konsole, ob die Verschlüsselung bei der Übertragung in Ihren Cluster-Details aktiviert ist. ElastiCache 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 -connectexample.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 dies nicht und die TLS/SSL Verschlüsselung bei der Übertragung ElastiCache ist aktiviert;
Die Anwendung unterstützt TLS/SSL , verfügt aber nicht über die richtigen Konfigurationsflags oder vertrauenswürdigen Zertifizierungsstellen;
Network-related Grenzwerte
Maximale Anzahl von Verbindungen: Es gibt harte Grenzen für gleichzeitige Verbindungen. Jeder ElastiCache Knoten ermöglicht bis zu 65.000 gleichzeitige Verbindungen über alle Clients hinweg. Dieses Limit kann anhand der eingeschalteten
CurrConnectionsMetriken ü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 60999Im vorherigen Beispiel sind 28231 Verbindungen von derselben Quelle zu derselben Ziel-IP (ElastiCache Knoten) und demselben Port zulässig. Der folgende Befehl zeigt, wie viele Verbindungen für einen bestimmten ElastiCache Knoten (IP 1.2.3.4) existieren:
ss --numeric --tcp state connected "dst 1.2.3.4 and dport == 6379" | grep -vE '^State' | wc -lWenn 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 wurden in die Warteschlange gestellt oder gelöscht, 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 wurden in die Warteschlange gestellt oder verworfen, weil die maximale Anzahl von Verbindungen, die über alle dem Knoten zugewiesenen Sicherheitsgruppen verfolgt wurden, ü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. Amazon-EC2-Instances verfügen auch über Netzwerklimits, die über 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 Kennzahl zur CPU-Auslastung ist der Ausgangspunkt der Untersuchung, und ElastiCache nebenbei können die folgenden Elemente dabei helfen, mögliche Probleme einzugrenzen:
Redis OSS SlowLogs: In der ElastiCache Standardkonfiguration werden die letzten 128 Befehle beibehalten, deren Ausführung über 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-lenundslowlog-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"-> SourceDas obige Ereignis geschah am 26. Dezember um 19:26:07 UTC, dauerte 4,8 Sekunden (4,823 ms) und wurde durch die
KEYSBefehl 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 2020Mit 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 : 2020Viele 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,,;
evalevalshaGeoSpatialBasedCmdsLatency:
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:
dumpexistskeys,object,pttl,randomkey,ttl,type,del,expire,expireat,movepersist,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 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.;
Sicherung und Replikation: ElastiCache verwendet eine Sicherungs- und Replikationsmethode ohne Fork, wodurch Schreibvorgänge verzögert werden können, um Ausfällen vorzubeugen.
Dies kann zu Zeiten höherer CPU-Auslastung führen, zu längeren Reaktionszeiten und folglich zu Timeouts auf dem Client während der Ausführung führen. Überprüfen Sie immer, ob die Client-Fehler während des Backup-Fensters oder der
SaveInProgress-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 auf dem Client oder ElastiCache auf 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“ Timeout „-Wert 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 sendet, 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 Symbol
maxmemory-Limit erreicht wird, versucht die Engine, Elemente zu vertreiben, um die Pufferverwendung zu erfüllen. Bei extrem geringem Arbeitsspeicher entscheidet sich OSS ElastiCache für Redis möglicherweise dafür, Clients, die große Client-Ausgabepuffer verbrauchen, die Verbindung zu trennen, um Speicherplatz freizugeben und den Zustand des Clusters aufrechtzuerhalten.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: weiches limit für client-verbindungen. Die Verbindung wird beendet, wenn mehr als die für client-output-buffer-limit-normal-soft-seconds definierte Zeit in Sekunden über dem weichen Limit bleibt oder wenn sie das harte Limit erreicht;
client-output-buffer-limit-normal-soft-seconds: erlaubte Zeit für die Verbindungen, die den client-output-buffer-limit-normal-soft-limit überschreiten;
client-output-buffer-limit--normal-hard-limit: Eine Verbindung, die diesen Grenzwert trifft, wird sofort beendet.
Neben den regulären Client-Puffern steuern die folgenden Optionen den Puffer für Replikatknoten und Pub/Sub () -Clients: Publish/Subscribe
client-output-buffer-limit-slave-hard-limit
client-output-buffer-limit-replica-soft-seconds;
client-output-buffer-limit-slave-hard-limit
client-output-buffer-limit-slave-soft-limit
client-output-buffer-limit-pubsubsoft-seconds;
client-output-buffer-limit-slave-hard-limit
Client-side Fehlerbehebung für Amazon EC2-Instances
Die Auslastung und Reaktionsfähigkeit auf der Clientseite können sich auch auf die Anfragen an auswirken. ElastiCache EC2-Instance- und Betriebssystemlimits müssen sorgfältig überprüft werden, während zeitweilige Konnektivitäts- oder Timeout-Probleme behoben werden. Einige wichtige Punkte zu beachten:
CPU:
EC2-Instance CPU-Auslastung: Stellen Sie sicher, dass die CPU nicht gesättigt ist oder fast 100 Prozent beträgt. Historische Analysen können über 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;
Bei Verwendung vonBurstable EC2-Instances, stellen Sie sicher, dass ihr CPU-Guthaben nicht erschöpft wurde. Diese Informationen sind in der Metrik verfügbar.
CPUCreditBalanceCloudWatchKurze Zeiträume mit hoher CPU-Auslastung können zu Timeouts führen, ohne dass eine 100-prozentige Auslastung von aktiviert CloudWatch ist. Solche Fälle erfordern eine Echtzeitüberwachung mit Betriebssystem-Tools wie
top,psundmpstat.
Netzwerk
Überprüfen Sie, ob der Netzwerkdurchsatz gemäß den Instance-Funktionen unter akzeptablen Werten liegt. Weitere Informationen finden Sie unter Amazon-EC2-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 aufgrund eines zu hohen eingehenden oder ausgehenden Durchsatzes in die Warteschlange gestellt oder verworfen wurden;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 mehrere Operationen gleichzeitig ausführen, besser zuMGETnutzen.GET
Aufschlüsselung der Zeit, die zum Abschließen einer einzelnen Anfrage benötigt wird
On the network:
TcpdumpundWireshark(tshark auf der Kommandozeile) sind praktische Tools, um nachzuvollziehen, wie viel Zeit die Anfrage benötigt hat, um das Netzwerk zu durchqueren, den ElastiCache Motor zu treffen und eine Rückgabe 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 +PONGParallel 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 kernelAus 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 den gleichen RedisPINGOSS-Befehl verwenden, erhaltenstracewir:$ 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.
