Redis maxmemory correct instellen: geheugenreserves voor gegevens en bedrijfsvoering

Wat de maxmemory-waarde daadwerkelijk beperkt

maxmemory voegt in Redis Open Source een Drempel voor uitzetting Er is geen vaste, strikte bovengrens voor het Redis-proces of de bijbehorende container. Als het geheugengebruik dat relevant is voor het geheugenbeheer de drempel bereikt, probeert Redis – afhankelijk van het gekozen beleid – sleutels te verwijderen. Bij een beleid zonder verwijdering kunnen schrijfopdrachten die het geheugengebruik vergroten, in plaats daarvan mislukken.

De kengetallen used_memory omvat het geheugen dat door Redis via zijn allocator wordt ingenomen. Hieronder vallen niet alleen de eigenlijke waarden van je toepassing, maar ook beheersstructuren en andere Redis-geheugengebieden. Wie de limiet uitsluitend afleidt uit de geschatte omvang van de gebruiksgegevens, houdt geen rekening met deze overhead.

Een deel van used_memory wordt bij de Eviction-test buiten beschouwing gelaten: mem_not_counted_for_evict bevat met name tijdelijke replicatie- en AOF-buffers. Deze buffers nemen niettemin fysiek geheugen in beslag. De waarde is al opgenomen in used_memory is hierin al opgenomen en mag daarom niet zonder controle nogmaals bij deze kengetallen worden opgeteld.

Dit betekent niet dat alle client- of replicatieopslag buiten de berekening van de eviction valt. Bovendien kan een enkele grote opdracht de drempel tijdelijk aanzienlijk overschrijden. Als je maxmemory Als de container volledig vol raakt, blijft er geen betrouwbare marge over voor dergelijke pieken en extra procesbelasting.

Bij de planning moeten daarom twee vragen afzonderlijk worden beantwoord: hoeveel ruimte nemen de dataset en de Redis-overhead in beslag binnen het geheugenbeheer? En hoeveel reserve heeft de gehele runtime-omgeving daarnaast nodig? Pas als beide perspectieven samen worden bekeken, wordt duidelijk of een gekozen waarde onder de daadwerkelijke geheugenlimiet aannemelijk is.

RSS, allocator en piekwaarden voor persistentie

Na een piekbelasting kan used_memory dalen, terwijl used_memory_rss hoog blijft: Redis heeft het geheugen weliswaar via de allocator vrijgegeven, maar dit is niet per se onmiddellijk teruggegeven aan het besturingssysteem. RSS beschrijft het residente geheugen van het proces vanuit het perspectief van het besturingssysteem en is daarom een ander observatieniveau.

Stel dat een cache tijdens een actie sterk groeit en dat daarna veel sleutels verlopen. De kleinere Redis-geheugenwaarde betekent niet automatisch dat de container onmiddellijk evenveel vrije reserve terugkrijgt. Voor de volgende piek is het verloop van het daadwerkelijke verbruik daarom belangrijker dan de aanname dat vrijgegeven geheugen onmiddellijk verdwijnt.

Ook mem_fragmentation_ratio is geen puur fragmentatiepercentage. De verhouding omvat nog andere procescomponenten; voor de oorzakenanalyse moet je deze samen met de beschikbare allocator_*-statistieken en de belastinggeschiedenis in ogenschouw nemen. Uit één enkele verhouding kan geen algemeen geldende reserve worden afgeleid.

Bij RDB-snapshots en AOF-rewrites maakt Redis een subproces aan. Door Copy-on-Write Er kunnen bovendien extra fysieke opslagpagina’s nodig zijn als er tijdens de persistentieronde pagina’s worden gewijzigd. Hoe intensiever en breder de schrijfbelasting tijdens deze fase is, hoe belangrijker het is om deze fase bij de capaciteitsplanning in de gaten te houden.

De Redis-beheerder geeft aan dat voor toepassingen met intensief schrijfverkeer in extreme gevallen tot wel het dubbele van het normaal gebruikte geheugen nodig kan zijn. Dit is een waarschuwing voor ongunstige belastingverhoudingen, geen algemene vermenigvuldigingsfactor. Tel bovendien niet zomaar de RSS-waarden van het bovenliggende en het onderliggende proces bij elkaar op: gezamenlijk gebruikte pagina’s zouden dan meerdere keren worden geteld; relevant is de juiste host- of containerobservatie.

Replica’s hebben een eigen budget nodig

Een replica bewaart in principe een kopie van de gegevens en heeft daarvoor eigen RAM nodig. De primaire en de replica zijn daarom afzonderlijke geheugenverbruikers: een reserve op de primaire zorgt niet voor extra ruimte in de container van de replica. Plan elk lid op basis van zijn eigen limiet en zijn waargenomen verbruik.

Standaard negeert een replica zijn geconfigureerde maxmemory voor eigen verwijderingen. De Primary beslist over het verwijderen van sleutels en repliceert de verwijderingen. Toch kunnen de opslagstanden van elkaar verschillen, bijvoorbeeld vanwege afwijkende buffers of gegevensstructuren; dezelfde drempelwaarde garandeert daarom geen identieke belasting.

Bij een Promotie neemt de voormalige replica de primaire rol over. Controleer daarom niet alleen of deze als leeskopie voldoende ruimte heeft, maar ook of de opslaglimiet en configuratie ervan geschikt zijn voor gebruik als primaire server. Hierbij gaat het met name om de schrijfbelasting, de replicatieverbindingen en de op dat moment geldende eviction-regeling.

Sinds Redis 7.0 delen de replicabuffer en de replicatie-backlog geheugen. mem_clients_slaves kan daarom nul aangeven, hoewel de replicatie geheugen in beslag neemt. Interpreteer het veld niet op zichzelf en tel de backlog en de replicabuffer niet zonder controle bij elkaar op als volledig afzonderlijke gebieden.

Naast het geheugengebruik is ook de voortgang van de gegevensoverdracht van belang voor de werking: een vertraging vertoont andere kenmerken dan de grootte van een buffer. Hoe de replicatiestatus en de achterstand kunnen worden ingedeeld, wordt uitgelegd in het artikel over de Redis-replicatie-offset. Voor de opslagreserve blijven echter de daadwerkelijke verbruiksontwikkelingen van elke instantie doorslaggevend.

Opslag op drie niveaus registreren

Voor de dimensionering heb je waarden nodig uit Redis en uit de omgeving waarin de instantie draait. De observatieniveau bepaalt wat een getal aangeeft: allocatorbezetting, proces-RSS en containergebruik zijn verschillende grootheden en kunnen niet zomaar bij elkaar worden opgeteld.

Met INFO memory lees je onder andere de Redis-opslagwaarden en het geconfigureerde beleid. MEMORY STATS voegt details over de geheugenverdeling toe. Beide commando’s zijn alleen-lezen; welke velden beschikbaar zijn, hangt af van de Redis-versie, de machtigingen en het hostingpakket.

Om het tijdsverband te controleren, kijk je bovendien of INFO persistence op persistentieactiviteit en beschikbare Copy-on-Write-waarden. INFO replication Geeft de rol en de replicatiestatus weer. Voer deze gegevens afzonderlijk in voor de primaire en de replica, zodat een rolwisseling of een synchronisatie bij de evaluatie herkenbaar blijft.

Een enkele waarde geeft noch de typische belasting, noch de benodigde piekreserve weer. Verzamel daarom tijdreeksen over normale bedrijfsvoering, schrijfpieken en persistentieruns en koppel deze aan het gelijktijdig waargenomen host- of containerverbruik. Zo kun je ook zien of een hoge RSS-waarde gepaard gaat met een actuele belasting of blijft bestaan na een eerdere piek.

Een realistisch opslagbudget berekenen

Het uitgangspunt is de daadwerkelijk geldende Opslaglimiet: Bij een container kan deze lager zijn dan het RAM-geheugen van de host. Ga na welke andere processen en systeemonderdelen dezelfde limiet in beslag nemen. Wat voor hen is gereserveerd, is niet beschikbaar voor Redis voor gegevens of pieken.

Trek vervolgens reserves af voor extra RSS- en allocator-effecten, buffers die niet voor eviction zijn meegeteld, pieken in de persistentie en een veiligheidsmarge. Het resultaat is een voorlopige maxmemory-Budget, geen interne Redis-vergelijking. De reserves moeten overeenkomen met dezelfde limiet en met realistische, gelijktijdig optredende belastingtoestanden.

Illustratief rekenvoorbeeld, geen meting: van een containerlimiet van 8 GiB wordt 0,5 GiB afgetrokken voor andere gebruikers, 0,5 GiB voor extra RSS-effecten, 0,5 GiB voor buffers die buiten de eviction-berekening vallen, 1 GiB voor een piek in de persistentie en 0,5 GiB veiligheidsmarge. Als voorlopige waarde blijft er 5 GiB over voor maxmemory.

Deze cijfers vormen geen aanbeveling voor een specifieke instantie. Het voorbeeld gaat ervan uit dat de toegewezen reserves extra, niet-overlappende bijdragen aan de containerlimiet beschrijven. Juist bij een persistentie-run kunnen gedeelde geheugenpagina's en copy-on-write de toewijzing bemoeilijken; een loutere optelling van de RSS-waarden van het ouder- en kindproces zou hiervoor ongeschikt zijn.

Vermijd Dubbele tellingen: mem_not_counted_for_evict zit al in used_memory. Als je uitgaat van het totale waargenomen RSS- of containerverbruik, mag je dit bufferaandeel niet zonder controle nogmaals optellen. In het resterende eviction-budget moeten zowel de dataset als de meegerekende Redis-overhead ruimte vinden; test de aanpak vervolgens onder vergelijkbare belasting.

Een vergelijking van uitzettingsbeleid in de praktijk

De Uitzettingsbeleid bepaalt hoe Redis reageert op schrijfopdrachten wanneer er onvoldoende opslagruimte is. Het is geen vervanging voor capaciteitsplanning: zelfs een geschikt beleid vereist reserves buiten de eviction-berekening om. De beslissing hangt vooral af van welke sleutels mogen verloren gaan en hoe de toepassing op fouten reageert.

Bij een zuivere cache kan allkeys-lru van toepassing zijn wanneer verwijderde records uit een andere bron opnieuw kunnen worden opgebouwd. LRU is in Redis een benadering en geen exacte globale sortering. Frequente verwijderingen kunnen leiden tot meer verzoeken aan de backend; daarom zijn niet alleen vrije bytes, maar ook de cache-hitratio en de capaciteit van de backend van belang.

Voor gegevens die niet zomaar kunnen worden gewist, geldt noeviction een andere beslissing: de applicatie moet in staat zijn om mislukte schrijfbewerkingen af te handelen, in plaats van er stilzwijgend van uit te gaan dat het opslaan is gelukt. Het beleid heeft geen betrekking op persistentie, noch op bescherming tegen een OOM op besturingssysteem- of containerniveau.

Bij gemengde bestanden is de TTL-discipline cruciaal: Een volatile-*-Policy kan alleen sleutels met een vervaltijd selecteren. Als er te weinig geschikte kandidaten zijn, biedt een TTL op zichzelf geen bescherming tegen schrijffouten. Controleer daarom of de cache en belangrijke gegevens werkelijk dezelfde instantie en foutbehandelingsstrategie moeten delen.

Sessiegegevens illustreren het doelconflict: het verwijderen van een vermelding kan voor gebruikers het verlies van de sessiestatus betekenen, ook al blijft de applicatie technisch gezien draaien. Beoordeel de gevolgen en de herstelbaarheid voordat je een beleid kiest; aanvullende informatie vind je in het artikel over de Sessiebeheer met Redis en andere opslagsystemen.

De reserve onder belasting controleren

Een berekende waarde voor maxmemory Dit is in eerste instantie een uitgangspunt. Test het in een geïsoleerde omgeving met een vergelijkbare Redis-versie, gegevensstructuur en opslaglimiet. De belasting moet niet alleen de normale bedrijfsvoering weerspiegelen, maar ook schrijfpieken en fasen waarin persistentie en replicatie tegelijkertijd actief zijn.

Let daarbij op de Containerverbruik respectievelijk de bijbehorende host-metriek en de Redis-opslagwaarden. Noteer wanneer er een snapshot of een AOF-rewrite wordt uitgevoerd en of een replica wordt gesynchroniseerd. Het is van cruciaal belang hoeveel tijd er overblijft tot de daadwerkelijke grens tijdens overlappende gebeurtenissen, niet alleen in de rustperiode daarna.

Met het leescommando INFO stats Je registreert onder andere het aantal evictions. Analyseer de verandering daarvan per tijdsinterval: een hoog historisch niveau zegt op zichzelf nog niet of er op dit moment sleutels worden verdrongen. Breng het stijgende aantal evictions in verband met cache-hits en de backend-belasting, voor zover je applicatie deze gegevens beschikbaar stelt.

Registreer bovendien Redis-OOM-reacties in de applicatie en opslaggerelateerde containergebeurtenissen op het platform. Beide fouten kunnen bij een vergelijkbare belasting optreden, maar hebben betrekking op verschillende limieten. Een alarmmelding moet daarom zowel rekening houden met de beschikbare reserve als met de waargenomen fouten en het tijdsverloop daarvan.

Herhaal de evaluatie na wijzigingen in de dataset, de schrijfbelasting of de persistentie en replicatie. Ook een promotie verandert de rol van een replica en daarmee het te controleren belastingsprofiel. De resultaten uit de geïsoleerde omgeving zijn geen vervanging voor de voortdurende monitoring van de productieve instanties.

Opslagproblemen gericht inperken

Als de proces-RSS stijgt, terwijl used_memory Als er geheugen vrijkomt, kijk dan eerst naar het verloop en de eerdere belasting. Vrijgekomen geheugen hoeft niet onmiddellijk terug te gaan naar het besturingssysteem. De Allocator-statistieken van INFO memory helpen bij de interpretatie; de fragmentatiegraad op zich bewijst noch een geheugenlek, noch de oorzaak daarvan.

Controleer vervolgens of de stijging samenvalt met een persistentieloop of een synchronisatie. Hiervoor dienen INFO persistence en INFO replication. Een enkele waarde voor buffers die niet bij de eviction worden meegeteld, geeft alleen de huidige toestand weer. Voor een reserve heb je waarnemingen nodig over relevante belasting- en storingsfasen heen.

Bij een Redis-OOM-antwoord Controleer het geconfigureerde beleid en of er geschikte sleutels beschikbaar zijn voor een eviction. Een schrijfopdracht kan met name mislukken als Redis onder het geldende beleid onvoldoende ruimte kan vrijmaken. De toepassing moet deze fout afhandelen, in plaats van ervan uit te gaan dat het schrijven succesvol is verlopen.

Bij een door geheugenproblemen veroorzaakte container-afbreking moet je daarentegen de platformgebeurtenissen en het verbruik vergelijken met de containerlimiet. Houd daarbij rekening met pieken in de persistentie en andere verbruikers die in de container worden geregistreerd. Een Redis-OOM en een container-OOM zijn niet hetzelfde: zelfs zonder een voorafgaande Redis-OOM-melding kan de externe geheugenlimiet worden bereikt.

maxmemory-clients kan bovendien het door clients gebruikte geheugen beperken. Als het betreffende clientgeheugen de geconfigureerde drempel overschrijdt, kan Redis clients met een hoog verbruik verbreken; applicaties moeten omgaan met verbroken verbindingen. Deze instelling beperkt niet alle replicatieverbindingen en vervangt noch het totale budget, noch het monitoren van bufferspieken.

Redis-hosting en -architectuur afwegen

Als de waargenomen reserve bij een representatieve belasting niet toereikend is, kan meer RAM zinvol zijn als de dataset en de belasting in principe op één instantie moeten blijven. De extra capaciteit moet echter deel uitmaken van de daadwerkelijk geldende host- of containerlimiet. Een hogere Redis-limiet alleen zorgt niet voor extra fysiek geheugen.

Als alternatief kan een Belastingverdeling de opslagbehoefte en de schrijfbewerkingen over meerdere instanties verdelen. Dit vereist een passende verdeling van de gegevens en een eigen budget voor elke betrokken instantie. Replica’s zijn daarbij niet hetzelfde als een verdeling van de gegevens: ze bevatten in principe een kopie en hebben daarvoor eigen RAM nodig.

Ook een aanpassing van de architectuur kan helpen, bijvoorbeeld door een verliesbestendige cache te scheiden van gegevens met strengere eisen. Hierdoor kunnen beleidsregels en capaciteiten onafhankelijk van elkaar worden gekozen. Noch deze scheiding, noch meer RAM of lastverdeling garandeert echter dat er in de toekomst geen pieken in persistentie, replicatie en schrijfverkeer meer zullen optreden.

Bij het vergelijken van Beperkingen van de aanbieder Ga na of de weergegeven waarde betrekking heeft op een containerlimiet, een instantielimiet of een anders gedefinieerde databaselimiet. Vraag bovendien welke statistieken en diagnostische commando’s beschikbaar zijn, of replicaten zijn inbegrepen in de geboekte opslagruimte en wat het effect is van een promotie op de beschikbare resources.

Redis Open Source, Redis Software en Redis Cloud moeten afzonderlijk worden beschouwd. Voor Redis Software geldt de gedocumenteerde databaselimiet voor zowel primaire als replica-shards; hieruit volgt geen overeenkomstige regel voor een afzonderlijke Redis OSS-instantie. Voor Redis Cloud en andere hostingaanbiedingen raadpleeg je de specifieke productvoorwaarden, in plaats van deze definitie klakkeloos over te nemen.