Active Defrag in Redis: Speicherfragmentierung automatisch im Hintergrund reduzieren

1. Wie fragmentierter Speicher trotz gelöschter Keys entsteht

Redis verwaltet seinen Arbeitsspeicher nicht selbst byteweise, sondern delegiert die eigentliche Speicherallokation an einen Allocator wie jemalloc, der Speicher in Blöcken fester Größenklassen vergibt. Wird ein kleines Objekt angefordert, wird es in eine passende Größenklasse eingeordnet, etwa 64 Byte oder 128 Byte, selbst wenn das eigentliche Objekt kleiner ist. Das beschleunigt Allokation und Freigabe erheblich, führt aber dazu, dass Speicher nicht beliebig fein zusammenhängend verwaltet wird.

Werden nun viele Objekte unterschiedlicher Größe in wechselnder Reihenfolge angelegt und wieder gelöscht, etwa durch ständig wechselnde Session-Daten oder ein Cache mit hoher Umschlagshäufigkeit, entstehen Lücken innerhalb der vom Allocator reservierten Speicherseiten. Diese Lücken sind zwar als frei markiert und stehen für neue Allokationen derselben Größenklasse zur Verfügung, können aber vom Betriebssystem nicht zurückgefordert werden, solange irgendein anderes, noch lebendes Objekt in derselben Speicherseite liegt. Das Resultat ist ein used_memory-Wert, der trotz sinkender tatsächlicher Datenmenge kaum oder gar nicht sinkt.

2. Fragmentierung messen: mem_fragmentation_ratio

Der zentrale Indikator für Speicherfragmentierung ist das Feld mem_fragmentation_ratio in der Ausgabe von INFO Memory. Es beschreibt das Verhältnis zwischen dem tatsächlich vom Betriebssystem an den Redis-Prozess vergebenen Speicher (Resident Set Size) und dem von Redis selbst als logisch benötigt gemeldeten Speicher. Ein Wert von 1.0 bedeutet keine messbare Fragmentierung, ein Wert von 1.5 zeigt, dass Redis fünfzig Prozent mehr physischen Speicher belegt, als für die eigentlichen Daten nötig wäre.

Werte deutlich über 1.5 gelten als Warnsignal und sollten Anlass sein, Active Defrag zu aktivieren oder dessen Tuning zu überprüfen. Interessant ist auch der umgekehrte Fall: Ein Verhältnis deutlich unter 1.0 deutet nicht auf effiziente Speichernutzung hin, sondern meist darauf, dass Redis mehr Speicher benötigt, als das Betriebssystem aktuell bereitstellt, etwa weil ein Teil des Speichers ausgelagert wurde, was ein eigenständiges, ernsteres Problem darstellt.

redis-cli INFO memory | grep -E "used_memory:|used_memory_rss:|mem_fragmentation_ratio"
# used_memory:2147483648
# used_memory_rss:3221225472
# mem_fragmentation_ratio:1.50

3. Wie der Active-Defrag-Mechanismus inkrementell umkopiert

Active Defrag läuft als periodischer Hintergrund-Zyklus innerhalb des Haupt-Threads von Redis, bewusst so gestaltet, dass er sich in kleine, unterbrechbare Arbeitsschritte aufteilt, statt den Server für eine längere zusammenhängende Zeitspanne zu blockieren. In jedem Zyklus untersucht Redis eine begrenzte Anzahl von Keys, prüft anhand interner Allocator-Statistiken, ob das jeweils zugrunde liegende Speicherobjekt stark fragmentiert vorliegt, und kopiert es bei Bedarf in eine frisch allozierte, kompaktere Speicherstelle um.

Nach dem Umkopieren wird der alte, fragmentierte Speicherbereich freigegeben, was dem Allocator ermöglicht, zusammenhängende Speicherseiten wieder vollständig frei zu bekommen und letztlich an das Betriebssystem zurückzugeben. Weil dieser Prozess in vielen kleinen Schritten abläuft und zwischen den Schritten immer wieder die Kontrolle an die reguleare Command-Verarbeitung zurückgibt, bleibt die Latenz für normale Client-Requests während des Defragmentierens praktisch unverändert, ganz im Gegensatz zu einem hypothetischen einmaligen, vollständigen Kompaktierungslauf.

4. Active Defrag aktivieren und Voraussetzungen

Active Defrag ist standardmäßig deaktiviert und muss über activedefrag yes explizit eingeschaltet werden, entweder in der redis.conf oder zur Laufzeit über CONFIG SET. Eine wichtige technische Voraussetzung: Der Mechanismus funktioniert nur zuverlässig mit jemalloc als Speicher-Allocator, weil er auf dessen interne Fragmentierungs-Statistiken pro Speicherseite angewiesen ist. Wird Redis mit libc als Allocator kompiliert, was in manchen minimalen Container-Images vorkommt, steht Active Defrag nicht zur Verfügung.

Wer unsicher ist, welcher Allocator aktiv ist, findet die Information direkt in der Ausgabe von INFO Server unter dem Feld mem_allocator. Offizielle Redis-Docker-Images verwenden standardmäßig jemalloc, sodass Active Defrag dort ohne zusätzliche Maßnahmen einsatzbereit ist, sobald es konfiguriert wird.

# Allocator prüfen
redis-cli INFO server | grep mem_allocator
# mem_allocator:jemalloc-5.3.0

# Active Defrag zur Laufzeit aktivieren
redis-cli CONFIG SET activedefrag yes

# Dauerhaft in redis.conf
activedefrag yes

5. Schwellenwerte: ab wann Active Defrag eingreift

Active Defrag arbeitet nicht kontinuierlich, sondern erst, sobald die gemessene Fragmentierung bestimmte konfigurierbare Schwellenwerte überschreitet. active-defrag-ignore-bytes legt eine absolute Mindestmenge an fragmentiertem Speicher fest, unterhalb derer sich ein Defrag-Lauf noch nicht lohnt, standardmäßig 100 Megabyte. active-defrag-threshold-lower definiert den prozentualen Fragmentierungsgrad, ab dem Active Defrag überhaupt zu arbeiten beginnt, standardmäßig zehn Prozent.

active-defrag-threshold-upper legt fest, ab welchem Fragmentierungsgrad Redis mit maximaler konfigurierter Intensität arbeitet, standardmäßig 100 Prozent. Zwischen diesen beiden Schwellenwerten skaliert die Aggressivität des Defrag-Prozesses linear: Je höher die gemessene Fragmentierung, desto mehr CPU-Zeit investiert Redis pro Zyklus in das Umkopieren, bis die obere Grenze erreicht ist und die konfigurierte Maximalintensität greift.

# Schwellenwerte anpassen
redis-cli CONFIG SET active-defrag-ignore-bytes 50mb
redis-cli CONFIG SET active-defrag-threshold-lower 5
redis-cli CONFIG SET active-defrag-threshold-upper 80

6. Tuning der CPU-Grenzen für den Defrag-Prozess

Zwei weitere Parameter steuern direkt, wie viel CPU-Zeit Active Defrag pro Sekunde verbrauchen darf: active-defrag-cycle-min legt die Mindest-CPU-Auslastung fest, die der Defrag-Prozess selbst bei niedriger Fragmentierung einsetzt, standardmäßig ein Prozent. active-defrag-cycle-max begrenzt die maximale CPU-Auslastung bei sehr hoher Fragmentierung, standardmäßig 25 Prozent. Diese Grenzen bestimmen den Kompromiss zwischen schneller Aufräumung und der CPU-Last, die für die eigentliche Command-Verarbeitung übrig bleibt.

In Umgebungen mit knapper CPU-Kapazität, etwa kleineren Cloud-Instanzen, die ohnehin nahe ihrer CPU-Grenze arbeiten, empfiehlt sich ein niedrigerer active-defrag-cycle-max-Wert, um zu vermeiden, dass Defrag-Aktivität mit dem eigentlichen Anwendungs-Traffic um CPU-Zeit konkurriert. Auf großzügig dimensionierter Hardware mit viel freier CPU-Reserve kann ein höherer Wert die Fragmentierung deutlich schneller abbauen, ohne dass produktive Requests darunter spürbar leiden.

# Konservatives Tuning für CPU-knappe Umgebungen
redis-cli CONFIG SET active-defrag-cycle-min 1
redis-cli CONFIG SET active-defrag-cycle-max 15

# Aggressiveres Tuning bei reichlich freier CPU-Kapazität
redis-cli CONFIG SET active-defrag-cycle-min 5
redis-cli CONFIG SET active-defrag-cycle-max 50

7. Wann sich Active Defrag lohnt und wann nicht

Active Defrag lohnt sich besonders bei Workloads mit hoher Schreib- und Löschfrequenz auf Keys unterschiedlicher Größe, etwa Session-Speicher mit ständig wechselnden Nutzern, Rate-Limiting-Zählern mit kurzer Lebensdauer, oder Cache-Ebenen mit häufiger Invalidierung. Bei überwiegend statischen Datenbeständen, die selten geändert werden, fällt kaum relevante Fragmentierung an, sodass der zusätzliche CPU-Verbrauch durch Active Defrag keinen messbaren Nutzen bringt.

In einem Magento-Setup mit Redis als Session- und Full-Page-Cache-Backend ist die Schreib- und Löschfrequenz typischerweise hoch genug, um von Active Defrag zu profitieren, insbesondere während verkaufsstarker Zeiten mit vielen parallelen Sessions und häufiger Cache-Invalidierung nach Preis- oder Bestandsänderungen. Ein aktiviertes Active Defrag mit moderatem Tuning verhindert dort, dass der Speicherverbrauch über Wochen hinweg kontinuierlich wächst, ohne dass die eigentliche Datenmenge im gleichen Maß zunimmt.

8. Grenzen von Active Defrag und alternative Maßnahmen

Active Defrag reduziert Fragmentierung, verhindert sie aber nicht grundsätzlich, und bei extrem hoher Schreiblast kann die Fragmentierung schneller entstehen, als der Prozess sie mit den konfigurierten CPU-Grenzen wieder abbauen kann. In solchen Fällen bleibt mem_fragmentation_ratio dauerhaft erhöht, selbst mit aktiviertem Active Defrag, und ein höheres active-defrag-cycle-max ist dann oft der wirksamste nächste Schritt, sofern die verfügbare CPU-Kapazität das zulässt.

Für Fälle, in denen Active Defrag nicht ausreicht oder aus Kompatibilitätsgründen nicht verfügbar ist, etwa bei einem Allocator ungleich jemalloc, bleibt als letztes Mittel ein manueller, kontrollierter Neustart der Redis-Instanz mit anschließendem Laden aus einem RDB-Snapshot oder AOF-Log, wodurch der gesamte Speicher frisch und ohne jede Fragmentierung neu aufgebaut wird. Das ist allerdings mit einer kurzen Downtime verbunden und sollte nur als geplante Wartungsmassnahme eingesetzt werden, nicht als Ersatz für laufendes Defrag-Tuning.

9. Praxis-Fazit: moderates Tuning als guter Startpunkt

Für die meisten produktiven Redis-Instanzen mit jemalloc als Allocator ist die Aktivierung von Active Defrag mit den Standardwerten bereits ein sinnvoller erster Schritt, der ohne spürbare Latenz-Nebenwirkungen kontinuierlich für geringere Speicherfragmentierung sorgt. Regelmäßiges Monitoring von mem_fragmentation_ratio über INFO Memory zeigt zuverlässig, ob die Standardwerte ausreichen oder ob ein Nachjustieren der CPU-Grenzen nötig ist.

Wer nach der Aktivierung weiterhin dauerhaft hohe Fragmentierungswerte beobachtet, sollte zunächst active-defrag-cycle-max schrittweise erhöhen, bevor tiefergehende Maßnahmen wie ein geplanter Neustart in Betracht gezogen werden. Die Kombination aus korrekt konfiguriertem jemalloc, aktivem Defrag und regelmäßigem Monitoring deckt die große Mehrheit der Fragmentierungsprobleme in produktiven Redis-Umgebungen zuverlässig ab.

10. Zusammenfassung

11. FAQ: Active Defrag