Redis-Leistungsüberwachung

Einführung

In diesem Lab lernen Sie, wie Sie Redis-Performanceprobleme überwachen und beheben. Der Schwerpunkt liegt auf der Identifizierung und Behebung von Latenzproblemen, der Analyse der Speichernutzung und der Optimierung der Abfrageleistung.

Sie verwenden den Befehl LATENCY DOCTOR zur Diagnose von Latenz, MEMORY STATS zur Überprüfung der Speichernutzung, SLOWLOG GET zur Analyse langsamer Abfragen und MEMORY PURGE zur Optimierung des Speichers. Durch Befolgen der Schritt-für-Schritt-Anleitung sammeln Sie praktische Erfahrungen bei der Wartung eines reaktionsschnellen und effizienten Redis-Deployments.

Vorkonfigurierte Umgebung

Um zuverlässige Demonstrationen zu gewährleisten, wurde diese Laborumgebung mit Folgendem vorkonfiguriert:

• 1000 String-Schlüssel (user:1 bis user:1000) mit Benutzerdaten
• 50 Hash-Objekte (profile:1 bis profile:50) mit Benutzerprofilinformationen
• 20 Listen-Objekte (logs:app1 bis logs:app20) mit Log-Einträgen
• 10 Set-Objekte (tags:1 bis tags:10) mit Tag-Daten
• Optimierte Redis-Konfiguration für die Performance-Überwachung
• Vorab generierte Latenz- und Slowlog-Daten für die sofortige Analyse

Latenz mit LATENCY DOCTOR überwachen

In diesem Schritt erfahren Sie, wie Sie den Befehl LATENCY DOCTOR in Redis verwenden, um Latenzprobleme zu diagnostizieren und zu beheben. Das Verständnis und die Behebung von Latenz sind entscheidend für die Aufrechterhaltung eines reaktionsschnellen und effizienten Redis-Deployments.

Was ist Latenz?

Latenz bezeichnet die Verzögerung zwischen dem Senden einer Anfrage an einen Redis-Server und dem Empfang einer Antwort. Hohe Latenz kann die Anwendungsleistung negativ beeinflussen und zu langsamen Antwortzeiten und einer schlechten Benutzererfahrung führen.

Einführung in LATENCY DOCTOR

Der Befehl LATENCY DOCTOR ist ein leistungsstarkes, in Redis integriertes Werkzeug, das hilft, potenzielle Latenzquellen zu identifizieren. Er analysiert verschiedene Aspekte des Redis-Betriebs und liefert Einblicke, was Verzögerungen verursachen könnte.

Schritt-für-Schritt-Anleitung

1. Verbindung zu Redis herstellen:

   Stellen Sie zunächst mit dem Befehl redis-cli eine Verbindung zu Ihrem Redis-Server her. Öffnen Sie ein Terminal in Ihrer LabEx VM und führen Sie Folgendes aus:

   redis-cli
   

   Dadurch wird die Redis-Befehlszeilenschnittstelle geöffnet.

2. Aktuelle Konfiguration prüfen:

   Die Umgebung wurde mit aktiviertem Latenz-Monitoring vorkonfiguriert. Sie können die aktuellen Einstellungen überprüfen:

   CONFIG GET latency-monitor-threshold
   

   Dies sollte anzeigen, dass der Schwellenwert auf 10 Millisekunden eingestellt ist.

3. LATENCY DOCTOR ausführen:

   Führen Sie nun den Befehl LATENCY DOCTOR aus, um das System zu analysieren:

   LATENCY DOCTOR
   

   Da es sich hierbei um eine fehlerfreie Redis-Instanz ohne signifikante Latenzprobleme handelt, sehen Sie wahrscheinlich eine Ausgabe ähnlich der folgenden:

   Dave, no latency spike was observed during the lifetime of this Redis instance, not in the slightest bit. I honestly think you ought to sit down calmly, take a stress pill, and think things over.
   

   Diese humorvolle Nachricht (eine Anspielung auf HAL 9000 aus "2001: Odyssee im Weltraum") zeigt an, dass Redis ohne Latenzspitzen über dem konfigurierten Schwellenwert gut funktioniert.

4. Die Antwort von LATENCY DOCTOR verstehen:

   Wenn LATENCY DOCTOR die "Dave"-Nachricht anzeigt, bedeutet dies:

   • Keine Befehle haben den Schwellenwert für die Latenzüberwachung (in unserem Fall 10 ms) überschritten.
   • Redis arbeitet effizient ohne Leistungshindernisse.
   • Das System ist aus Latenzsicht gesund.

   In Produktionsumgebungen mit tatsächlichen Latenzproblemen würden Sie eine detaillierte Analyse sehen, einschließlich:

   • Spezifische Latenzspitzen und deren Ursachen.
   • Empfehlungen zur Optimierung.
   • Detaillierte Aufschlüsselungen langsamer Operationen.

5. Slowlog untersuchen (alternative Analyse):

   Auch wenn LATENCY DOCTOR keine Probleme anzeigt, können wir den Slowlog trotzdem untersuchen, um zu sehen, welche Operationen im Verhältnis zu anderen die meiste Zeit in Anspruch nehmen:

   SLOWLOG GET 10
   

   Sie sehen eine Ausgabe mit den letzten Befehlen und deren Ausführungszeiten. Die Einträge zeigen:

   • Eindeutige ID: Sequenzieller Identifikator für jeden Eintrag.
   • Zeitstempel: Unix-Zeitstempel, wann der Befehl ausgeführt wurde.
   • Ausführungszeit: Zeit in Mikrosekunden (z. B. 1954 Mikrosekunden = 1,954 Millisekunden).
   • Befehl: Der ausgeführte Befehl (zeigt oft "COMMAND" für interne Redis-Operationen an).
   • Client-Informationen: IP-Adresse und Port des Clients.

   Zum Beispiel:

   1) 1) (integer) 10
      2) (integer) 1753255495
      3) (integer) 1954
      4) 1) "COMMAND"
      5) "127.0.0.1:42212"
      6) ""
   

   Dies zeigt einen Befehl, dessen Ausführung 1.954 Mikrosekunden (etwa 2 Millisekunden) dauerte.

6. redis-cli beenden:

   Um sicherzustellen, dass die Befehle protokolliert werden, beenden Sie redis-cli, indem Sie Folgendes eingeben:

   exit
   

Die Bedeutung verstehen

Durch die Verwendung von LATENCY DOCTOR und die Analyse des Slowlogs können Sie wertvolle Einblicke in die Leistung Ihres Redis-Deployments gewinnen. Selbst wenn alles in Ordnung zu sein scheint (wie durch die "Dave"-Nachricht angezeigt), hilft die regelmäßige Überwachung, eine weiterhin gute Leistung sicherzustellen und aufkommende Probleme frühzeitig zu erkennen.

Speicher mit MEMORY STATS prüfen

In diesem Schritt lernen Sie, wie Sie den Befehl MEMORY STATS in Redis verwenden, um die Speichernutzung zu überwachen und zu verstehen. Eine effiziente Speicherverwaltung ist entscheidend für die Stabilität und Leistung Ihres Redis-Servers.

Warum Speicher überwachen?

Redis ist ein In-Memory-Datenspeicher, was bedeutet, dass es alle seine Daten im RAM speichert. Wenn Redis keinen Speicher mehr hat, kann dies zu Leistungseinbußen, Datenverlust oder sogar Abstürzen führen. Die Überwachung der Speichernutzung ermöglicht es Ihnen, potenzielle speicherbezogene Probleme proaktiv zu identifizieren und zu beheben.

Einführung in MEMORY STATS

Der Befehl MEMORY STATS bietet einen detaillierten Überblick über den Speicherverbrauch von Redis. Er unterteilt die Speichernutzung in verschiedene Kategorien und gibt Ihnen Einblicke, wo Ihr Speicher verwendet wird.

Schritt-für-Schritt-Anleitung

1. Verbindung zu Redis herstellen:

   Stellen Sie mit dem Befehl redis-cli eine Verbindung zu Ihrem Redis-Server her. Öffnen Sie ein Terminal in Ihrer LabEx VM und führen Sie Folgendes aus:

   redis-cli
   

   Dadurch wird die Redis-Befehlszeilenschnittstelle geöffnet.

2. MEMORY STATS ausführen:

   Führen Sie nach der Verbindung den Befehl MEMORY STATS aus:

   MEMORY STATS
   

   Redis sammelt dann Speicherstatistiken und zeigt die Ergebnisse an.

3. Ausgabe interpretieren:

   Die Ausgabe von MEMORY STATS ist ein Dictionary von Schlüssel-Wert-Paaren, wobei jeder Schlüssel eine Speicherstatistik und der Wert seinen entsprechenden Wert darstellt. Betrachten wir eine Beispielausgabe und erklären einige der wichtigsten Metriken:

   127.0.0.1:6379> MEMORY STATS
    1) "peak.allocated"
    2) (integer) 1114480
    3) "total.allocated"
    4) (integer) 1114480
    5) "startup.allocated"
    6) (integer) 948480
    7) "replication.buffer"
    8) (integer) 0
    9) "clients.slaves"
   10) (integer) 0
   11) "clients.normal"
   12) (integer) 6456
   13) "aof.buffer"
   14) (integer) 0
   15) "lua.vm"
   16) (integer) 0
   17) "overhead.total"
   18) (integer) 165992
   19) "keys.count"
   20) (integer) 0
   21) "keys.bytes-per-key"
   22) (integer) 0
   23) "dataset.bytes"
   24) (integer) 948488
   25) "dataset.percentage"
   26) "0.00%"
   27) "bytes-per-replica.avg"
   28) (integer) 0
   29) "bytes-per-replica.min"
   30) (integer) 0
   31) "bytes-per-replica.max"
   32) (integer) 0
   33) "allocator.fragratio"
   34) "1.00"
   35) "allocator.fragbytes"
   36) (integer) 0
   37) "allocator.rss"
   38) (integer) 835584
   39) "allocator.peak"
   40) (integer) 1114112
   41) "total.system"
   42) (integer) 4194304
   43) "allocator.resident"
   44) (integer) 835584
   

   Hier ist eine Aufschlüsselung einiger wichtiger Metriken:

   • peak.allocated: Die höchste Speichermenge, die Redis seit dem Start zugewiesen hat.
   • total.allocated: Die insgesamt von Redis aktuell zugewiesene Speichermenge.
   • dataset.bytes: Die Gesamtgröße der in Redis gespeicherten Daten (ohne Overhead).
   • overhead.total: Die Gesamtmenge des Speichers, der für Redis-Overhead verwendet wird (z. B. Datenstrukturen, Metadaten).
   • keys.count: Die Anzahl der aktuell in Redis gespeicherten Schlüssel.
   • allocator.fragratio: Das Fragmentierungsverhältnis des Speicherallokators. Ein höherer Wert deutet auf mehr Fragmentierung hin.
   • allocator.rss: Die Speichermenge, die Redis laut Betriebssystem verwendet (Resident Set Size).
   • total.system: Die auf dem System verfügbare Gesamtspeichermenge.

4. redis-cli beenden:

   Um sicherzustellen, dass die Befehle protokolliert werden, beenden Sie redis-cli, indem Sie Folgendes eingeben:

   exit
   

Verwendung der Informationen

Die von MEMORY STATS bereitgestellten Informationen können verwendet werden, um:

• Speicherlecks zu identifizieren.
• Datenstrukturen zu optimieren, um die Speichernutzung zu reduzieren.
• Redis-Konfigurationsparameter anzupassen, um die Speichereffizienz zu verbessern.
• Festzustellen, ob Sie den für Ihren Redis-Server verfügbaren RAM erhöhen müssen.

Langsame Abfragen mit SLOWLOG GET analysieren

In diesem Schritt werden wir die Analyse langsamer Abfragen mit dem Befehl SLOWLOG GET in Redis untersuchen. Das Identifizieren und Optimieren langsamer Abfragen ist unerlässlich, um ein reaktionsschnelles und effizientes Redis-Deployment aufrechtzuerhalten. Wie bereits in der ersten Lektion von LATENCY DOCTOR vorgeschlagen, ist die Analyse des Slowlogs ein entscheidender Schritt zur Behebung von Latenzproblemen.

Was ist das Slowlog?

Das Slowlog ist ein System in Redis, das Abfragen protokolliert, die eine festgelegte Ausführungszeit überschreiten. Dies ermöglicht es Ihnen, Abfragen zu identifizieren, die länger als erwartet dauern und möglicherweise die Leistung beeinträchtigen.

Schritt-für-Schritt-Anleitung

1. Verbindung zu Redis herstellen:

   Stellen Sie mit dem Befehl redis-cli eine Verbindung zu Ihrem Redis-Server her. Öffnen Sie ein Terminal in Ihrer LabEx VM und führen Sie Folgendes aus:

   redis-cli
   

   Dadurch wird die Redis-Befehlszeilenschnittstelle geöffnet.

2. Slowlog-Konfiguration prüfen:

   Die Umgebung wurde mit geeigneten Slowlog-Einstellungen vorkonfiguriert. Sie können die aktuelle Konfiguration überprüfen:

   CONFIG GET slowlog-log-slower-than
   

   CONFIG GET slowlog-max-len
   

   Diese sollten zeigen, dass Redis so konfiguriert ist, dass Befehle protokolliert werden, die länger als 1000 Mikrosekunden (1 Millisekunde) dauern, und bis zu 128 Slowlog-Einträge gespeichert werden.

3. Slowlog-Einträge abrufen:

   Verwenden Sie den Befehl SLOWLOG GET, um Slowlog-Einträge abzurufen. Um die 10 neuesten Slowlog-Einträge abzurufen, verwenden Sie den folgenden Befehl:

   SLOWLOG GET 10
   

   Sie sehen eine Ausgabe, die dieser ähnelt (zeigt aktuelle Redis-interne Operationen):

    1) 1) (integer) 10
       2) (integer) 1753255495
       3) (integer) 1954
       4) 1) "COMMAND"
       5) "127.0.0.1:42212"
       6) ""
    2) 1) (integer) 9
       2) (integer) 1753255494
       3) (integer) 4795
       4) 1) "COMMAND"
       5) "127.0.0.1:41444"
       6) ""
    3) 1) (integer) 8
       2) (integer) 1753255494
       3) (integer) 1599
       4) 1) "COMMAND"
       5) "127.0.0.1:41004"
       6) ""
   

4. Ausgabe interpretieren:

   Die Ausgabe von SLOWLOG GET ist ein Array von Slowlog-Einträgen. Jeder Eintrag enthält sechs Informationen:

   1. Eindeutige ID: Ein sequenzieller Identifikator für den Slowlog-Eintrag (z. B. 10, 9, 8...)
   2. Zeitstempel: Der Unix-Zeitstempel, wann die Abfrage ausgeführt wurde.
   3. Ausführungszeit: Die Ausführungszeit in Mikrosekunden (z. B. 1954 = 1,954 Millisekunden).
   4. Befehlsarray: Der ausgeführte Befehl (zeigt oft "COMMAND" für interne Redis-Operationen an).
   5. Client-IP und Port: Die IP-Adresse und der Port des Clients (z. B. "127.0.0.1:42212").
   6. Client-Name: Der Name des Clients (normalerweise leer, angezeigt als "").

   Verständnis der Zeiten:

   • 1954 Mikrosekunden = 1,954 Millisekunden
   • 4795 Mikrosekunden = 4,795 Millisekunden
   • 1599 Mikrosekunden = 1,599 Millisekunden

5. Häufige Muster analysieren:

   In der Umgebung sehen Sie typischerweise:

   • "COMMAND"-Einträge: Diese repräsentieren interne Redis-Operationen wie Befehlsanalyse und -verarbeitung.
   • Mikrosekunden-Timing: Die meisten Operationen sind sehr schnell (1-5 Millisekunden).
   • Lokale Verbindungen: Alle Verbindungen von 127.0.0.1 (localhost).

6. Detailliertere langsame Abfragen generieren:

   Um spezifischere langsame Abfragen mit den vorhandenen Daten zu sehen, führen wir Operationen aus, die durch den Datensatz scannen:

   KEYS user:*
   

   Dieser Befehl scannt alle Benutzer-Schlüssel (1000 Schlüssel), die im Slowlog erscheinen sollten.

   Überprüfen Sie nun das aktualisierte Slowlog:

   SLOWLOG GET 3
   

   Sie sollten nun den Befehl KEYS user:* im Slowlog mit einem Format wie diesem sehen:

   1) 1) (integer) 11
      2) (integer) [timestamp]
      3) (integer) [execution_time]
      4) 1) "KEYS"
         2) "user:*"
      5) "127.0.0.1:[port]"
      6) ""
   

7. Speicheroptimierung mit MEMORY PURGE:

   Lassen Sie uns auch die Speicheroptimierung demonstrieren. Überprüfen Sie zuerst die aktuelle Speichernutzung:

   MEMORY STATS
   

   Suchen Sie in der Ausgabe nach dem Wert total.allocated. Lassen Sie uns nun Speicher freigeben, indem wir ungenutzten Speicher bereinigen:

   MEMORY PURGE
   

   Überprüfen Sie die Speichernutzung erneut:

   MEMORY STATS
   

   Vergleichen Sie die Werte von total.allocated, um zu sehen, ob Speicher freigegeben wurde. Der Befehl MEMORY PURGE versucht, Speicher freizugeben, der von Redis nicht aktiv genutzt wird.

8. redis-cli beenden:

   Um sicherzustellen, dass die Befehle protokolliert werden, beenden Sie redis-cli, indem Sie Folgendes eingeben:

   exit
   

Verwendung der Informationen

Durch die Analyse des Slowlogs können Sie langsame Abfragen identifizieren und Schritte zu deren Optimierung unternehmen. Wichtige Erkenntnisse sind:

• Befehlshäufigkeit: Wie oft langsame Befehle auftreten.
• Ausführungsmuster: Ob bestimmte Operationen konsistent im Slowlog erscheinen.
• Leistungstrends: Änderungen der Ausführungszeiten im Laufe der Zeit.
• Ressourcennutzung: Befehle, die möglicherweise übermäßige CPU- oder Speichernutzung verursachen.

Diese Informationen helfen Ihnen dabei:

• Anwendungsabfragen zu optimieren.
• Problematische Muster zu identifizieren.
• Skalierung und Kapazität zu planen.
• Leistungsprobleme in der Produktion zu beheben.

Zusammenfassung

In diesem Lab haben wir Techniken zur Leistungsüberwachung von Redis mit einer vorkonfigurierten Umgebung untersucht, die reale Leistungsüberwachungstools von Redis demonstriert.

Wir begannen mit dem Befehl LATENCY DOCTOR, um zu verstehen, wie Redis Latenzprobleme diagnostiziert. In unserer gesunden Umgebung sahen wir die charakteristische "Dave"-Nachricht, die anzeigte, dass keine Latenzspitzen erkannt wurden. Dies lehrte uns, wie man das Latenzüberwachungsfeedback von Redis interpretiert, wenn Systeme gut funktionieren.

Als Nächstes untersuchten wir den Befehl MEMORY STATS, um Muster der Redis-Speichernutzung zu analysieren. Mit dem vorkonfigurierten Datensatz von 1000 String-Schlüsseln, 50 Hash-Objekten, 20 Listen und 10 Sets beobachteten wir eine realistische Speicherzuweisung und lernten, wichtige Speicher-Metriken wie total.allocated, dataset.bytes und overhead.total zu identifizieren.

Anschließend erkundeten wir den Befehl SLOWLOG GET, um die Abfrageleistung zu analysieren. Wir lernten, die sechsteiligen Slowlog-Einträge zu lesen und die Ausführungszeiten in Mikrosekunden zu verstehen, und beobachteten, wie interne Redis-"COMMAND"-Operationen im Slowlog erscheinen. Wir demonstrierten auch die Generierung benutzerdefinierter langsamer Abfragen mithilfe von Mustervergleichsbefehlen wie KEYS user:*.

Schließlich demonstrierten wir die Speicheroptimierung mit dem Befehl MEMORY PURGE und verglichen die Speichernutzung vor und nach dem Purging, um zu verstehen, wie Redis den Speicher effizient verwaltet.

Während des Labs haben wir gelernt, wie man:

1. Die Ausgabe von LATENCY DOCTOR interpretiert, einschließlich der Nachricht "healthy system".
2. Muster der Speichernutzung mit MEMORY STATS anhand realer Datensatz-Metriken analysiert.
3. Slowlog-Einträge mit ihrer sechsteiligen Struktur liest und versteht.
4. Langsame Abfragen mithilfe von Mustervergleichsoperationen generiert und analysiert.
5. Die Speichernutzung mit MEMORY PURGE optimiert.
6. Zwischen internen Redis-Operationen und Benutzerbefehlen bei der Leistungsüberwachung unterscheidet.

Diese praktische Erfahrung mit den integrierten Leistungsüberwachungstools von Redis bildet die Grundlage für die Aufrechterhaltung reaktionsschneller und effizienter Redis-Deployments in Produktionsumgebungen.