Vier wesentliche Strategien zur Behebung von Redis-Speicherlecks und -Spitzen

Redis ist ein In-Memory-Datenspeicher, daher treten Speicherprobleme schnell auf. Ein kleiner Fehler bei der TTL-Verwaltung, eine übermäßig große Liste oder ein Hintergrundspeichervorgang auf einem Host ohne freien Arbeitsspeicher können zu Latenz, Schreibfehlern, Räumungen, Auslagerungen oder einem vom Betriebssystem beendeten Redis-Prozess führen.

Die erste nützliche Gewohnheit ist, nicht jeden Speicheranstieg als Leck zu bezeichnen. Echte Redis-Lecks sind selten. Die meisten Vorfälle fallen in eine von drei Kategorien: echtes Datenwachstum, Allokator-Fragmentierung oder temporärer Copy-on-Write-Overhead während der Persistenz. Auf einem Dashboard sehen sie ähnlich aus, aber die Lösungen sind völlig unterschiedlich.

Wenn used_memory stetig steigt, speichert Ihre Anwendung wahrscheinlich mehr Daten als erwartet. Wenn used_memory stabil ist, aber used_memory_rss springt, untersuchen Sie Fragmentierung, gegabelte Hintergrundarbeit oder das Betriebssystem. Wenn beide während eines Verkehrsanstiegs steigen und dann nie wieder fallen, überprüfen Sie TTLs, die Räumungsrichtlinie und große Schlüssel.

Strategie 1: Detaillierte Überwachung von Nutzungs- und Fragmentierungsmetriken

Der erste Schritt zur Diagnose eines Speicherproblems ist die Festlegung einer Basislinie und das Verständnis, wie Redis die Speichernutzung meldet. Der Standardbefehl INFO memory liefert wesentliche Metriken, die zwischen dem von Daten genutzten Speicher und dem vom Betriebssystem genutzten Speicher unterscheiden.

Wichtige Metriken zur Diagnose

Wenn ein Anstieg auftritt, sehen Sie sich sofort diese Metriken von INFO memory an:

1. used_memory: Speicher, den Redis für Daten und interne Strukturen zugewiesen hat.
2. used_memory_dataset: Speicher, der vom tatsächlichen Datensatz verwendet wird, ohne einen Teil des Overheads.
3. used_memory_rss: Residenter Speicher, den das Betriebssystem dem Redis-Prozess zugewiesen hat.
4. mem_fragmentation_ratio: Ein grober Vergleich von RSS zu zugewiesenem Speicher. Behandeln Sie es als Hinweis, nicht als endgültiges Urteil.

# Grundlegende Speicherstatistiken abrufen
redis-cli INFO memory

# Beispielausgabe (Auszug)
# used_memory:1073741824 			# 1 GB Daten
# used_memory_rss:1509949440 		# ~1,5 GB im RAM
# mem_fragmentation_ratio:1.40625 	# RSS ist etwa 40% höher als used_memory

Interpretation des Fragmentierungsverhältnisses

Ein Verhältnis nahe 1.0 ist in der Regel gesund. Ein Verhältnis über 1.5 ist untersuchungswürdig, insbesondere wenn RSS hoch genug ist, um den Host zu gefährden. Ein Verhältnis unter 1.0 beweist nicht automatisch Auslagerung; es kann aufgrund von Messrandfällen, Shared-Memory-Abrechnung oder sehr kleinen Datensätzen auftreten. Überprüfen Sie die OS-Auslagerungsmetriken direkt mit vmstat, top, sar oder Ihrem Überwachungssystem.

Wenn used_memory flach ist, aber RSS während BGSAVE oder BGREWRITEAOF ansteigt, ist Copy-on-Write eine wahrscheinliche Ursache. Der Kindprozess schreibt eine Persistenzdatei, während der Elternprozess weiterhin Schreibvorgänge bearbeitet. Seiten, die vom Elternprozess geändert wurden, müssen möglicherweise kopiert werden, was vorübergehend den Speicherdruck erhöht.

Strategie 2: Implementierung robuster Räumungsrichtlinien

Unbegrenztes Wachstum ist die häufigste Ursache für vermeintliche Speicher„lecks“ in Redis. Wenn die Instanz als Cache verwendet wird, muss sie eine definierte Obergrenze für die Speichernutzung haben, die durch die maxmemory-Direktive durchgesetzt wird.

Wenn maxmemory nicht gesetzt ist, kann Redis weiterhin Speicher zuweisen, bis der Host unter Druck gerät. Auf einem dedizierten Redis-Rechner kann dies dazu führen, dass der Kernel Redis beendet. In einem Container kann die Container-Laufzeitumgebung ihn früher beenden.

Festlegen von maxmemory und Richtlinienauswahl

Geben Sie das maximale Speicherlimit in Ihrer redis.conf oder mit CONFIG SET an:

# Maximalen Speicher auf 4 GB setzen. Freiraum für Redis-Overhead, gegabelte Kindprozesse,
# den OS-Seitencache und andere Prozesse lassen.
CONFIG SET maxmemory 4gb

# Räumungsrichtlinie konfigurieren
# allkeys-lru: Räumt die am wenigsten kürzlich verwendeten Schlüssel aus dem *gesamten* Datensatz
CONFIG SET maxmemory-policy allkeys-lru

Richtlinienname	Beschreibung	Anwendungsfall
noeviction	Standard. Gibt Fehler bei Schreibbefehlen zurück, wenn das Speicherlimit erreicht ist.	Datenbanken, bei denen kein Datenverlust akzeptabel ist.
allkeys-lru	Räumt die am wenigsten kürzlich verwendeten Schlüssel unabhängig vom Ablauf.	Allgemeiner Cache.
volatile-lru	Räumt die am wenigsten kürzlich verwendeten Schlüssel nur unter denen mit einem Ablaufdatum.	Gemischte Anwendungsfälle (persistierte Daten + Cache-Daten).
allkeys-random	Räumt zufällige Schlüssel, wenn das Limit erreicht ist.	Einfache Sitzungsspeicher oder wenn das Zugriffsmuster unvorhersehbar ist.

Für einen reinen Cache ist allkeys-lru oder allkeys-lfu oft ein vernünftiger Ausgangspunkt. Für eine gemischte Redis-Instanz, bei der nur einige Schlüssel entbehrlich sind, kann volatile-lru oder eine andere volatile-*-Richtlinie sicherer sein, aber nur, wenn jeder Cache-Schlüssel ein Ablaufdatum hat. Die gefährliche Konfiguration ist ein Cache mit noeviction, keiner TTL-Disziplin und keiner Warnung, bevor der Speicher voll ist.

Strategie 3: Diagnose und Entfernung großer Schlüsselspitzen

Manchmal liegt das Problem nicht in der Anzahl der Schlüssel. Es ist ein Schlüssel, der ohne Begrenzung gewachsen ist: eine Benutzer-Feed-Liste, die nie gekürzt wird, ein sortiertes Set aller jemals gesehenen Ereignisse oder ein Hash, der als Sammelbecken für Sitzungsfelder dient.

Verwendung von redis-cli --bigkeys

Das Dienstprogramm redis-cli --bigkeys durchsucht den Schlüsselraum und meldet große Schlüssel nach Typ und Elementanzahl. Es misst nicht die genaue Byte-Größe und kann auf einer stark ausgelasteten Produktionsinstanz zusätzliche Last verursachen. Führen Sie es daher vorsichtig oder nach Möglichkeit gegen eine Replik aus.

# Bigkeys-Analyse ausführen
redis-cli --bigkeys

# Beispielausgabe (Identifizierung einer massiven Liste)
---------- Zusammenfassung ----------
...
[5] Größte Liste gefunden 'user:1001:feed' mit 859387 Elementen

Verwendung von MEMORY USAGE (Redis 4.0+)

Um die genaue Größe eines verdächtigen Schlüssels in Bytes zu bestimmen, verwenden Sie den Befehl MEMORY USAGE. Dies ist für eine gründliche Diagnose unerlässlich.

# Speichernutzung eines bestimmten Schlüssels überprüfen (in Bytes)
redis-cli MEMORY USAGE user:1001:feed

# Ausgabe: (z.B.) 84329014

Wenn Sie große Schlüssel identifizieren, überprüfen Sie den Schreibpfad. Übliche Lösungen sind das Kürzen von Listen mit LTRIM, das Ablaufen lassen von transienten Strukturen, das Aufteilen sehr großer Hashes oder sortierter Sets in kleinere partitionierte Schlüssel und das Ersetzen von „Alles laden“-Lesevorgängen durch seitenweisen Zugriff wie HSCAN, SSCAN oder ZSCAN. Die eigentliche Lösung liegt normalerweise im Anwendungsverhalten, nicht in einem Redis-Regler.

Strategie 4: Verwaltung von Speicherfragmentierung und Copy-on-Write

Hohe Fragmentierung oder plötzliche RSS-Anstiege werden oft mit Datenlecks verwechselt. Diese Probleme hängen mit Speicherzuweisung, Objektverschleiß und fork-basierter Persistenz zusammen.

Aktive Defragmentierung

Aktive Defragmentierung kann Redis helfen, verschwendeten Allokator-Speicher zurückzugewinnen, während der Server weiterläuft. Sie ist nützlich für Arbeitslasten, die viele unterschiedlich große Werte erstellen und löschen. Sie verbraucht auch CPU, aktivieren Sie sie daher bewusst und beobachten Sie die Latenz nach der Änderung.

Aktivieren und konfigurieren Sie sie in der redis.conf:

# Aktive Defragmentierung aktivieren
activedefrag yes

# Untere und obere Schwellenwerte sind prozentuale Konfigurationswerte.
active-defrag-threshold-lower 10
active-defrag-threshold-upper 100

Reduzierung des Copy-on-Write-Overheads

Wenn Redis einen Kindprozess für RDB-Snapshots oder AOF-Umschreibungen forkt, verwendet das Betriebssystem die CoW-Optimierung. Wenn der Elternprozess während der Aktivität des Kindprozesses viele Schreibvorgänge durchführt, muss jede geschriebene Seite dupliziert werden, was vorübergehend used_memory_rss in die Höhe treibt. Dieser Anstieg kann den Redis-Speicherverbrauch leicht verdoppeln.

Minderungsmaßnahmen:

1. Planen Sie Persistenz in verkehrsarmen Zeiten.
2. Lassen Sie Speicherreserven oberhalb von maxmemory für Allokator-Overhead, Clients, Replikationspuffer und gegabelte Kindprozesse. Der richtige Spielraum hängt von der Datensatzgröße und der Schreibrate ab; messen Sie ihn während eines echten BGSAVE oder BGREWRITEAOF.
3. Vermeiden Sie überlappende schwere Hintergrundarbeit wie Snapshots, AOF-Umschreibungen, Backups und Host-Level-Scans.
4. Reduzieren Sie Schreibverschleiß während der Persistenz, wenn ein Batch-Job Copy-on-Write-Wachstum verursacht.

Greifen Sie nicht als erste Reaktion zu Allokator-Umgebungsvariablen. Redis wird üblicherweise mit jemalloc erstellt, und eine Änderung des Allokator-Verhaltens ohne Tests kann neues Latenz- oder Speicherverhalten erzeugen. Wenn die Fragmentierung nach aktiver Defragmentierung und Arbeitslastkorrekturen schwerwiegend bleibt, testen Sie Änderungen auf einer Staging-Instanz oder einem Replikat, bevor Sie die Produktion berühren.

Ein praktischer Ablauf bei Vorfällen

Wenn der Speicher springt, sammeln Sie die Fakten, bevor Sie Redis neu starten. Ein Neustart kann die Beweise verbergen.

Führen Sie aus:

redis-cli INFO memory
redis-cli INFO persistence
redis-cli DBSIZE
redis-cli --bigkeys

Fragen Sie dann, was sich geändert hat. Hat ein Deployment TTLs entfernt? Hat ein Warteschlangenverbraucher aufgehört, sodass Listen wachsen konnten? Hat ein neuer Berichtsjob HGETALL auf riesigen Hashes ausgeführt? Hat eine AOF-Umschreibung während des Verkehrsspitzenwerts begonnen? Hat sich das Container-Speicherlimit geändert?

Die besten Redis-Speicherlösungen sind in der Regel einfach: Setzen Sie ein realistisches maxmemory, wählen Sie eine Räumungsrichtlinie, die zur Arbeitslast passt, geben Sie jedem Cache-Schlüssel eine TTL, brechen Sie unbegrenzte Strukturen auf, verhindern Sie, dass Persistenz ohne Speicherreserven läuft, und warnen Sie bei Speichertrends, bevor die Instanz die Klippe erreicht.