Korrekt dimensionering af Redis’ maxmemory: Hukommelsesreserver til data og drift

Hvad der rent faktisk begrænser maxmemory

maxmemory opretter en i Redis Open Source Tærskel for udsættelse Der er ingen fast, streng øvre grænse for Redis-processen eller dens container. Når det forbrugsniveau, der er relevant for hukommelsesstyringen, når tærsklen, forsøger Redis at fjerne nøgler afhængigt af den valgte politik. Ved en politik uden eviction kan skrivekommandoer, der øger hukommelsesforbruget, i stedet mislykkes.

Nøgletallet used_memory omfatter den hukommelse, som Redis allokerer via sin allokator. Dette omfatter ikke kun selve værdierne i din applikation, men også administrationsstrukturer og andre Redis-hukommelsesområder. Hvis man udleder grænsen udelukkende ud fra den anslåede størrelse af brugerdataene, tager man ikke højde for denne overhead.

En del af used_memory undtages ved Eviction-testen: mem_not_counted_for_evict indeholder især midlertidige replikations- og AOF-buffere. Disse buffere kræver dog stadig fysisk hukommelse. Værdien er allerede angivet i used_memory er indeholdt og må derfor ikke uden nærmere undersøgelse lægges til dette nøgletal en anden gang.

Det betyder dog ikke, at al klient- eller replikeringshukommelse er undtaget fra eviction-beregningen. En enkelt stor kommando kan desuden midlertidigt overskride tærsklen betydeligt. Hvis du maxmemory Hvis man udnytter containerens fulde kapacitet, er der ikke noget pålideligt spillerum til sådanne udsving og ekstra procesforbrug.

I forbindelse med planlægningen skal der derfor besvares to spørgsmål hver for sig: Hvor meget plads kræver datasættet og Redis-overheadet inden for hukommelsesstyringen? Og hvor meget reserve har hele kørselsmiljøet desuden brug for? Først når begge perspektiver ses i sammenhæng, kan man vurdere, om en valgt værdi under den faktiske hukommelsesgrænse er plausibel.

RSS, allokator og persistensspidser

Efter en belastningsspids kan used_memory falder, mens used_memory_rss forbliver høj: Redis har ganske vist frigivet hukommelse via allokatoren, men denne blev ikke nødvendigvis straks returneret til operativsystemet. RSS beskriver processens residente hukommelse set fra operativsystemets synspunkt og udgør derfor et andet observationsniveau.

Lad os antage, at en cache vokser kraftigt under en handling, og at mange nøgler udløber bagefter. Den mindre Redis-hukommelsesværdi betyder ikke automatisk, at containeren straks får tilsvarende meget ledig plads tilbage. For den næste spidsbelastning er det derfor vigtigere at se på det faktiske forbrug end at antage, at frigivet hukommelse forsvinder med det samme.

Også mem_fragmentation_ratio er ikke blot en fragmenteringsprocent. Forholdet omfatter yderligere procesandele; til årsagsanalysen bør du betragte det sammen med de tilgængelige allocator_*-målinger og belastningshistorikken. Man kan ikke udlede en generelt gældende reserve ud fra et enkelt forhold.

Ved RDB-snapshots og AOF-rewrites opretter Redis en underproces. Gennem Copy-on-Write Der kan desuden være behov for fysiske lagringssider, hvis siderne ændres under persistenskørslen. Jo større og bredere skrivebelastningen er i denne periode, desto vigtigere er det at holde øje med denne fase i forbindelse med kapacitetsplanlægningen.

Redis-administrationen angiver, at skriveintensive applikationer i ekstreme tilfælde kan kræve op til det dobbelte af den normalt anvendte hukommelse. Dette er en advarsel om ugunstige belastningsforhold, ikke en generel multiplikator. Du bør desuden ikke blot lægge RSS-værdierne for forældre- og underprocesser sammen: Fælles anvendte sider vil blive talt flere gange; det er relevant at overvåge den relevante vært eller container.

Replikaer kræver egne budgetter

En replika opbevarer som udgangspunkt en kopi af datamængden og har derfor brug for sin egen RAM. Primærinstansen og replikaen er derfor separate forbrugere af hukommelse: En reserve på primærinstansen frigør ikke plads i replikaens container. Planlæg hvert medlem ud fra dets egne begrænsninger og dets observerede forbrug.

Som standard ignorerer en replika sin konfigurerede maxmemory til egne sletninger. Primærserveren træffer beslutning om fjernelse af nøgler og replikerer sletningerne. Alligevel kan lagringsstatusene afvige fra hinanden, f.eks. på grund af forskellige buffere eller datastrukturer; den samme grænseværdi garanterer derfor ikke en identisk udnyttelsesgrad.

I tilfælde af en Forfremmelse overtager den tidligere replika rollen som primær. Kontroller derfor ikke kun, om den har tilstrækkelig plads som læsekopi, men også om dens lagergrænse og konfiguration kan understøtte driften som primær. Dette omfatter især skrivebelastning, replikeringsforbindelser og den på det tidspunkt gældende eviction-styring.

Siden Redis 7.0 deler replikabufferen og replikeringsbackloggen hukommelse. mem_clients_slaves kan derfor vise nul, selvom replikeringen optager hukommelse. Du bør ikke fortolke feltet isoleret og ikke uden videre lægge backlog og replikabuffer sammen som to fuldstændigt adskilte områder.

Ud over lagerforbruget er fremskridtet i dataoverførslen også relevant for driften: En forsinkelse udviser en anden egenskab end størrelsen på en buffer. Hvordan replikeringsstatus og efterslæb kan klassificeres, forklares i artiklen om Redis-replikationsforskydning. For lagerreserven er det dog stadig de faktiske forbrugsmønstre for hver enkelt instans, der er afgørende.

Registrering af lagerbeholdningen på tre niveauer

Til dimensioneringen skal du bruge værdier fra Redis og fra det miljø, hvor instansen kører. De Observationsniveau bestemmer, hvad et tal angiver: Allocator-belægning, proces-RSS og containerforbrug er forskellige størrelser og kan ikke blot lægges sammen.

Med INFO memory Du læser blandt andet Redis-lagringsværdierne og den konfigurerede politik. MEMORY STATS tilføjer oplysninger om hukommelsesfordelingen. Begge kommandoer er skrivebeskyttede; hvilke felter der er tilgængelige, afhænger af Redis-versionen, tilladelserne og hostingpakken.

For at vurdere den tidsmæssige sammenhæng skal du desuden kontrollere INFO persistence på persistensaktivitet og tilgængelige Copy-on-Write-værdier. INFO replication Viser rolle og replikeringstilstand. Indtast disse oplysninger separat for primær og replika, så et rollebytte eller en synkronisering fremgår tydeligt ved udvurderingen.

En enkelt værdi viser hverken den typiske udnyttelse eller den nødvendige spidsbelastningsreserve. Indsaml derfor tidsserier over normal drift, skrivespidsbelastninger og persistenskørsler, og knyt dem til det samtidig observerede host- eller containerforbrug. På den måde kan du også se, om en høj RSS-værdi ledsager en aktuel belastning, eller om den fortsat eksisterer efter en tidligere spidsbelastning.

Beregne et realistisk budget til lagerplads

Udgangspunktet er den faktisk gældende Lagringsgrænse: For en container kan den være lavere end værtsmaskinens RAM. Find ud af, hvilke andre processer og systemkomponenter der bruger den samme grænse. Den plads, der er afsat til dem, står ikke til rådighed for Redis til data eller spidsbelastninger.

Træk derefter reserver fra for yderligere RSS- og Allocator-effekter, buffere, der ikke er medregnet i eviction, persistensspidser og en sikkerhedsmargen. Resultatet er et foreløbigt maxmemory-Budget, ingen Redis-intern ligning. Reserverne skal passe til den samme grænse og til realistiske belastningstilstande, der opstår samtidigt.

Illustrativt regneeksempel, ikke en måling: Af en containergrænse på 8 GiB fratrækkes 0,5 GiB til andre forbrugere, 0,5 GiB til yderligere RSS-effekter, 0,5 GiB til buffere, der er undtaget fra eviction-beregningen, 1 GiB til en persistensspids og 0,5 GiB sikkerhedsafstand. Som foreløbig værdi forbliver der 5 GiB til maxmemory.

Disse tal er ikke en anbefaling til en konkret instans. Eksemplet forudsætter, at de angivne reserver beskriver yderligere, ikke-overlappende bidrag til containergrænsen. Især ved en persistenskørsel kan fælles hukommelsessider og Copy-on-Write gøre tildelingen vanskelig; en simpel sammenlægning af RSS-værdierne fra forældre- og underprocesser ville være uegnet til dette formål.

Undgå Dobbeltoptællinger: mem_not_counted_for_evict findes allerede i used_memory. Hvis du tager udgangspunkt i det samlede observerede RSS- eller containerforbrug, må du ikke blot lægge denne bufferandel til igen uden at kontrollere den. Det resterende eviction-budget skal rumme både datasættet og den medregnede Redis-overhead; test derefter tilgangen under en tilsvarende belastning.

Sammenligning af udkastningspolitikker i praksis

Die Udvisningspolitik bestemmer, hvordan Redis reagerer på skrivekommandoer, når der er pladsmangel. Den erstatter ikke kapacitetsplanlægning: Selv en passende politik kræver reserver ud over det, der indgår i eviction-beregningen. Beslutningen afhænger først og fremmest af, hvilke nøgler der må gå tabt, og hvordan applikationen reagerer på fejl.

I tilfælde af en ren cache kan allkeys-lru er relevant, hvis slettede poster kan gendannes fra en anden kilde. LRU er i Redis en tilnærmelse og ikke en præcis global sortering. Hyppige evictions kan medføre flere adgangsforespørgsler til backend; derfor er ikke kun ledige bytes, men også cache-hitrate og backend-kapacitet vigtige.

For data, der ikke kan slettes vilkårligt, gælder noeviction En anden beslutning: Applikationen skal kunne håndtere mislykkede skriveoperationer i stedet for automatisk at antage, at lagringen er lykkedes. Politikken handler hverken om persistens eller beskyttelse mod en OOM på operativsystem- eller containerniveau.

Ved blandede bestande er TTL-disciplin afgørende: En volatile-*-Policy kan kun vælge nøgler med udløbsdato. Hvis der er for få egnede kandidater, beskytter en TTL alene ikke mod skrivefejl. Kontroller derfor, om cachen og vigtige data virkelig bør dele den samme instans og fejlhåndteringsstrategi.

Sessionsdata tydeliggør målkonflikten: En slettet post kan for brugerne betyde tab af sessionstilstand, selvom applikationen teknisk set fortsætter med at køre. Vurder konsekvenserne og muligheden for gendannelse, inden du vælger en politik; yderligere baggrundsinformation findes i artiklen om Sessionstyring med Redis og andre datalagringssystemer.

Kontroller reserven under belastning

En beregnet værdi for maxmemory er i første omgang et udgangspunkt. Test det i et isoleret miljø med en tilsvarende Redis-version, datastruktur og lagergrænse. Belastningen bør ikke kun afspejle den normale drift, men også skrivespidser og faser, hvor persistens og replikering er aktive på samme tid.

Hold øje med Containerforbrug henholdsvis den relevante host-metrik samt Redis-lagerværdier. Notér, hvornår der kører et snapshot eller en AOF-rewrite, og om en replika synkroniseres. Det afgørende er, hvor stor afstand der er til den faktiske grænse under overlappende begivenheder, ikke kun i tomgang bagefter.

Med kommandoen »read« INFO stats Du registrerer blandt andet antallet af evictioner. Analyser ændringerne heri pr. tidsinterval: Et højt historisk niveau siger i sig selv ikke noget om, hvorvidt nøgler netop nu bliver fortrængt. Sæt stigende evictioner i sammenhæng med cache-hits og backend-belastning, forudsat at din applikation stiller disse tal til rådighed.

Registrer desuden Redis-OOM-svar i applikationen og lagerrelaterede containerhændelser på platformen. Begge fejl kan opstå ved en lignende belastning, men vedrører forskellige grænser. En alarm bør derfor tage højde for både den tilgængelige reserve og de observerede fejl samt deres tidsmæssige forløb.

Gentag vurderingen efter ændringer i datasættet, skrivebelastningen eller persistensen og replikeringen. Også en forfremmelse ændrer en replikas rolle og dermed det belastningsprofil, der skal kontrolleres. Resultaterne fra det isolerede miljø erstatter ikke den løbende overvågning af de produktive instanser.

Målrettet indsnævring af hukommelsesproblemer

Hvis proces-RSS stiger, mens used_memory Hvis der opstår et fald, skal du først se på forløbet og den tidligere belastning. Frigivet hukommelse behøver ikke straks at blive returneret til operativsystemet. Den Allocator-målinger fra INFO memory hjælper med at sætte det i perspektiv; fragmenteringsgraden i sig selv beviser hverken et hukommelseslæk eller årsagen hertil.

Kontroller derefter, om stigningen falder sammen med et persistensløb eller en synkronisering. Til dette formål anvendes INFO persistence og INFO replication. En enkelt værdi for en buffer, der ikke medregnes i eviction, beskriver kun den aktuelle tilstand. For at kunne opbygge en reserve skal du have observationer, der dækker relevante belastnings- og fejlfaser.

I tilfælde af en Redis-OOM-svar Kontroller den konfigurerede politik, og om der findes egnede nøgler til en eviction. En skrivekommando kan især mislykkes, hvis Redis ikke kan frigøre tilstrækkelig plads i henhold til den gældende politik. Applikationen skal håndtere denne fejl i stedet for at antage, at skriveoperationen lykkes.

Ved en hukommelsesrelateret container-nedbrud skal du derimod undersøge platformshændelserne og forbruget i forhold til containergrænsen. Medtag spidsbelastninger i persistensen og andre forbrugere, der registreres i containeren. En Redis-OOM og en container-OOM er ikke det samme: Den ydre hukommelsesgrænse kan nås, selv uden et forudgående Redis-OOM-svar.

maxmemory-clients kan desuden begrænse den hukommelse, der er optaget af klienter. Hvis den pågældende klienthukommelse overskrider den konfigurerede tærskel, kan Redis afbryde forbindelsen til klienter med højt forbrug; applikationer skal kunne håndtere afbrudte forbindelser. Indstillingen begrænser ikke alle replikeringsforbindelser og erstatter hverken det samlede budget eller overvågningen af buffertoppe.

Afvejning af Redis-hosting og -arkitektur

Hvis den observerede reserve ikke er tilstrækkelig ved en repræsentativ belastning, kan det være en god idé at øge RAM-kapaciteten, hvis datasættet og belastningen generelt skal forblive på én instans. Den ekstra kapacitet skal dog være en del af den faktisk gældende værts- eller containergrænse. En større Redis-grænse skaber i sig selv ikke yderligere fysisk hukommelse.

Alternativt kan en Fordeling af belastning fordele lagerbehovet og skrivearbejdet på flere instanser. Dette kræver en passende fordeling af dataene og en separat budgettering for hver involveret instans. Replikater skal dog ikke sidestilles med en opdeling af datamængden: De opbevarer som udgangspunkt en kopi og kræver derfor deres eget RAM.

Også en ændring af arkitekturen kan hjælpe, f.eks. adskillelsen af en tabstolerant cache fra data med strengere krav. Dermed kan politikker og kapaciteter vælges uafhængigt af hinanden. Hverken denne adskillelse, mere RAM eller belastningsfordeling garanterer dog, at der fremover ikke vil opstå spidsbelastninger i forbindelse med persistens, replikering og skrivning.

Når man sammenligner Udbyderbegrænsninger Afklar, om den angivne værdi henviser til en containergrænse, en instansgrænse eller en anden defineret databasegrænse. Spørg desuden, hvilke målinger og diagnostiske kommandoer der er tilgængelige, om replikaer er inkluderet i den reserverede lagerplads, og hvordan en promovering påvirker de tilgængelige ressourcer.

Redis Open Source, Redis Software og Redis Cloud skal betragtes hver for sig. For Redis Software gælder den dokumenterede databasegrænse på tværs af primære og replikerede shards; heraf følger ingen tilsvarende regel for en enkelt Redis OSS-instans. For Redis Cloud og andre hosting-tilbud skal du tjekke de konkrete produktbetingelser i hvert enkelt tilfælde, i stedet for at overføre denne definition uden at tjekke den først.