Beispielanalyse der Redis-Timeout-Fehlerbehebung

Während unserer Arbeit vor ein paar Tagen erhielten wir plötzlich eine Warnung, dass unser Redis abgestürzt sei, und viele Leute diskutierten über ein bestimmtes Redis-Verbindungs-Timeout. Zuerst dachte ich, es gäbe ein großes Problem, aber wer hätte gedacht, dass es sich nach einer Weile bessern würde. Zu diesem Zeitpunkt habe ich mich am Server angemeldet und die Überwachung überprüft. Werfen Sie zum ersten Mal einen Blick auf QPS:

Sie können sehen, dass der QPS nicht hoch ist, aber warum haben Sie die Daten eine Zeit lang nicht erhalten? Schauen Sie sich dann weiterhin die CPU-Auslastung von Redis an:

Sie können sehen, dass die CPU ausgelastet ist, was erklären kann, warum das Diagramm fehlerhaft ist. Da Redis Single-Threaded ist, kann es nach der Nutzung von 100 % der CPU keine anderen Befehle verarbeiten und Zabbix kann den Info-Befehl nicht ausführen qps. Wir wissen also bereits, dass das Problem durch die CPU-Sättigung verursacht wird. Was ist also der Grund? Überprüfen Sie dann weiterhin, ob während der Zeit hoher CPU-Auslastung langsame Protokolle vorliegen:

Dies scheint nicht die Ursache für eine hohe CPU-Auslastung zu sein, daher ist die Fehlerbehebung schwierig. In diesem Beispiel handelt es sich um einen Master-Knoten und einen Slave-Knoten. Dann werfen wir einen Blick auf die CPU-Auslastung der Slave-Bibliothek:

Heilige Scheiße, was ist los? Warum werden 74 % der CPU aus der Bibliothek nicht genutzt? Ist das nicht wissenschaftlich? Überprüfen Sie auf jeden Fall, ob langsame Protokolle aus der Slave-Bibliothek vorhanden sind:

Heilige Scheiße, was ist los? Niemand nutzt die Slave-Bibliothek. Überprüfen Sie, ob schreibgeschützt:

127.0.0.1:6103> CONFIG GET "slave-read-only"
1) "slave-read-only"
2) "yes"
127.0.0.1:6103> 

Es scheint schreibgeschützt zu sein, was mich verwirrt hat. Schließlich fiel mir plötzlich auf, dass die Hauptbibliothek einen großen Schlüssel hat, der zu diesem Zeitpunkt abgelaufen ist, und der langsame Betrieb des abgelaufenen Schlüssels in der Hauptbibliothek keine langsamen Protokolle aufzeichnet. Der Schlüsselablauf der Slave-Bibliothek wird gelöscht Die Hauptbibliothek initiiert einen DEL-Befehl. Zu diesem Zeitpunkt zeichnet die Slave-Bibliothek das langsame Protokoll auf. Aus dem obigen langsamen Protokoll können Sie ersehen, dass die maximale DEL-Operation 335 ms beträgt. Kein Wunder, dass es zu Zeitüberschreitungen bei der Anwendungsverbindung kommt.

Verwenden Sie den Befehl info commandstats erneut, um Folgendes anzuzeigen:

Das obige ist der detaillierte Inhalt vonBeispielanalyse der Redis-Timeout-Fehlerbehebung. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!