{"id":21291,"date":"2026-09-11T11:51:31","date_gmt":"2026-09-11T09:51:31","guid":{"rendered":"https:\/\/webhosting.de\/redis-memory-fragmentation-ratio-richtig-interpretieren-speicheranalyse\/"},"modified":"2026-09-11T11:51:31","modified_gmt":"2026-09-11T09:51:31","slug":"korrekt-fortolkning-af-redis-hukommelsesfragmenteringsgrad-hukommelsesanalyse","status":"publish","type":"post","link":"https:\/\/webhosting.de\/da\/redis-memory-fragmentation-ratio-richtig-interpretieren-speicheranalyse\/","title":{"rendered":"Korrekt fortolkning og optimering af Redis\u2019 hukommelsesfragmenteringsgrad"},"content":{"rendered":"<p><strong>Fragmentering i Redis<\/strong> bestemmer, hvor meget arbejdshukommelse der g\u00e5r tabt mellem den RSS, som operativsystemet tildeler, og de faktisk anvendte Redis-data, og hvordan jeg undg\u00e5r latenstid, swap og nedbrud. Jeg forklarer <strong>Redis-hukommelsesfragmenteringsgrad<\/strong> er praksisorienteret, angiver fornuftige gr\u00e6nsev\u00e6rdier og giver klare retningslinjer for finjustering, overv\u00e5gning og datamodellering.<\/p>\n\n<h2>Centrale punkter<\/h2>\n\n<ul>\n  <li><strong>Definition af<\/strong>: Fortolk forholdet mellem used_memory_rss og used_memory korrekt.<\/li>\n  <li><strong>Gr\u00e6nsev\u00e6rdier<\/strong>: Handl ved 1,5 eller derover; kontroller straks ved 1,0 eller derunder.<\/li>\n  <li><strong>\u00c5rsager<\/strong>: Varierende objektst\u00f8rrelser, sletningsb\u00f8lger, lange k\u00f8retider.<\/li>\n  <li><strong>Foranstaltninger<\/strong>: Active Defrag, budgettering, stramning af datamodellen.<\/li>\n  <li><strong>Overv\u00e5gning<\/strong>: Indstil alarmer for Ratio- og Allocator-v\u00e6rdier.<\/li>\n<\/ul>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/redis-analyse-4032.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Hvad betyder \u00bbmem_fragmentation_ratio\u00ab helt pr\u00e6cist?<\/h2>\n\n<p>Jeg bruger n\u00f8gletallet <strong>mem_fragmentering_ratio<\/strong>, for at se forholdet mellem RSS og dataforbrug. Kvotienten af <strong>brugt_hukommelse_rss<\/strong> divideret med <strong>brugt_hukommelse<\/strong> viser, hvor t\u00e6t Redis pakker RAM\u2019en. V\u00e6rdier t\u00e6t p\u00e5 1,0 indikerer en <strong>effektiv<\/strong> Udnyttelsesgrad med f\u00e5 tomme omr\u00e5der. H\u00f8je v\u00e6rdier tyder p\u00e5, at der i processen findes mange ledige omr\u00e5der, som allokatoren ikke kan genbruge. Jeg vurderer aldrig denne v\u00e6rdi isoleret, men sammen med st\u00f8rrelse, arbejdsbelastning og <strong>Allocator<\/strong>-m\u00e5linger.<\/p>\n\n<h2>At s\u00e6tte retningsv\u00e6rdier i den rette sammenh\u00e6ng<\/h2>\n\n<p>Jeg sorterer den <strong>Forhold<\/strong> i faste zoner, s\u00e5 beslutningerne forbliver reproducerbare. Sm\u00e5 overskridelser p\u00e5 omkring 1,1 er for mig helt normale <strong>Overhead<\/strong>. Fra ca. 1,5 planl\u00e6gger jeg at gribe ind, da RAM ellers g\u00e5r tabt, eller systemet n\u00e6rmer sig OOM-gr\u00e6nserne. Under 1,0 reagerer jeg straks, da det tyder p\u00e5 <strong>Bytte<\/strong> . Den f\u00f8lgende tabel opsummerer typiske omr\u00e5der og handlinger.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th><strong>Forhold<\/strong><\/th>\n      <th><strong>Betydning<\/strong><\/th>\n      <th><strong>\u00f8jeblikkelig foranstaltning<\/strong><\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>Under 1,0<\/td>\n      <td><strong>Bytte<\/strong>-risiko, stor forsinkelse<\/td>\n      <td>Kontroller RAM\/maks. hukommelse, reducer datam\u00e6ngden<\/td>\n    <\/tr>\n    <tr>\n      <td>1,0\u20131,1<\/td>\n      <td><strong>Sund<\/strong> med et let overhead<\/td>\n      <td>Forts\u00e6t med at holde \u00f8je med det, intet presserende<\/td>\n    <\/tr>\n    <tr>\n      <td>1,1\u20131,5<\/td>\n      <td><strong>Normal<\/strong>, moderat fragmentering<\/td>\n      <td>F\u00f8lg tendenser, noter \u00e5rsagerne<\/td>\n    <\/tr>\n    <tr>\n      <td>Over 1,5<\/td>\n      <td><strong>Forh\u00f8jet<\/strong>, spild af lagerplads<\/td>\n      <td>Active Defrag, Kontroller model, Test Purge<\/td>\n    <\/tr>\n    <tr>\n      <td>Over 2,0<\/td>\n      <td><strong>H\u00f8j<\/strong>, kapacitetspres<\/td>\n      <td>Aggressiv defragmentering \u2013 overvej at genstarte<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/redis_meeting_optimization_6723.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Hvordan fragmentering opst\u00e5r<\/h2>\n\n<p>Jeg ser h\u00f8je <strong>Fragmentering<\/strong> is\u00e6r ved mange skrive- og sletningscyklusser. Allokatoren, som oftest <strong>jemalloc<\/strong>, opretter lagringsplads i arenaer, som ikke altid genbruges optimalt. N\u00e5r n\u00f8gler krymper, vokser eller forsvinder helt, efterlades der huller. Nye objekter passer ofte ikke ind i disse huller, hvilket betyder, at RSS forbliver h\u00f8jere end de faktiske data. Ved lange k\u00f8rselstider hober disse sig op <strong>Huller<\/strong>, indtil forholdet stiger markant.<\/p>\n\n<h2>Symptomer og risici i driften<\/h2>\n\n<p>Stigende <strong>Forsinkelse<\/strong>, pludselige OOM-fejl og stigende RSS er det f\u00f8rste, der falder mig i \u00f8jnene. Selv om used_memory forbliver moderat, kan instansen <strong>RAM<\/strong>-st\u00f8der p\u00e5 gr\u00e6nser. N\u00e5r systemet derefter flytter sider ud, skyder svartiderne i vejret. Tjenesterne reagerer tr\u00e6gt, og antallet af timeouts stiger, hvilket forstyrrer applikationernes drift. Derfor holder jeg altid ogs\u00e5 \u00f8je med <strong>Bytte<\/strong>-Metrikkerne i fokus.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/redis-memory-optimization-8486.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>L\u00e6s INFO MEMORY sikkert<\/h2>\n\n<p>Omkring <strong>INFO<\/strong> Hvad ang\u00e5r hukommelsen, tjekker jeg used_memory, used_memory_rss og mem_fragmentation_ratio. Derudover holder jeg \u00f8je med <strong>allocator_frag_ratio<\/strong> og allocator_rss_ratio for at identificere forskelle mellem heap og operativsystemet. En h\u00f8j mem_fragmentation_ratio ved en normal allokatorv\u00e6rdi viser mig, at operativsystemet ikke genvinder siderne ordentligt. H\u00f8je allokatorv\u00e6rdier tyder derimod p\u00e5 interne <strong>Dynge<\/strong>-fragmentering. Jeg dokumenterer kombinationerne, s\u00e5 tendenser bliver synlige, og foranstaltningerne kan m\u00e5lrettet sl\u00e5 igennem.<\/p>\n\n<h2>Aktiv defragmentering i praksis<\/h2>\n\n<p>Jeg aktiverer <strong>Aktiv<\/strong> Defragmentering, n\u00e5r belastningsforholdet stiger, eller arbejdsbelastningen svinger kraftigt. Her omorganiserer Redis objekterne og samler dem t\u00e6ttere, s\u00e5 operativsystemet kan frig\u00f8re hukommelse. Jeg tester styringen trin for trin for at holde CPU-belastningen inden for rimelige gr\u00e6nser. Til at begynde med bruger jeg gennempr\u00f8vede indstillinger og finjusterer dem derefter. Denne kilde giver mig en god introduktion <a href=\"https:\/\/webhosting.de\/da\/redis-aktiv-defragmentering-reducere-hukommelsesfragmentering-optimeret-heap\/\">Aktiv defragmentering<\/a>-Artikel.<\/p>\n\n<pre><code>CONFIG SET activedefrag yes\nCONFIG SET active-defrag-ignore-bytes 100mb\nCONFIG SET active-defrag-threshold-lower 10\nCONFIG SET active-defrag-threshold-upper 100\nCONFIG SET active-defrag-cycle-min 5\nCONFIG SET active-defrag-cycle-max 75\n<\/code><\/pre>\n\n<p>Jeg s\u00e6tter <strong>Gr\u00e6nsev\u00e6rdier<\/strong> s\u00e5ledes at defragmenteringen tr\u00e6der i kraft, n\u00e5r det virkelig er n\u00f8dvendigt. Cycle-v\u00e6rdierne begr\u00e6nser CPU-budgettet, s\u00e5 spidsbelastninger ikke p\u00e5virkes negativt. Efter justeringerne overv\u00e5ger jeg m\u00e5lingerne i flere timer. F\u00f8rst n\u00e5r ratio, latenstid og CPU ser fornuftige ud, overf\u00f8rer jeg <strong>V\u00e6rdier<\/strong> permanent.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/redis_optimierung_3021.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Finjustering af parametre uden bivirkninger<\/h2>\n\n<p>Jeg forh\u00f8jer <strong>T\u00e6rskelv\u00e6rdier<\/strong> kun i sm\u00e5 skridt for at undg\u00e5 bivirkninger. En for aggressiv cyklus mindsker ganske vist fragmenteringen, men belaster <strong>CPU<\/strong> m\u00e6rkbart. N\u00e5r der er travlt om dagen, udskyder jeg testene til roligere tidspunkter, s\u00e5 effekterne forbliver let m\u00e5lbare. Det er nyttigt at foretage en sammenligning f\u00f8r og efter justeringen med identisk <strong>Arbejdsbyrde<\/strong>. S\u00e5dan kan jeg se, om Defrag virkelig s\u00e6nker forholdet, eller om det blot flytter belastningen.<\/p>\n\n<h2>Brug Lazy Free bevidst<\/h2>\n\n<p>Jeg bruger <strong>Lazy Free<\/strong>, n\u00e5r mange store n\u00f8gler forsvinder eller omd\u00f8bes p\u00e5 \u00e9n gang. I stedet for at blokere synkroniseringen, giver <em>UNLINK<\/em>, <em>FLUSHDB ASYNC<\/em> og <em>FLUSHALL ASYNC<\/em> Frig\u00f8r hukommelse i baggrunden. Dette mindsker spidsbelastninger i latenstiden, men kan p\u00e5 kort sigt \u00f8ge fragmenteringen, da sider f\u00f8rst genbruges asynkront. Jeg styrer denne adf\u00e6rd via lazyfree-parametre (f.eks. lazyfree-lazy-eviction, lazyfree-lazy-server-del), tester virkningerne p\u00e5 CPU'en og overv\u00e5ger <strong>lazyfree_pending_objects<\/strong> i INFO-hukommelsen. Hvis der er mange udest\u00e5ende objekter, \u00f8ger jeg defragmenteringsbudgettet en smule eller spreder sletningsb\u00f8lgerne, s\u00e5 heap\u2019en ikke bliver opsplittet i mange sm\u00e5 huller.<\/p>\n\n<h2>Planl\u00e6g manuel oprydning og genstart<\/h2>\n\n<p>Hvis Ratio eksploderer, sl\u00e5r jeg h\u00e5rdt til <strong>H\u00e5ndtag<\/strong>. Med MEMORY PURGE beder jeg allokatoren om at returnere ubrugte sider til operativsystemet. Med DEBUG MALLOC-STATS f\u00e5r jeg et mere detaljeret indblik i <strong>Arenaer<\/strong> og m\u00f8nstre for tildelingerne. Hvis forholdstallet forbliver over 2,0, planl\u00e6gger jeg en koordineret genstart efter et snapshot eller en AOF-synkronisering. Dette trin foruds\u00e6tter, at <strong>Lagringsstruktur<\/strong> tilbage og henter straks RSS.<\/p>\n\n<h2>Planl\u00e6g Maxmemory klogt<\/h2>\n\n<p>Jeg planl\u00e6gger <strong>maksimal hukommelse<\/strong> aldrig helt op til den fysiske RAM-gr\u00e6nse. Som tommelfingerregel reserverer jeg ca. 60\u201365 % til data, 5\u201310 % som fragmenteringsbuffer og 10\u201320 % til <strong>Copy-on-Write<\/strong>. Resten g\u00e5r til operativsystemet, agenterne og driften. Denne fordeling forhindrer <strong>OOM<\/strong>-Overraskelser og giver Defrag mere plads. Her finder jeg en praktisk vejledning: <a href=\"https:\/\/webhosting.de\/da\/redis-hukommelsesstyring-optimal-konfiguration-af-hukommelse-ydeevne-og-cache\/\">Konfigurer lageret optimalt<\/a>.<\/p>\n\n<h2>Persistens, RDB\/AOF og Copy-on-Write<\/h2>\n\n<p>Jeg tager altid h\u00f8jde for virkningerne af <strong>Vedholdenhed<\/strong> p\u00e5 fragmenteringen. Ved BGSAVE og AOF-rewrites duplikerer Copy-on-Write \u00e6ndrede sider. I denne fase stiger RSS, selvom used_memory n\u00e6sten ikke vokser. Jeg planl\u00e6gger derfor omfattende rewrites i perioder med lav belastning og kontrollerer <em>auto-aof-rewrite-procent<\/em> og <em>-min-st\u00f8rrelse<\/em> og s\u00f8rg for, at der er headroom til CoW. Aggressive skrivespidser under en omskrivning kan hurtigt f\u00e5 arenaerne til at blive fragmenterede; en efterf\u00f8lgende defragmentering tr\u00e6kker RSS tilbage. P\u00e5 replikaer holder jeg s\u00e6rligt \u00f8je med den f\u00f8rste fulde resynkronisering: store masseimport plus CoW er en klassisk \u00e5rsag til kortvarige h\u00f8je <strong>mem_fragmentering_ratio<\/strong>. Hvis v\u00e6rdien forbliver forh\u00f8jet efter afslutningen, k\u00f8rer jeg et kort defragmenteringsforl\u00f8b eller tester <em>MEMORY PURGE<\/em>.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/redis_optimierung_desktop_4253.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Under 1,0: Swap er den st\u00f8rste hindring<\/h2>\n\n<p>Hvis forholdstallet falder til under 1,0, bremser <strong>Bytte<\/strong> systemet. Hver page-fault-runde tager m\u00e6rkbart lang tid og \u00f8del\u00e6gger latenstidsm\u00e5lene. Jeg tjekker derefter RAM-tilstanden og s\u00e6nker <strong>maksimal hukommelse<\/strong> eller reducer m\u00e6ngden af data i instansen. Derudover kontrollerer jeg systemparametre som vm.swappiness, s\u00e5 kernen sj\u00e6ldnere <strong>outsourcer<\/strong>. M\u00e5let er fortsat at holde processen udelukkende i RAM og undg\u00e5 sideindl\u00e6sninger.<\/p>\n\n<h2>Medregne container- og kernelindstillinger<\/h2>\n\n<p>I containere m\u00e5ler jeg altid fragmentering i sammenh\u00e6ng med <strong>cgroups<\/strong>-gr\u00e6nser. Jeg sammenligner RSS med hukommelsesgr\u00e6nserne og indstiller <em>vm.overcommit_memory=1<\/em>, s\u00e5 Redis ikke g\u00e5r ned p\u00e5 grund af overcommit. <strong>Gennemsigtige store sider<\/strong> Jeg deaktiverer dem, fordi de fylder for meget i RSS-feeds og g\u00f8r defragmentering vanskeligere. Desuden har jeg bem\u00e6rket, at <em>oom_kill<\/em>-t\u00e6ller for cgroupen og reagerer tidligt, n\u00e5r kernen begynder at l\u00e6gge pres p\u00e5. I Kubernetes s\u00f8rger jeg for realistiske anmodninger\/gr\u00e6nser og reserverer headroom pr. pod, s\u00e5 BGSAVE og Rewrites ikke utilsigtet kommer til at k\u00f8re helt til gr\u00e6nsen. Vigtigt: Containerisolering \u00e6ndrer ikke p\u00e5 den interne heap-logik \u2013 defragmentering, Lazy Free og modelvedligeholdelse forbliver de centrale v\u00e6rkt\u00f8jer mod <strong>Fragmentering<\/strong>.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/redis-optimierung-4931.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Optimering af datamodel og n\u00f8gletal<\/h2>\n\n<p>Jeg holder <strong>Objekter<\/strong> sm\u00e5 og ensartede, s\u00e5 allokatoren spreder dem mindre. Meget store lister, s\u00e6t eller hash-tabeller opdeler jeg i flere mindre n\u00f8gler. I stedet for enorme JSON-strenge bruger jeg kompakte <strong>Datatyper<\/strong> som f.eks. hashes med felter, der skifter sj\u00e6ldnere. For sessioner, t\u00e6llere og cacher standardiserer jeg st\u00f8rrelserne, s\u00e5 allokeringerne forbliver mere forudsigelige. P\u00e5 den m\u00e5de reducerer jeg <strong>Fragmentering<\/strong>, f\u00f8r jeg begynder at justere indstillingerne.<\/p>\n\n<h2>Udsmidningspolitik og adf\u00e6rd i forbindelse med udsmidning<\/h2>\n\n<p>Jeg v\u00e6lger <strong>Udvisningspolitik<\/strong> tilpasset arbejdsbelastningen. Ved st\u00e6rkt svingende n\u00f8glem\u00e6ngder fordeler LRU\/LFU-varianter sletningerne mere j\u00e6vnt og undg\u00e5r spidsbelastninger. Jeg undg\u00e5r masseudl\u00f8b p\u00e5 hele timetidspunkter og spreder TTL\u2019erne, s\u00e5 Active-Expire ikke fjerner tusindvis af objekter p\u00e5 \u00e9n gang. Parametre som <em>hz<\/em> og <em>active-expire-effort<\/em> Jeg justerer kun forsigtigt for ikke at overbelaste CPU\u2019en. Et j\u00e6vnt forl\u00f8b giver forudsigelige allokeringer \u2013 og det er netop det, der holder <strong>mem_fragmentering_ratio<\/strong> flad.<\/p>\n\n<h2>Redis-klynger og sharding<\/h2>\n\n<p>N\u00e5r det g\u00e6lder v\u00e6kst, satser jeg p\u00e5 <strong>Opdeling<\/strong> eller klynger, fordi mindre heaps pr. shard skaber f\u00e6rre langvarige huller. Ved rebalancing planl\u00e6gger jeg migrationsvinduerne, s\u00e5 skrivetoppe og omskrivninger ikke kolliderer. Store MIGRATE-b\u00f8lger kan midlertidigt \u00f8ge RSS p\u00e5 m\u00e5lknudepunkter; jeg overv\u00e5ger allokatorv\u00e6rdierne undervejs og aktiverer defragmentering efter flytningen. P\u00e5 replikater tager jeg h\u00f8jde for ekstra hukommelse til backlogs og replikabuffere \u2013 ogs\u00e5 det indg\u00e5r i <strong>Maxmemory<\/strong>-budgettering.<\/p>\n\n<h2>Dybere indsigt i observabilitet: MEMORY STATS og latenstid<\/h2>\n\n<ul>\n  <li>Jeg bruger <strong>HUKOMMELSESSTATISTIK<\/strong>, for at se overhead, datas\u00e6tandel og fragmenteringsdetaljer. Det hj\u00e6lper med at skelne mellem heap-fragmentering og fragmentering for\u00e5rsaget af operativsystemet.<\/li>\n  <li>Med <strong>MEMORY DOCTOR<\/strong> f\u00e5r jeg anbefalinger om, hvorvidt datamodellen, defragmentering eller rensning giver det bedste resultat p\u00e5 kort sigt.<\/li>\n  <li>Jeg korrelerer <strong>latens<\/strong>-Metrikker (f.eks. latency doctor) med defragmenteringsfaser og omskrivninger for at identificere bivirkninger.<\/li>\n  <li>Der <strong>SLOWLOG<\/strong> viser mig, om kommandoer kommer ud af takt p\u00e5 grund af hukommelsesoperationer \u2013 is\u00e6r DEL-, UNLINK- og store HSET\/HGET-serier.<\/li>\n<\/ul>\n\n<h2>Praktisk vejledning til driften<\/h2>\n\n<ul>\n  <li>Udgangspunkt: Sikre INFO-hukommelse, dokumentere ratio, allokatorv\u00e6rdier samt datas\u00e6t\/overhead.<\/li>\n  <li>Budget: Indstil maxmemory til et realistisk niveau p\u00e5 60\u201365 % data, 5\u201310 % fragmentering og 10\u201320 % CoW.<\/li>\n  <li>Defrag: Aktiver \u00bbactivedefrag\u00ab, \u00f8g v\u00e6rdien gradvist, og m\u00e5l effekten over flere timer.<\/li>\n  <li>Datamodel: Opdel store objekter, undg\u00e5 JSON-blokke, standardiser st\u00f8rrelserne.<\/li>\n  <li>Udl\u00f8b: Spred TTL-v\u00e6rdierne, v\u00e6lg en passende eviction-politik, undg\u00e5 sletningsb\u00f8lger.<\/li>\n  <li>Persistens: Planl\u00e6g omskrivninger, s\u00f8rg for ledig plads, kontroller defragmenteringen efter afslutning.<\/li>\n  <li>Rensning\/genstart: Hvis forholdet er &gt; 2,0, skal der fors\u00f8ges en rensning; ellers skal der foretages en ordnet genstart.<\/li>\n  <li>Container: THP sl\u00e5et fra, Overcommit sl\u00e5et til, gr\u00e6nser\/anmodninger med headroom; swap skal begr\u00e6nses strengt.<\/li>\n  <li>Overv\u00e5gning: Advarsler ved 1,5\/2,0\/under 1,0; analysere tendenser efter implementeringer og batcher.<\/li>\n<\/ul>\n\n<h2>Eksempel: Fra 1,8 til 1,2 p\u00e5 24 timer<\/h2>\n\n<p>I en 64 GB-instans (maxmemory 40 GB) steg <strong>mem_fragmentering_ratio<\/strong> til 1,8, selvom used_memory l\u00e5 p\u00e5 28\u201330 GB. F\u00f8rst <em>aktivere defragmentering<\/em> aktiveret (cycle-min 5, cycle-max 50) og flyttet tidspunktet for den natlige AOF-omskrivning til et roligere tidsrum. Derefter justerede jeg TTL'er, der hidtil udl\u00f8b hver time, og erstattede flere enorme JSON-v\u00e6rdier med hashes med faste feltst\u00f8rrelser. En m\u00e5lrettet <em>MEMORY PURGE<\/em> Efter spidsbelastningen frigav RSS yderligere hukommelse. Resultat: Efter 24 timer faldt forholdstallet stabilt til ~1,2, forsinkelsestoppene forsvandt, og v\u00e6rts-RAM\u2019en fik ~8 GB mere plads. Den <strong>Allocator<\/strong>-V\u00e6rdier bekr\u00e6ftet: mindre fragmentering af heap\u2019en, OS-RSS i balance.<\/p>\n\n<h2>S\u00e5dan sammenligner du hostingmilj\u00f8er p\u00e5 en fornuftig m\u00e5de<\/h2>\n\n<p>Jeg s\u00f8rger for, at der er nok <strong>RAM<\/strong>, forudsigelige CPU- og konsistente IO-v\u00e6rdier, n\u00e5r jeg placerer Redis hos hostingudbyderen. Dedikerede ressourcer og fleksible opgraderinger forhindrer flaskehalse i forbindelse med v\u00e6kst. Det er fornuftigt at have klare m\u00e5lepunkter for RSS, <strong>Bytte<\/strong> og begr\u00e6nsninger, s\u00e5 jeg kan opdage flaskehalse i god tid. Til tyske ops\u00e6tninger anbefaler jeg webhoster.de, fordi ressourcerne der er p\u00e5lidelige. En velfungerende platform sikrer, at <strong>Fragmentering<\/strong>-v\u00e6rdien inden for det normale interval.<\/p>\n\n<h2>Sammenfatning<\/h2>\n\n<p>Jeg l\u00e6ser <strong>Redis<\/strong> Hukommelsesfragmenteringsgrad som et tidligt advarselssignal for tab af RAM og latenstid. V\u00e6rdier t\u00e6t p\u00e5 1,0 er normale; fra 1,5 iv\u00e6rks\u00e6tter jeg defragmentering og modeljusteringer, og under 1,0 stopper jeg <strong>Bytte<\/strong> med det samme. Med aktiv defragmentering, intelligent Maxmemory-budgettering og kompakte datastrukturer holder jeg <strong>Hukommelse<\/strong>-effektiviteten er h\u00f8j. Kontinuerlig overv\u00e5gning afsl\u00f8rer m\u00f8nstre og forhindrer hektiske ad hoc-tiltag. P\u00e5 den m\u00e5de forbliver instansen reaktionsdygtig, og den <strong>Forhold<\/strong> bev\u00e6ger sig der, hvor han h\u00f8rer til.<\/p>","protected":false},"excerpt":{"rendered":"<p>L\u00e6r, hvordan du korrekt fortolker Redis-hukommelsesfragmenteringsgraden, genkender normale og kritiske niveauer og ved hj\u00e6lp af m\u00e5lrettet Redis-optimering holder din Redis-hukommelse effektiv og stabil.<\/p>","protected":false},"author":1,"featured_media":21284,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[781],"tags":[],"class_list":["post-21291","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-datenbanken-administration-anleitungen"],"acf":[],"_wp_attached_file":null,"_wp_attachment_metadata":null,"litespeed-optimize-size":null,"litespeed-optimize-set":null,"_elementor_source_image_hash":null,"_wp_attachment_image_alt":null,"stockpack_author_name":null,"stockpack_author_url":null,"stockpack_provider":null,"stockpack_image_url":null,"stockpack_license":null,"stockpack_license_url":null,"stockpack_modification":null,"color":null,"original_id":null,"original_url":null,"original_link":null,"unsplash_location":null,"unsplash_sponsor":null,"unsplash_exif":null,"unsplash_attachment_metadata":null,"_elementor_is_screenshot":null,"surfer_file_name":null,"surfer_file_original_url":null,"envato_tk_source_kit":null,"envato_tk_source_index":null,"envato_tk_manifest":null,"envato_tk_folder_name":null,"envato_tk_builder":null,"envato_elements_download_event":null,"_menu_item_type":null,"_menu_item_menu_item_parent":null,"_menu_item_object_id":null,"_menu_item_object":null,"_menu_item_target":null,"_menu_item_classes":null,"_menu_item_xfn":null,"_menu_item_url":null,"_trp_menu_languages":null,"rank_math_primary_category":null,"rank_math_title":null,"inline_featured_image":null,"_yoast_wpseo_primary_category":null,"rank_math_schema_blogposting":null,"rank_math_schema_videoobject":null,"_oembed_049c719bc4a9f89deaead66a7da9fddc":null,"_oembed_time_049c719bc4a9f89deaead66a7da9fddc":null,"_yoast_wpseo_focuskw":null,"_yoast_wpseo_linkdex":null,"_oembed_27e3473bf8bec795fbeb3a9d38489348":null,"_oembed_c3b0f6959478faf92a1f343d8f96b19e":null,"_trp_translated_slug_en_us":null,"_wp_desired_post_slug":null,"_yoast_wpseo_title":null,"tldname":null,"tldpreis":null,"tldrubrik":null,"tldpolicylink":null,"tldsize":null,"tldregistrierungsdauer":null,"tldtransfer":null,"tldwhoisprivacy":null,"tldregistrarchange":null,"tldregistrantchange":null,"tldwhoisupdate":null,"tldnameserverupdate":null,"tlddeletesofort":null,"tlddeleteexpire":null,"tldumlaute":null,"tldrestore":null,"tldsubcategory":null,"tldbildname":null,"tldbildurl":null,"tldclean":null,"tldcategory":null,"tldpolicy":null,"tldbesonderheiten":null,"tld_bedeutung":null,"_oembed_d167040d816d8f94c072940c8009f5f8":null,"_oembed_b0a0fa59ef14f8870da2c63f2027d064":null,"_oembed_4792fa4dfb2a8f09ab950a73b7f313ba":null,"_oembed_33ceb1fe54a8ab775d9410abf699878d":null,"_oembed_fd7014d14d919b45ec004937c0db9335":null,"_oembed_21a029d076783ec3e8042698c351bd7e":null,"_oembed_be5ea8a0c7b18e658f08cc571a909452":null,"_oembed_a9ca7a298b19f9b48ec5914e010294d2":null,"_oembed_f8db6b27d08a2bb1f920e7647808899a":null,"_oembed_168ebde5096e77d8a89326519af9e022":null,"_oembed_cdb76f1b345b42743edfe25481b6f98f":null,"_oembed_87b0613611ae54e86e8864265404b0a1":null,"_oembed_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_oembed_time_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_tldname":null,"_tldclean":null,"_tldpreis":null,"_tldcategory":null,"_tldsubcategory":null,"_tldpolicy":null,"_tldpolicylink":null,"_tldsize":null,"_tldregistrierungsdauer":null,"_tldtransfer":null,"_tldwhoisprivacy":null,"_tldregistrarchange":null,"_tldregistrantchange":null,"_tldwhoisupdate":null,"_tldnameserverupdate":null,"_tlddeletesofort":null,"_tlddeleteexpire":null,"_tldumlaute":null,"_tldrestore":null,"_tldbildname":null,"_tldbildurl":null,"_tld_bedeutung":null,"_tldbesonderheiten":null,"_oembed_ad96e4112edb9f8ffa35731d4098bc6b":null,"_oembed_8357e2b8a2575c74ed5978f262a10126":null,"_oembed_3d5fea5103dd0d22ec5d6a33eff7f863":null,"_eael_widget_elements":null,"_oembed_0d8a206f09633e3d62b95a15a4dd0487":null,"_oembed_time_0d8a206f09633e3d62b95a15a4dd0487":null,"_aioseo_description":null,"_eb_attr":null,"_eb_data_table":null,"_oembed_819a879e7da16dd629cfd15a97334c8a":null,"_oembed_time_819a879e7da16dd629cfd15a97334c8a":null,"_acf_changed":null,"_wpcode_auto_insert":null,"_edit_last":null,"_edit_lock":null,"_oembed_e7b913c6c84084ed9702cb4feb012ddd":null,"_oembed_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_time_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_03514b67990db061d7c4672de26dc514":null,"_oembed_time_03514b67990db061d7c4672de26dc514":null,"rank_math_news_sitemap_robots":null,"rank_math_robots":null,"_eael_post_view_count":"48","_trp_automatically_translated_slug_ru_ru":null,"_trp_automatically_translated_slug_et":null,"_trp_automatically_translated_slug_lv":null,"_trp_automatically_translated_slug_fr_fr":null,"_trp_automatically_translated_slug_en_us":null,"_wp_old_slug":null,"_trp_automatically_translated_slug_da_dk":null,"_trp_automatically_translated_slug_pl_pl":null,"_trp_automatically_translated_slug_es_es":null,"_trp_automatically_translated_slug_hu_hu":null,"_trp_automatically_translated_slug_fi":null,"_trp_automatically_translated_slug_ja":null,"_trp_automatically_translated_slug_lt_lt":null,"_elementor_edit_mode":null,"_elementor_template_type":null,"_elementor_version":null,"_elementor_pro_version":null,"_wp_page_template":null,"_elementor_page_settings":null,"_elementor_data":null,"_elementor_css":null,"_elementor_conditions":null,"_happyaddons_elements_cache":null,"_oembed_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_time_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_time_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_59808117857ddf57e478a31d79f76e4d":null,"_oembed_time_59808117857ddf57e478a31d79f76e4d":null,"_oembed_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_time_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_81002f7ee3604f645db4ebcfd1912acf":null,"_oembed_time_81002f7ee3604f645db4ebcfd1912acf":null,"_elementor_screenshot":null,"_oembed_7ea3429961cf98fa85da9747683af827":null,"_oembed_time_7ea3429961cf98fa85da9747683af827":null,"_elementor_controls_usage":null,"_elementor_page_assets":[],"_elementor_screenshot_failed":null,"theplus_transient_widgets":null,"_eael_custom_js":null,"_wp_old_date":null,"_trp_automatically_translated_slug_it_it":null,"_trp_automatically_translated_slug_pt_pt":null,"_trp_automatically_translated_slug_zh_cn":null,"_trp_automatically_translated_slug_nl_nl":null,"_trp_automatically_translated_slug_pt_br":null,"_trp_automatically_translated_slug_sv_se":null,"rank_math_analytic_object_id":null,"rank_math_internal_links_processed":"1","_trp_automatically_translated_slug_ro_ro":null,"_trp_automatically_translated_slug_sk_sk":null,"_trp_automatically_translated_slug_bg_bg":null,"_trp_automatically_translated_slug_sl_si":null,"litespeed_vpi_list":null,"litespeed_vpi_list_mobile":null,"rank_math_seo_score":null,"rank_math_contentai_score":null,"ilj_limitincominglinks":null,"ilj_maxincominglinks":null,"ilj_limitoutgoinglinks":null,"ilj_maxoutgoinglinks":null,"ilj_limitlinksperparagraph":null,"ilj_linksperparagraph":null,"ilj_blacklistdefinition":null,"ilj_linkdefinition":null,"_eb_reusable_block_ids":null,"rank_math_focus_keyword":"Redis Fragmentation","rank_math_og_content_image":null,"_yoast_wpseo_metadesc":null,"_yoast_wpseo_content_score":null,"_yoast_wpseo_focuskeywords":null,"_yoast_wpseo_keywordsynonyms":null,"_yoast_wpseo_estimated-reading-time-minutes":null,"rank_math_description":null,"surfer_last_post_update":null,"surfer_last_post_update_direction":null,"surfer_keywords":null,"surfer_location":null,"surfer_draft_id":null,"surfer_permalink_hash":null,"surfer_scrape_ready":null,"_thumbnail_id":"21284","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/posts\/21291","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/comments?post=21291"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/posts\/21291\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/media\/21284"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/media?parent=21291"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/categories?post=21291"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/tags?post=21291"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}