So lösen Sie häufige Latenzprobleme in Redis

Verwenden Sie komplexe Befehle

Wenn Sie feststellen, dass die Zugriffsverzögerung bei der Verwendung von Redis plötzlich zunimmt, wie können Sie den Fehler beheben?

Der erste Schritt besteht darin, das langsame Protokoll von Redis zu überprüfen. Über die Slow-Log-Befehlsstatistikfunktion von Redis können wir die folgenden Optionen festlegen, um zu sehen, welche Befehle eine große Verzögerung bei der Ausführung verursachen.

Legen Sie zunächst den Schwellenwert für die langsame Protokollierung von Redis fest. Die Einheit beträgt hier beispielsweise 5 Millisekunden und legen Sie fest, dass nur die letzten 1000 Datensätze für die langsame Protokollierung gespeichert werden :

# 命令执行超过5毫秒记录慢日志
CONFIG SET slowlog-log-slower-than 5000
# 只保留最近1000条慢日志
CONFIG SET slowlog-max-len 1000

Nachdem die Einstellung abgeschlossen ist, werden alle ausgeführten Befehle von Redis aufgezeichnet, wenn die Verzögerung größer als 5 Millisekunden ist. Wir führen SLOWLOG get 5 aus, um die letzten 5 langsamen Protokolle abzufragen:

127.0.0.1:6379> SLOWLOG get 5
1) 1) (integer) 32693       # 慢日志ID
   2) (integer) 1593763337  # 执行时间
   3) (integer) 5299        # 执行耗时(微妙)
   4) 1) "LRANGE"           # 具体执行的命令和参数
      2) "user_list_2000"
      3) "0"
      4) "-1"
2) 1) (integer) 32692
   2) (integer) 1593763337
   3) (integer) 5044
   4) 1) "GET"
      2) "book_price_1000"
...

Durch Anzeigen der langsamen Protokollaufzeichnungen, Wir können wissen, welche Befehle zu welchem ​​Zeitpunkt ausgeführt wurden. Befehle sind zeitaufwändig, wenn Ihr Unternehmen häufig Befehle mit einer Komplexität über O(N) verwendet, wie z. B. Sortieren, Sunion, Zunionstore, Schlüssel, Scannen oder die bei der Ausführung verarbeitete Datenmenge O(N)-Befehle sind relativ umfangreich, daher ist die Verarbeitung von Daten unter Redis in diesen Situationen sehr zeitaufwändig.

Wenn die CPU-Auslastung der Redis-Instanz hoch ist, Ihr Serviceanfragevolumen jedoch nicht groß ist, liegt dies wahrscheinlich an der Verwendung von Befehlen mit hoher Komplexität.

Die Lösung besteht darin, diese komplexen Befehle nicht zu verwenden und nicht zu viele Daten auf einmal abzurufen. Versuchen Sie, jedes Mal eine kleine Datenmenge zu verarbeiten, damit Redis sie rechtzeitig verarbeiten und zurückgeben kann.

Speichern von Bigkey

Wenn Sie das langsame Protokoll abfragen und feststellen, dass es nicht durch Befehle mit hoher Komplexität verursacht wird, z. B. SET- und DELETE-Vorgänge im langsamen Protokolldatensatz, müssen Sie sich fragen, ob Redis die Bigkey-Bedingung geschrieben hat .

Wenn Redis neue Daten schreibt, wird dafür Speicherplatz zugewiesen, und wenn Daten aus Redis gelöscht werden, wird auch der entsprechende Speicherplatz freigegeben.

Wenn die von einem Schlüssel geschriebenen Daten sehr groß sind, wird die Speicherzuweisung durch Redis auch zeitaufwändiger. Ebenso dauert es lange, bis der Speicher freigegeben wird, wenn die Daten dieses Schlüssels gelöscht werden.

Sie müssen Ihren Geschäftscode überprüfen, um zu sehen, ob Bigkey geschrieben wird. Sie müssen die Menge der geschriebenen Daten auswerten. Die Geschäftsschicht sollte vermeiden, zu viele Daten in einem Schlüssel zu speichern.

Als Reaktion auf das Bigkey-Problem hat Redis in Version 4.0 offiziell den Lazy-Free-Mechanismus eingeführt, der verwendet wird, um den Speicher von Bigkey asynchron freizugeben und die Auswirkungen auf die Leistung von Redis zu verringern. Dennoch empfehlen wir nicht, dass Bigkey die Leistung der Migration während des Cluster-Migrationsprozesses beeinträchtigt. Dies wird später in den Cluster-bezogenen Artikeln ausführlich beschrieben.

Konzentrierter Ablauf

Manchmal werden Sie feststellen, dass es bei der Verwendung von Redis keine große Verzögerung gibt, sondern zu einem bestimmten Zeitpunkt plötzlich eine Verzögerungswelle auftritt und die langsamen Zeitpunkte sehr regelmäßig sind, z. B. zu einem bestimmten Zeitpunkt. Es wird passieren zur vollen Stunde oder in regelmäßigen Abständen.

In diesem Fall müssen Sie überlegen, ob eine große Anzahl von Schlüsseln zusammen abgelaufen ist.

Wenn eine große Anzahl von Schlüsseln zu einem festen Zeitpunkt abläuft und zu diesem Zeitpunkt auf Redis zugegriffen wird, kann sich die Verzögerung erhöhen.

Die Ablaufstrategie von Redis verwendet zwei Strategien: regelmäßiges Löschen + verzögertes Löschen.

Beachten Sie, dass die geplanten Aufgaben zum regelmäßigen Löschen von Redis auch im Redis-Hauptthread ausgeführt werden. Dies bedeutet, dass bei Bedarf ein Fehler während der Ausführung des aktiven Ablaufs auftritt Um eine große Anzahl abgelaufener Schlüssel zu löschen, müssen Sie während des Geschäftszugriffs auf den Abschluss der abgelaufenen Aufgabe warten, bevor Sie die Geschäftsanforderung verarbeiten. Zu diesem Zeitpunkt tritt das Problem einer erhöhten Geschäftszugriffsverzögerung auf, und die maximale Verzögerung beträgt 25 Millisekunden.

Und diese Zugriffsverzögerung wird nicht im langsamen Protokoll aufgezeichnet. Das langsame Protokoll zeichnet nur die tatsächliche Ausführungszeit eines bestimmten Befehls auf, bevor der Betriebsbefehl ausgeführt wird. Wenn der Betriebsbefehl den Schwellenwert für das langsame Protokoll nicht erreicht, wird er nicht in der Statistik des langsamen Protokolls berechnet Das Geschäft kam mit zunehmenden Verzögerungen zurecht.

Die Lösung besteht darin, dem zentralen Ablauf eine zufällige Zeit hinzuzufügen und die Zeiten dieser Schlüssel, die ablaufen müssen, zu verteilen.

Der Instanzspeicher erreicht die Obergrenze

Wenn wir Redis manchmal als reinen Cache verwenden, legen wir eine Speicherobergrenze maxmemory für die Instanz fest und aktivieren dann die LRU-Eliminierungsstrategie.

Wenn der Speicher der Instanz den maximalen Speicher erreicht, werden Sie feststellen, dass das Schreiben neuer Daten jedes Mal langsamer werden kann.

Der Grund für die Verlangsamung liegt darin, dass, wenn der Redis-Speicher den maximalen Speicher erreicht, bevor alle neuen Daten geschrieben werden, ein Teil der Daten entfernt werden muss, um den Speicher unter dem maximalen Speicher zu halten.

Diese Logik des Herauswerfens alter Daten benötigt ebenfalls Zeit, und die spezifische Zeitdauer hängt von der konfigurierten Eliminierungsstrategie ab.

Fork ist sehr zeitaufwändig.

Wenn Ihr Redis über die Funktion zur automatischen RDB-Generierung und AOF-Umschreibung verfügt, dann Dies kann dazu führen, dass sich die Zugriffsverzögerung von Redis erhöht, wenn im Hintergrund RDB- und AOF-Umschreibungen generiert werden, und die Verzögerung verschwindet, nachdem diese Aufgaben abgeschlossen sind.

Wenn diese Situation auftritt, wird sie normalerweise durch die Ausführung der Aufgabe zum Generieren von RDB- und AOF-Umschreibungen verursacht.

Das Generieren von RDB und AOF erfordert, dass der übergeordnete Prozess einen untergeordneten Prozess für die Datenpersistenz ausgibt. Während des Fork-Ausführungsprozesses muss der übergeordnete Prozess die Speicherseitentabelle in den untergeordneten Prozess kopieren Speicher, dann muss die Seitentabelle zeitaufwändig sein, bevor die Verzweigung abgeschlossen ist und keine Anfragen verarbeitet werden können Zu diesem Zeitpunkt sind die CPU-Ressourcen knapp, der Fork wird länger dauern oder sogar Sekunden erreichen. Dies wird die Leistung von Redis ernsthaft beeinträchtigen.

Binden der CPU

Wenn wir Dienste bereitstellen, verwenden wir häufig den Prozess zum Binden der CPU, um die Leistung zu verbessern und den Leistungsverlust beim Kontextwechsel zu verringern, wenn das Programm mehrere CPUs verwendet.

Bei der Verwendung von Redis raten wir jedoch aus folgenden Gründen davon ab.

CPU-gebundenes Redis: Bei der Durchführung der Datenpersistenz erbt der untergeordnete Prozess die CPU-Auslastungspräferenz des übergeordneten Prozesses. Zu diesem Zeitpunkt verbraucht der untergeordnete Prozess eine große Menge an CPU-Ressourcen für die Datenpersistenz Es kommt zu einem CPU-Konflikt mit dem Hauptprozess, was ebenfalls zu unzureichenden CPU-Ressourcen des Hauptprozesses und einer erhöhten Zugriffsverzögerung führt.

Wenn Sie also bei der Bereitstellung des Redis-Prozesses den RDB- und AOF-Umschreibmechanismus aktivieren müssen, dürfen Sie keine CPU-Bindungsvorgänge ausführen.

Verwenden Sie Swap.

Wenn Sie feststellen, dass Redis plötzlich sehr langsam wird, dauert jeder Zugriff bis zu Hunderte Überprüfen Sie dann, ob Redis Swap verwendet. In diesem Fall ist Redis grundsätzlich nicht in der Lage, leistungsstarke Dienste bereitzustellen.

Wir wissen, dass das Betriebssystem einen Swap-Mechanismus bereitstellt. Der Zweck besteht darin, einen Teil der Daten im Speicher auf die Festplatte auszulagern, wenn der Speicher nicht ausreicht, um die Speichernutzung zu puffern.

Aber nachdem die Daten im Speicher auf die Festplatte übertragen wurden, ist für den Zugriff auf die Daten das Lesen von der Festplatte erforderlich, was viel langsamer ist als der Speicher!

Besonders bei einer leistungsstarken In-Memory-Datenbank wie Redis ist diese Betriebszeit für eine extrem leistungsempfindliche Datenbank wie Redis nicht akzeptabel, wenn der Speicher in Redis auf die Festplatte ausgelagert wird. Sie können den Betriebssystem-Swap vorübergehend schließen. Zu diesem Zeitpunkt müssen Sie überprüfen, ob der Netzwerkkartenverkehr des Computers erschöpft ist.

Eine hohe Netzwerklast kann zu Problemen wie Verzögerungen beim Datenversand und Datenverlust auf Netzwerkebene und TCP-Ebene führen. Neben dem Speicher ist Redis auch aufgrund seiner hervorragenden Netzwerk-IO-Leistung leistungsstark. Da jedoch die Anzahl der Anfragen weiter zunimmt, erhöht sich auch die Belastung der Netzwerkkarte entsprechend.

Wenn dies geschieht, müssen Sie überprüfen, welche Redis-Instanz auf diesem Computer übermäßigen Datenverkehr hat und die Netzwerkbandbreite ausfüllt, und dann bestätigen, ob der plötzliche Anstieg des Datenverkehrs eine normale Geschäftssituation ist. Wenn dies der Fall ist, müssen Sie erweitern oder migrieren Sie die Instanz rechtzeitig.

Das obige ist der detaillierte Inhalt vonSo lösen Sie häufige Latenzprobleme in Redis. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!