Redis arbeitet Befehle einzeln nacheinander ab. Ein einziger langsamer Befehl blockiert deshalb alle nachfolgenden Anfragen.
Warum Im laufenden Betrieb Komplettsuche per KEYS oder komplettes Lesen bzw. Löschen von Ranglisten und Listen mit Millionen Elementen → Folge Bis dieser Befehl fertig ist, warten alle anderen Anfragen (einige Dutzend ms bis einige Sekunden) → Auf dem Bildschirm Funktionen mit Sessions, Ranglisten oder Cache stocken gleichzeitig, Login verzögert
KEYS durch SCAN ersetzen, große Keys aufteilen, zum Löschen UNLINK verwenden (Löschen im Hintergrund), Ablaufzeitpunkte verteilen, die in dieselbe Sekunde fallen.
Aufgaben Infrastrukturteam
Log langsamer Befehle (SLOWLOG) überwachen, gefährliche Befehle wie KEYS auf Produktionsservern sperren, große Keys regelmäßig prüfen, THP abschalten und Speicherreserve für fork vorhalten, RDB- und AOF-Persistenz auf dem Replikat ausführen.
Größenordnungen
Normale Befehle dauern unter 1 ms. Werden Millionen Elemente auf einmal verarbeitet, kann es mehrere hundert ms bis einige Sekunden dauern.
Im Graphen
Vereinzelte Spitzen ohne Muster · Redis-Antwortlatenz, Anzahl langsamer Befehle
Wo nachsehen
Mit SLOWLOG GET Befehle prüfen, die slowlog-log-slower-than überschritten haben, mit CONFIG SET latency-monitor-threshold den Latency Monitor (standardmäßig aus) einschalten und mit LATENCY LATEST und LATENCY DOCTOR die Latenz je Event wie fork oder expire-cycle prüfen. Mit latest_fork_usec aus INFO und redis-cli --bigkeys auch fork-Dauer und große Keys prüfen
Spricht dafür
Zum Zeitpunkt des Stillstands stehen in SLOWLOG KEYS oder Befehle, die große Keys komplett verarbeiten, oder LATENCY verzeichnet zur selben Zeit fork- oder expire-cycle-Events von mindestens einigen Dutzend ms
Spricht dagegen
SLOWLOG und LATENCY leer, nur auf Seite des Spielservers langsam: Netzwerk oder Wartezeiten im Spielserver (SLOWLOG misst nur die Ausführungszeit des Befehls, ohne die Kommunikation mit dem Client)
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Mehr dazu
Auch in dem Moment, in dem sich der Prozess per fork dupliziert, um eine Sicherungsdatei (RDB-Snapshot) zu erstellen oder das AOF neu zu schreiben, steht Redis still. Auf aktuellen Servern sind das etwa 10 ms pro GB Arbeitsspeicher, bei 30 GB also rund 300 ms. Mit aktivierten großen Pages (THP) wird nach dem fork bei jedem Schreibzugriff eine ganze große Page kopiert (Copy-on-Write), was Stillstand und Speicherverbrauch stark erhöht. Deshalb schaltet man THP meist ab und hält reichlich Speicherreserve vor. Auch wenn sehr viele Keys in derselben Sekunde ablaufen, steht Redis kurz still, weil es sie löschen muss.
Quellen
Diagnosing latency issuesRedis Ein einzelner Thread arbeitet Anfragen nacheinander ab, ein langsamer Befehl blockiert alle folgenden; KEYS durch SCAN ersetzen; fork auf physischen Servern und aktuellen VMs gemessen etwa 9–13 ms pro GB; THP lässt Latenz und Speicherverbrauch durch das Kopieren nach dem fork sprunghaft steigen; massenhaftes Ablaufen in derselben Sekunde führt zu Stillstand
KEYSRedis Im Produktivbetrieb nur mit äußerster Vorsicht verwenden, kann bei großen Datenbanken die Performance ruinieren (auf einem Einsteiger-Laptop 40 ms für 1 Million Keys)
UNLINKRedis Asynchrones Löschen: Der Key wird sofort entfernt, der Speicher in einem anderen Thread freigegeben
SLOWLOGRedis Log langsamer Befehle, die slowlog-log-slower-than überschreiten; die Ausführungszeit enthält keine I/O für die Kommunikation mit dem Client
Redis latency monitoringRedis latency-monitor-threshold Standard 0 (aus), LATENCY LATEST und LATENCY DOCTOR, Latenzaufzeichnung je Event wie fork oder expire-cycle
INFORedis latest_fork_usec: Dauer des letzten fork (Mikrosekunden)
Redis CLIRedis --bigkeys: durchsucht den Keyspace nach großen Keys