Dimensionera Redis maxmemory på rätt sätt: Minnesreserver för data och drift

Vad som faktiskt begränsar maxmemory

maxmemory lägger till en i Redis Open Source Tröskelvärde för vräkning Det finns ingen fast, strikt övre gräns för Redis-processen eller dess container. Om den minnesanvändning som är relevant för minneshanteringen når tröskelvärdet försöker Redis ta bort nycklar beroende på vilken policy som valts. Vid en policy utan uteslutning kan skrivkommandon som ökar minnesanvändningen istället misslyckas.

Nyckeltalet used_memory omfattar det minne som Redis upptar via sin allokator. Detta inkluderar inte bara själva värdena i din applikation, utan även förvaltningsstrukturer och andra Redis-minnesområden. Den som beräknar gränsen enbart utifrån den uppskattade storleken på användardata bortser från denna overhead.

En del av used_memory undantas vid utsläppningsprövningen: mem_not_counted_for_evict innehåller framför allt tillfälliga replikerings- och AOF-buffertar. Dessa buffertar kräver ändå fysiskt minne. Värdet finns redan i used_memory ingår och får därför inte läggas till detta nyckeltal en andra gång utan granskning.

Det innebär dock inte att allt klient- eller replikeringsminne ligger utanför beräkningen av utrymning. En enskild stor kommando kan dessutom tillfälligt överskrida tröskelvärdet avsevärt. Om du ställer in maxmemory Om man utnyttjar containergränsen fullt ut finns det inget tillförlitligt utrymme för sådana avvikelser och extra processresursförbrukning.

Vid planeringen måste man därför besvara två frågor separat: Hur mycket utrymme kräver datamängden och Redis-överheaden inom minneshanteringen? Och hur mycket reservutrymme behöver hela körningsmiljön utöver detta? Först när båda dessa perspektiv beaktas tillsammans framgår det om ett valt värde under den faktiska minnesgränsen är rimligt.

RSS, Allocator och persistensspikar

Efter en belastningstopp kan used_memory minskar, medan used_memory_rss förblir högt: Redis har visserligen frigjort minne via allokatorn, men detta har inte nödvändigtvis återlämnats till operativsystemet omedelbart. RSS beskriver processens residenta minne ur operativsystemets perspektiv och utgör därför en annan observationsnivå.

Anta att en cache växer kraftigt under en åtgärd och att många nycklar sedan löper ut. Det mindre Redis-minnesvärdet innebär inte automatiskt att behållaren omedelbart återfår motsvarande mängd ledigt utrymme. För nästa topp är därför utvecklingen av den faktiska förbrukningen viktigare än antagandet att frigjort minne omedelbart försvinner.

Dessutom mem_fragmentation_ratio är inte en ren fragmenteringsprocent. Förhållandet omfattar även andra processkomponenter; för orsaksanalysen bör du beakta det tillsammans med de tillgängliga allocator_*-mått och belastningshistoriken. Utifrån ett enskilt förhållande går det inte att fastställa någon allmängiltig reserv.

Vid RDB-snapshots och AOF-omskrivningar skapar Redis en underprocess. Genom Copy-on-Write Det kan dessutom krävas ytterligare fysiska lagringssidor om sidor ändras under persistenskörningen. Ju större och bredare skrivbelastningen är under denna tid, desto viktigare är det att beakta denna fas vid kapacitetsplaneringen.

Redis-administrationen anger att skrivintensiva applikationer i extrema fall kan kräva upp till dubbelt så mycket minne som normalt används. Detta är en varning för ogynnsamma belastningsförhållanden, inte en generell multiplikator. Lägg dessutom inte bara ihop RSS-värdena för moder- och barnprocesser: gemensamt använda sidor skulle räknas flera gånger; det som är relevant är att övervaka rätt värd eller container.

Repliker kräver egna budgetar

En replik innehåller i princip en kopia av datamängden och behöver därför eget RAM-minne. Primärinstansen och repliken är därför separata minnesförbrukare: En reserv på primärinstansen frigör inte utrymme i replikens container. Planera varje instans utifrån dess egna gränser och observerade förbrukning.

Som standard ignorerar en replik sin konfigurerade maxmemory för egna borttagningar. Primärservern beslutar om borttagning av nycklar och replikerar borttagningarna. Trots detta kan lagringsstatusen skilja sig åt, till exempel på grund av avvikande buffertar eller datastrukturer; samma gränsvärde garanterar därför inte identisk utnyttjandegrad.

Vid en Marknadsföring tar den tidigare repliken över rollen som primär. Kontrollera därför inte bara om den har tillräckligt med utrymme som läsreplik, utan också om dess lagringsgräns och konfiguration klarar driften som primär. Detta omfattar framför allt skrivbelastning, replikeringsanslutningar och den då gällande uteslutningsstyrningen.

Sedan Redis 7.0 delar replikbufferten och replikeringsköet på minnet. mem_clients_slaves kan därför visa noll, trots att replikeringen tar upp minnesutrymme. Tolka inte fältet isolerat och lägg inte ihop backlog och replikbuffert utan att kontrollera dem som helt separata områden.

Förutom minnesanvändningen är framstegen i dataöverföringen av betydelse för driften: en fördröjning har en annan egenskap än storleken på en buffert. Hur replikeringsstatus och eftersläpning kan klassificeras förklaras i artikeln om Redis-replikeringsoffset. För lagringsreserven är det dock fortfarande den faktiska förbrukningsutvecklingen för varje instans som är avgörande.

Registrera lagringsutrymmen på tre nivåer

För dimensioneringen behöver du värden från Redis och från den miljö där instansen körs. De Observationsnivå avgör vad en siffra står för: Allocator-beläggning, process-RSS och containerförbrukning är olika storheter och kan inte enkelt läggas ihop.

Med INFO memory läser du bland annat Redis-lagringsvärdena och den konfigurerade policyn. MEMORY STATS Lägger till detaljer om minnesfördelningen. Båda kommandona är av läsande karaktär; vilka fält som är tillgängliga beror på Redis-versionen, behörigheter och webbhotellspaketet.

För att kontrollera tidsmässiga samband ska du dessutom kontrollera INFO persistence på persistensaktivitet och tillgängliga Copy-on-Write-värden. INFO replication Visar roll och replikeringsstatus. Registrera dessa uppgifter separat för primär och replik, så att ett rollbyte eller en synkronisering framgår vid utvärderingen.

Ett enskilt värde visar varken den typiska belastningen eller den nödvändiga toppreserven. Samla därför in tidsserier över normal drift, skrivtoppar och persistenskörningar och koppla dem till den samtidigt observerade värd- eller containeranvändningen. På så sätt kan du också se om ett högt RSS-värde åtföljer en aktuell belastning eller kvarstår efter en tidigare topp.

Beräkna en hållbar lagringsbudget

Utgångspunkten är den faktiskt gällande Lagringsgräns: För en container kan den vara lägre än värdmaskinens RAM-minne. Ta reda på vilka andra processer och operativsystemskomponenter som utnyttjar samma gräns. Det utrymme som reserverats för dem står inte till Redis förfogande för data eller toppbelastningar.

Dra sedan av reserver för ytterligare RSS- och Allocator-effekter, buffertar som inte räknats in i eviction, persistensspikar och en säkerhetsmarginal. Resultatet blir ett preliminärt maxmemory-Budget, ingen Redis-intern ekvation. Reserverna måste stämma överens med samma gräns och med realistiska belastningsförhållanden som inträffar samtidigt.

Illustrativt räkneexempel, ingen mätning: Av en containergräns på 8 GiB avsätts 0,5 GiB för andra användare, 0,5 GiB för ytterligare RSS-effekter, 0,5 GiB för buffertar som undantas från eviction-beräkningen, 1 GiB för en persistensspets och 0,5 GiB säkerhetsmarginal. Som preliminärt värde återstår 5 GiB för maxmemory.

Dessa siffror utgör inte någon rekommendation för en specifik instans. Exemplet förutsätter att de angivna reserverna beskriver ytterligare, icke-överlappande bidrag till containergränsen. Särskilt vid en persistenskörning kan gemensamma minnessidor och Copy-on-Write försvåra tilldelningen; en enkel summering av RSS-värdena för föräldra- och barnprocessen skulle vara olämplig för detta ändamål.

Undvik Dubbelräkningar: mem_not_counted_for_evict finns redan i used_memory. Om du utgår från den totala RSS- eller containerförbrukningen som observerats får du inte lägga till denna buffertandel igen utan att kontrollera den. Både datamängden och den medräknade Redis-överheaden måste rymmas inom den återstående eviction-budgeten; kontrollera sedan metoden under jämförbar belastning.

Jämförelse av vräkningspolicyer i praktiken

Die Utsläppningspolicy bestämmer hur Redis reagerar på skrivkommandon vid lagringsbrist. Den ersätter inte kapacitetsplanering: även en lämplig policy kräver reserver utöver vad som ingår i uteslutningsberäkningen. Beslutet beror framför allt på vilka nycklar som får gå förlorade och hur applikationen reagerar på fel.

I fallet med en ren cache kan allkeys-lru är lämpligt om borttagna poster kan återskapas från en annan källa. LRU är i Redis en approximation och ingen exakt global sortering. Frekventa utplaceringar kan leda till fler åtkomstförfrågningar till backend; därför är inte bara lediga byte viktiga, utan även cacheträfffrekvensen och backend-kapaciteten.

För data som inte kan raderas godtyckligt gäller att noeviction Ett annat beslut: Applikationen måste kunna hantera misslyckade skrivoperationer, istället för att tyst utgå från att lagringen har lyckats. Policyn avser varken persistens eller skydd mot ett OOM-fel på operativsystem- eller containernivå.

När det gäller blandade bestånd är TTL-disciplin avgörande: En volatile-*-Policy kan endast välja nycklar med utgångstid. Om det finns för få lämpliga kandidater skyddar en TTL inte i sig mot skrivfel. Kontrollera därför om cachen och viktiga data verkligen bör dela samma instans och felstrategi.

Sessionsdata belyser målkonflikten: En borttagen post kan innebära att användaren förlorar sitt sessionsläge, även om applikationen tekniskt sett fortsätter att köras. Utvärdera konsekvenserna och möjligheten till återställning innan du väljer policy; ytterligare bakgrundsinformation finns i artikeln om Sessionshantering med Redis och andra lagringslösningar.

Kontrollera reserven under belastning

Ett beräknat värde för maxmemory är till att börja med en utgångspunkt. Testa den i en isolerad miljö med en jämförbar Redis-version, datastruktur och lagringsgräns. Belastningen bör inte bara återspegla den normala driften, utan även skrivtoppar och faser där persistens och replikering är aktiva samtidigt.

Observera då Containerförbrukning respektive motsvarande värdmetrik samt Redis-lagringsvärden. Notera när en snapshot eller AOF-omskrivning pågår och om en replik synkroniseras. Det avgörande är hur stort avståndet är till den faktiska gränsen under överlappande händelser, inte bara under tomgången därefter.

Med läsbefallningen INFO stats Du registrerar bland annat antalet evictions. Utvärdera hur dessa värden förändras per tidsintervall: En hög historisk nivå i sig säger inte om nycklar just nu trängs undan. Sätt de ökande evictions i relation till cacheträffar och belastning på backend, förutsatt att din applikation tillhandahåller dessa mått.

Registrera dessutom Redis-OOM-svar i applikationen och lagringsrelaterade containerhändelser på plattformen. Båda dessa fel kan uppstå vid liknande belastning, men berör olika gränsvärden. Ett larm bör därför ta hänsyn till både den tillgängliga reserven och de observerade felen samt deras tidsmässiga förlopp.

Upprepa utvärderingen efter ändringar av datamängden, skrivbelastningen eller persistensen och replikeringen. Även en befordran förändrar en repliks roll och därmed den belastningsprofil som ska kontrolleras. Resultaten från den isolerade miljön ersätter inte den löpande övervakningen av de produktiva instanserna.

Att på ett målinriktat sätt avgränsa lagringsproblem

Om process-RSS ökar medan used_memory Om minnet frigörs, ska du först beakta minnets användningshistorik och den tidigare belastningen. Frigjort minne behöver inte omedelbart återlämnas till operativsystemet. Det Allokator-mått från INFO memory hjälper till med att sätta in det i sitt sammanhang; fragmenteringsgraden i sig bevisar varken ett minnesläckage eller dess orsak.

Kontrollera därefter om ökningen sammanfaller tidsmässigt med ett persistenslopp eller en synkronisering. För detta ändamål används INFO persistence och INFO replication. Ett enskilt värde för en buffert som inte räknas in i eviction beskriver endast det aktuella tillståndet. För att beräkna en reserv behöver du observationer som sträcker sig över relevanta belastnings- och störningsfaser.

Vid en Redis-OOM-svar Kontrollera den konfigurerade policyn och se om det finns lämpliga nycklar för en eviction. En skrivkommando kan framför allt misslyckas om Redis inte kan frigöra tillräckligt med utrymme enligt den gällande policyn. Applikationen måste hantera detta fel istället för att förutsätta att skrivningen lyckas.

Vid ett minnesrelaterat containeravbrott bör du däremot undersöka plattformshändelserna och förbrukningen i förhållande till containergränsen. Ta hänsyn till toppar i persistensförbrukningen och andra förbrukare som registreras i containern. Ett Redis-OOM och ett container-OOM är inte samma sak: även utan ett tidigare Redis-OOM-svar kan den yttre minnesgränsen nås.

maxmemory-clients kan dessutom begränsa det minne som upptas av klienter. Om det aktuella klientminnet överskrider det konfigurerade tröskelvärdet kan Redis koppla bort klienter med hög minnesanvändning; applikationer måste hantera avbrott i anslutningen. Inställningen begränsar inte alla replikeringsanslutningar och ersätter varken den totala budgeten eller övervakningen av bufferttoppar.

Att väga in Redis-hosting och arkitektur

Om den observerade reserven inte räcker till vid en representativ belastning kan det vara lämpligt med mer RAM om datamängden och belastningen i princip ska förbli på en instans. Den extra kapaciteten måste dock ingå i den faktiskt gällande gränsen för värden eller containrar. En högre Redis-gräns i sig skapar inte ytterligare fysiskt minne.

Alternativt kan en Lastfördelning fördela lagringsbehovet och skrivbelastningen på flera instanser. Detta kräver en lämplig fördelning av data och en separat budgetering för varje berörd instans. Repliker ska dock inte likställas med en uppdelning av datamängden: de innehåller i princip en kopia och kräver därför eget RAM-minne.

Även en arkitekturändring kan vara till hjälp, till exempel att separera en förlusttolerant cache från data med strängare krav. På så sätt kan man välja policyer och kapacitet oberoende av varandra. Varken denna separering, mer RAM-minne eller lastfördelning garanterar dock att toppar i persistens, replikering och skrivningar inte kommer att uppstå i framtiden.

Vid en jämförelse mellan Leverantörsbegränsningar Kolla upp om det angivna värdet avser en containergräns, en instansgräns eller en annan typ av databasgräns. Fråga dessutom vilka mätvärden och diagnostikkommandon som är tillgängliga, om repliker ingår i det bokade lagringsutrymmet och hur en uppgradering påverkar de tillgängliga resurserna.

Redis Open Source, Redis Software och Redis Cloud ska betraktas separat. För Redis Software gäller den dokumenterade databasgränsen över både primära och replikerade shards; detta innebär inte att det finns någon motsvarande regel för en enskild Redis OSS-instans. För Redis Cloud och andra hostingtjänster bör du kontrollera de specifika produktvillkoren för respektive tjänst, istället för att tillämpa denna definition utan att först kontrollera den.