Redis maxmemory richtig dimensionieren: Speicherreserven für Daten und Betrieb

Was maxmemory tatsächlich begrenzt

maxmemory legt in Redis Open Source eine Eviction-Schwelle fest, keine harte Obergrenze für den Redis-Prozess oder seinen Container. Erreicht der für die Speichersteuerung relevante Verbrauch die Schwelle, versucht Redis abhängig von der gewählten Policy Schlüssel zu entfernen. Bei einer Policy ohne Eviction können speichervergrößernde Schreibbefehle stattdessen fehlschlagen.

Die Kennzahl used_memory umfasst den von Redis über seinen Allocator belegten Speicher. Dazu gehören nicht nur die eigentlichen Werte deiner Anwendung, sondern auch Verwaltungsstrukturen und weitere Redis-Speicherbereiche. Wer das Limit allein aus der geschätzten Größe der Nutzdaten ableitet, lässt diesen Overhead unberücksichtigt.

Ein Teil von used_memory wird bei der Eviction-Prüfung ausgenommen: mem_not_counted_for_evict weist insbesondere temporäre Replikations- und AOF-Puffer aus. Diese Puffer benötigen trotzdem realen Speicher. Der Wert ist bereits in used_memory enthalten und darf deshalb nicht ohne Prüfung ein zweites Mal zu dieser Kennzahl addiert werden.

Daraus folgt nicht, dass sämtliche Client- oder Replikationsspeicher außerhalb der Eviction-Rechnung liegen. Ein einzelner großer Befehl kann die Schwelle zudem vorübergehend deutlich überschreiten. Setzt du maxmemory auf das volle Containerlimit, bleibt für solche Ausschläge und zusätzlichen Prozessverbrauch kein verlässlicher Spielraum.

Für die Planung sind daher zwei Fragen getrennt zu beantworten: Wie viel Platz brauchen Datensatz und Redis-Overhead innerhalb der Speichersteuerung? Und wie viel Reserve benötigt die gesamte Laufzeitumgebung darüber hinaus? Erst beide Perspektiven zusammen zeigen, ob ein gewählter Wert unter der tatsächlichen Speichergrenze plausibel ist.

RSS, Allocator und Persistenzspitzen

Nach einer Lastspitze kann used_memory sinken, während used_memory_rss hoch bleibt: Redis hat dann zwar Speicher über den Allocator freigegeben, dieser wurde aber nicht zwingend sofort an das Betriebssystem zurückgegeben. RSS beschreibt den residenten Speicher des Prozesses aus Betriebssystemsicht und ist deshalb eine andere Beobachtungsebene.

Angenommen, ein Cache wächst während einer Aktion stark und viele Schlüssel laufen danach ab. Der kleinere Redis-Speicherwert bedeutet nicht automatisch, dass der Container sofort entsprechend viel freie Reserve zurückerhält. Für die nächste Spitze ist daher der Verlauf des tatsächlichen Verbrauchs wichtiger als die Annahme, dass freigegebener Speicher unmittelbar verschwindet.

Auch mem_fragmentation_ratio ist kein reiner Fragmentierungsprozentsatz. Das Verhältnis umfasst weitere Prozessanteile; für die Ursachenanalyse solltest du es zusammen mit den verfügbaren allocator_*-Metriken und der Lastgeschichte betrachten. Aus einem einzelnen Verhältnis lässt sich keine allgemein gültige Reserve ableiten.

Bei RDB-Snapshots und AOF-Rewrites erzeugt Redis einen Kindprozess. Durch Copy-on-Write können zusätzlich physische Speicherseiten benötigt werden, wenn während des Persistenzlaufs Seiten verändert werden. Je stärker und breiter die Schreiblast währenddessen ist, desto wichtiger ist es, diese Phase bei der Kapazitätsplanung zu beobachten.

Die Redis-Administration nennt für schreibintensive Anwendungen im Extrem einen Bedarf bis zum Doppelten des normalerweise genutzten Speichers. Das ist eine Warnung für ungünstige Lastverhältnisse, kein pauschaler Multiplikator. Addiere außerdem nicht einfach die RSS-Werte von Eltern- und Kindprozess: Gemeinsam genutzte Seiten würden mehrfach gezählt; relevant ist die passende Host- oder Containerbeobachtung.

Replikate brauchen eigene Budgets

Ein Replica hält grundsätzlich eine Kopie des Datenbestands und benötigt dafür eigenes RAM. Primary und Replica sind deshalb getrennte Speicherverbraucher: Eine Reserve auf dem Primary schafft keinen Platz im Container des Replica. Plane jedes Mitglied anhand seiner eigenen Grenze und seines beobachteten Verbrauchs.

Standardmäßig ignoriert ein Replica sein konfiguriertes maxmemory für eigene Evictions. Der Primary entscheidet über das Entfernen von Schlüsseln und repliziert die Löschungen. Trotzdem können sich die Speicherstände unterscheiden, etwa wegen abweichender Puffer oder Datenstrukturen; derselbe Grenzwert garantiert daher keine identische Auslastung.

Bei einer Promotion übernimmt das frühere Replica die Primary-Rolle. Prüfe deshalb nicht nur, ob es als lesende Kopie genügend Platz hat, sondern auch, ob seine Speichergrenze und Konfiguration den Betrieb als Primary tragen. Dazu gehören insbesondere Schreiblast, Replikationsverbindungen und die dann geltende Eviction-Steuerung.

Seit Redis 7.0 teilen sich Replica-Buffer und Replikations-Backlog Speicher. mem_clients_slaves kann deshalb null anzeigen, obwohl die Replikation Speicher beansprucht. Interpretiere das Feld nicht isoliert und addiere Backlog und Replica-Buffer nicht ungeprüft als vollständig getrennte Bereiche.

Neben dem Speicherverbrauch ist der Fortschritt der Datenübertragung für den Betrieb relevant: Eine Verzögerung zeigt eine andere Eigenschaft als die Größe eines Puffers. Wie sich Replikationsstand und Rückstand einordnen lassen, erklärt der Beitrag zum Redis Replication Offset. Für die Speicherreserve bleiben dennoch die tatsächlichen Verbrauchsverläufe jeder Instanz entscheidend.

Speicher auf drei Ebenen erfassen

Für die Dimensionierung brauchst du Werte aus Redis und von der Umgebung, in der die Instanz läuft. Die Beobachtungsebene entscheidet darüber, was eine Zahl aussagt: Allocator-Belegung, Prozess-RSS und Containerverbrauch sind unterschiedliche Größen und lassen sich nicht einfach addieren.

Mit INFO memory liest du unter anderem die Redis-Speicherwerte und die konfigurierte Policy. MEMORY STATS ergänzt Details zur Speicherverteilung. Beide Befehle sind lesend; welche Felder verfügbar sind, hängt von Redis-Version, Berechtigungen und Hosting-Angebot ab.

Für den zeitlichen Zusammenhang prüfst du außerdem INFO persistence auf Persistenzaktivität und verfügbare Copy-on-Write-Werte. INFO replication zeigt Rolle und Replikationszustand. Erfasse diese Angaben für Primary und Replica getrennt, damit ein Rollenwechsel oder eine Synchronisation bei der Auswertung erkennbar bleibt.

Ein einzelner Wert zeigt weder die typische Auslastung noch die notwendige Spitzenreserve. Sammle deshalb Zeitreihen über normalen Betrieb, Schreibspitzen und Persistenzläufe und ordne ihnen den gleichzeitig beobachteten Host- oder Containerverbrauch zu. So erkennst du auch, ob ein hoher RSS-Wert eine aktuelle Last begleitet oder nach einer früheren Spitze bestehen bleibt.

Ein belastbares Speicherbudget berechnen

Ausgangspunkt ist die tatsächlich wirksame Speichergrenze: Bei einem Container kann sie niedriger sein als der RAM des Hosts. Ermittle, welche anderen Prozesse und Betriebsanteile dieselbe Grenze beanspruchen. Was ihnen vorbehalten ist, steht Redis nicht für Daten oder Spitzen zur Verfügung.

Ziehe anschließend Reserven für zusätzliche RSS- und Allocator-Effekte, nicht für Eviction gezählte Buffer, Persistenzspitzen und einen Sicherheitsabstand ab. Das Ergebnis ist ein vorläufiges maxmemory-Budget, keine Redis-interne Gleichung. Die Reserven müssen zur gleichen Grenze und zu realistisch gleichzeitig auftretenden Lastzuständen passen.

Illustratives Rechenbeispiel, keine Messung: Von einer Containergrenze von 8 GiB werden 0,5 GiB für andere Verbraucher, 0,5 GiB für zusätzliche RSS-Effekte, 0,5 GiB für aus der Eviction-Rechnung ausgenommene Buffer, 1 GiB für eine Persistenzspitze und 0,5 GiB Sicherheitsabstand abgezogen. Als vorläufiger Wert bleiben 5 GiB für maxmemory.

Diese Zahlen sind keine Empfehlung für eine konkrete Instanz. Das Beispiel setzt voraus, dass die angesetzten Reserven zusätzliche, nicht überlappende Beiträge zur Containergrenze beschreiben. Gerade bei einem Persistenzlauf können gemeinsame Speicherseiten und Copy-on-Write die Zuordnung erschweren; eine bloße Addition der RSS-Werte von Eltern- und Kindprozess wäre dafür ungeeignet.

Vermeide Doppelzählungen: mem_not_counted_for_evict steckt bereits in used_memory. Wenn du vom beobachteten gesamten RSS oder Containerverbrauch ausgehst, darfst du diesen Bufferanteil nicht ungeprüft noch einmal addieren. Im verbleibenden Eviction-Budget müssen sowohl der Datensatz als auch der mitgezählte Redis-Overhead Platz finden; prüfe den Ansatz anschließend unter vergleichbarer Last.

Eviction-Policies im Praxisvergleich

Die Eviction-Policy bestimmt, wie Redis bei Speicherknappheit auf schreibende Befehle reagiert. Sie ersetzt keine Kapazitätsplanung: Selbst eine passende Policy benötigt Reserven außerhalb der Eviction-Rechnung. Die Entscheidung hängt vor allem davon ab, welche Schlüssel verloren gehen dürfen und wie die Anwendung auf Fehler reagiert.

Bei einem reinen Cache kann allkeys-lru passen, wenn sich entfernte Einträge aus einer anderen Quelle neu aufbauen lassen. LRU ist in Redis eine Näherung und keine exakte globale Sortierung. Häufige Evictions können mehr Zugriffe auf das Backend auslösen; deshalb sind nicht nur freie Bytes, sondern auch Cache-Trefferrate und Backend-Kapazität wichtig.

Für nicht beliebig löschbare Daten ist noeviction eine andere Entscheidung: Die Anwendung muss fehlgeschlagene Schreibvorgänge behandeln können, statt stillschweigend mit erfolgreicher Speicherung zu rechnen. Die Policy ist weder Persistenz noch Schutz vor einem OOM auf Betriebssystem- oder Containerebene.

Bei gemischten Beständen ist die TTL-Disziplin entscheidend: Eine volatile-*-Policy kann nur Schlüssel mit Ablaufzeit auswählen. Wenn zu wenige geeignete Kandidaten vorhanden sind, schützt eine TTL allein nicht vor Schreibfehlern. Prüfe deshalb, ob Cache und wichtige Daten wirklich dieselbe Instanz und Fehlerstrategie teilen sollten.

Session-Daten verdeutlichen den Zielkonflikt: Ein entfernter Eintrag kann für Nutzer den Verlust eines Sitzungszustands bedeuten, auch wenn die Anwendung technisch weiterläuft. Bewerte die Folgen und Wiederherstellbarkeit vor der Policy-Wahl; zusätzliche Grundlagen bietet der Beitrag zum Session-Management mit Redis und anderen Speichern.

Reserve unter Last überprüfen

Ein berechneter Wert für maxmemory ist zunächst ein Ausgangspunkt. Prüfe ihn in einer isolierten Umgebung mit vergleichbarer Redis-Version, Datenstruktur und Speichergrenze. Die Last sollte nicht nur den gewöhnlichen Betrieb abbilden, sondern auch Schreibspitzen und Phasen, in denen Persistenz und Replikation gleichzeitig aktiv sind.

Beobachte dabei den Containerverbrauch beziehungsweise die passende Host-Metrik ebenso wie Redis-Speicherwerte. Halte fest, wann ein Snapshot oder AOF-Rewrite läuft und ob ein Replica synchronisiert wird. Entscheidend ist, wie viel Abstand zur tatsächlichen Grenze während überlappender Ereignisse bleibt, nicht nur im Leerlauf danach.

Mit dem lesenden Befehl INFO stats erfasst du unter anderem Eviction-Zähler. Werte deren Änderung pro Zeitintervall aus: Ein hoher historischer Stand allein sagt nicht, ob gerade Schlüssel verdrängt werden. Setze steigende Evictions in Beziehung zu Cache-Treffern und Backend-Last, sofern deine Anwendung diese Größen bereitstellt.

Erfasse außerdem Redis-OOM-Antworten in der Anwendung und speicherbedingte Container-Ereignisse auf der Plattform. Beide Fehler können bei ähnlicher Last auftreten, betreffen aber unterschiedliche Grenzen. Eine Alarmierung sollte deshalb sowohl die verfügbare Reserve als auch die beobachteten Fehler und deren zeitlichen Verlauf berücksichtigen.

Wiederhole die Bewertung nach Änderungen am Datensatz, an der Schreiblast oder an Persistenz und Replikation. Auch eine Promotion verändert die Rolle eines Replica und damit das zu prüfende Lastprofil. Die Ergebnisse aus der isolierten Umgebung ersetzen nicht die fortlaufende Beobachtung der produktiven Instanzen.

Speicherprobleme gezielt eingrenzen

Steigt der Prozess-RSS, während used_memory fällt, betrachte zuerst den Verlauf und die vorherige Last. Freigegebener Speicher muss nicht sofort an das Betriebssystem zurückgehen. Die Allocator-Metriken aus INFO memory helfen bei der Einordnung; das Fragmentierungsverhältnis allein beweist weder ein Speicherleck noch dessen Ursache.

Prüfe anschließend, ob der Anstieg zeitlich mit einem Persistenzlauf oder einer Synchronisierung zusammenfällt. Dazu dienen INFO persistence und INFO replication. Ein einzelner Wert für nicht zur Eviction gezählte Buffer beschreibt nur den aktuellen Zustand. Für eine Reserve brauchst du Beobachtungen über relevante Last- und Störungsphasen hinweg.

Bei einer Redis-OOM-Antwort prüfe die konfigurierte Policy und ob geeignete Schlüssel für eine Eviction vorhanden sind. Insbesondere kann ein Schreibbefehl scheitern, wenn Redis unter der geltenden Policy keinen ausreichenden Platz freimachen kann. Die Anwendung muss diesen Fehler behandeln, statt einen erfolgreichen Schreibvorgang vorauszusetzen.

Bei einem speicherbedingten Container-Abbruch untersuche dagegen die Plattformereignisse und den Verbrauch gegenüber dem Containerlimit. Beziehe Persistenzspitzen und andere im Container erfasste Verbraucher ein. Ein Redis-OOM und ein Container-OOM sind nicht gleichzusetzen: Auch ohne eine vorherige Redis-OOM-Antwort kann die äußere Speichergrenze erreicht werden.

maxmemory-clients kann zusätzlich den von Clients belegten Speicher begrenzen. Überschreitet der relevante Client-Speicher die konfigurierte Schwelle, kann Redis Clients mit hohem Verbrauch trennen; Anwendungen müssen mit Verbindungsabbrüchen umgehen. Die Einstellung begrenzt nicht sämtliche Replikationsverbindungen und ersetzt weder das Gesamtbudget noch die Beobachtung von Pufferspitzen.

Redis Hosting und Architektur abwägen

Reicht die beobachtete Reserve bei repräsentativer Last nicht aus, kann mehr RAM sinnvoll sein, wenn Datensatz und Last grundsätzlich auf einer Instanz bleiben sollen. Die zusätzliche Kapazität muss jedoch zur tatsächlich wirksamen Host- oder Containergrenze gehören. Ein größeres Redis-Limit allein schafft keinen zusätzlichen physischen Speicher.

Alternativ kann eine Lastverteilung den Speicherbedarf und die Schreibarbeit auf mehrere Instanzen verteilen. Das erfordert eine passende Aufteilung der Daten und eine eigene Budgetierung für jede beteiligte Instanz. Replikate sind dabei nicht mit einer Aufteilung des Datenbestands gleichzusetzen: Sie halten grundsätzlich eine Kopie und benötigen dafür eigenes RAM.

Auch eine Architekturänderung kann helfen, etwa die Trennung eines verlusttoleranten Caches von Daten mit strengeren Anforderungen. Dadurch lassen sich Policies und Kapazitäten unabhängig wählen. Weder diese Trennung noch mehr RAM oder Lastverteilung garantiert allerdings, dass Persistenz-, Replikations- und Schreibspitzen künftig ausbleiben.

Beim Vergleich von Anbietergrenzen kläre, ob der ausgewiesene Wert ein Containerlimit, ein Instanzlimit oder ein anders definiertes Datenbanklimit bezeichnet. Frage außerdem, welche Metriken und Diagnosebefehle zugänglich sind, ob Replikate im gebuchten Speicher enthalten sind und wie sich eine Promotion auf die verfügbaren Ressourcen auswirkt.

Redis Open Source, Redis Software und Redis Cloud sind getrennt zu betrachten. Bei Redis Software gilt das dokumentierte Datenbanklimit über Primary- und Replica-Shards hinweg; daraus folgt keine entsprechende Regel für eine einzelne Redis-OSS-Instanz. Für Redis Cloud und andere Hosting-Angebote prüfst du die jeweils konkreten Produktbedingungen, statt diese Definition ungeprüft zu übertragen.