{"id":20212,"date":"2026-08-01T08:32:36","date_gmt":"2026-08-01T06:32:36","guid":{"rendered":"https:\/\/webhosting.de\/memory-pressure-linux-kernel-hosting-systeme-optimierung-ram\/"},"modified":"2026-08-01T08:32:36","modified_gmt":"2026-08-01T06:32:36","slug":"hukommelsespres-linux-kernen-hosting-systemer-optimering-ram","status":"publish","type":"post","link":"https:\/\/webhosting.de\/da\/memory-pressure-linux-kernel-hosting-systeme-optimierung-ram\/","title":{"rendered":"Hukommelsespres i Linux-kernen: Konsekvenser for hostingsystemer"},"content":{"rendered":"<p>Hukommelsespres i Linux-kernen rammer hosting-systemer direkte: N\u00e5r presset stiger, flyttes CPU-tid og I\/O over til ressourcekr\u00e6vende <strong>Reclaim<\/strong>, responstiderne stiger, og risikoen for OOM-fejl \u00f8ges. Jeg viser tydeligt, hvordan jeg identificerer, m\u00e5ler og afb\u00f8der hukommelsespres, s\u00e5 <strong>Hosting<\/strong>-Reagere l\u00f8bende p\u00e5 arbejdsbelastninger.<\/p>\n\n<h2>Centrale punkter<\/h2>\n<p>Jeg fokuserer p\u00e5 de afg\u00f8rende faktorer, der i hostingmilj\u00f8er er afg\u00f8rende for ydeevne og nedbrud. De f\u00f8lgende punkter udg\u00f8r den r\u00f8de tr\u00e5d, som jeg baserer min diagnose og optimering p\u00e5. Med dette overblik undg\u00e5r jeg fejlagtige fortolkninger af \u201efuld RAM\u201c og identificerer reelle <strong>Tryk<\/strong> i god tid.<\/p>\n<ul>\n  <li><strong>PSI-m\u00e5linger<\/strong> viser ventetider i stedet for blot bel\u00e6gning og afsl\u00f8rer forsinkelser p\u00e5 et tidligt tidspunkt.<\/li>\n  <li><strong>Swap-belastning<\/strong> indikerer Reclaim-problemer, der forv\u00e6rrer I\/O og latenstider.<\/li>\n  <li><strong>Cgroups-gr\u00e6nser<\/strong> Styring af begr\u00e6nsning, beskyttelse og OOM-adf\u00e6rd pr. tjeneste.<\/li>\n  <li><strong>Cache-fortr\u00e6ngning<\/strong> har en direkte indflydelse p\u00e5 web- og databaseydelsen.<\/li>\n  <li><strong>Planl\u00e6gning af kapacitet<\/strong> og tuning sikrer headroom og forhindrer thrashing.<\/li>\n<\/ul>\n<p>P\u00e5 den m\u00e5de strukturerer jeg mine analyser fra kernen til applikationen og gennemf\u00f8rer passende tiltag i prioriteret r\u00e6kkef\u00f8lge. Fokus forbliver p\u00e5 m\u00e5lbare <strong>Effekter<\/strong>, ikke p\u00e5 arbejde p\u00e5 afbetaling.<\/p>\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\/08\/serverraum-memorydruck-4821.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Hvad betyder \u00bbmemory pressure\u00ab i Linux-kernen?<\/h2>\n\n<p>Memory-Druck betyder, at kernen bruger m\u00e6rkbar tid p\u00e5 at frig\u00f8re hukommelse i stedet for at forts\u00e6tte brugerprocessernes arbejde; CPU\u2019en bruger da i stigende grad tid p\u00e5 scanninger, skrivninger og evictions, mens anmodninger venter. Jeg skelner klart mellem \u201efuld RAM\u201c og \u201emangel p\u00e5 brugbar <strong>Headroom<\/strong>\u201c: En \u201efuld\u201c cache er sund; flaskehalse opst\u00e5r f\u00f8rst, n\u00e5r Reclaim-investeringerne stiger. Kernen scanner inaktive lister og skriver <strong>beskidt<\/strong>-sider, sletter filcachen og flytter anonyme sider ud, s\u00e5 snart vandm\u00e6rkerne overskrides. Det afg\u00f8rende er den tid, der bruges p\u00e5 disse aktiviteter; den afspejles i opgavernes ventetider og forl\u00e6ngede svartider. En host kan k\u00f8re stille ved 95 % %-udnyttelse, s\u00e5 l\u00e6nge cachen let kan genvindes, men kan g\u00e5 i st\u00e5 kraftigt ved lav udnyttelse, hvis aktive anonyme sider skal fortr\u00e6nges.<\/p>\n\n<h2>At forst\u00e5 og m\u00e5le PSI<\/h2>\n\n<p>Pressure Stall Information (PSI) g\u00f8r Memory Pressure h\u00e5ndgribeligt, fordi jeg ikke m\u00e5ler belastningen, men forsinkelserne. I <strong>\/proc\/tryk\/hukommelse<\/strong> Jeg ser \u201esome\u201c og \u201efull\u201c: \u201esome\u201c beskriver perioder, hvor mindst \u00e9n opgave venter p\u00e5 hukommelse, mens \u201efull\u201c angiver perioder, hvor alle opgaver st\u00e5r i k\u00f8. Eksempel: \u201esome avg10=4.67\u201c betyder, at der i de sidste 10 sekunder var 4,67 % af tiden, hvor der opstod afbrydelser p\u00e5 grund af hukommelsesflaskehalse; \u201efull avg10=0.30\u201c indikerer sj\u00e6ldne fuldst\u00e6ndige afbrydelser. Jeg sammenholder stigende \u201esome\u201c-v\u00e6rdier tidligt med responstider og skalerer, finjusterer eller aflaster, inden der opst\u00e5r alvorlige OOM-fejl. Denne tilgang forhindrer mig i at lade mig vildlede af tilsyneladende \u201eh\u00f8j ledig\u201c RAM, da ledige sider uden hurtig <strong>Reclaim<\/strong>-udnytter muligheden kun i begr\u00e6nset omfang.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>M\u00e5lt variabel<\/th>\n      <th>Vejledende v\u00e6rdi<\/th>\n      <th>Symptom<\/th>\n      <th>Handling<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>PSI-hukommelse (nogle) (avg10)<\/td>\n      <td>&gt; 2\u20133 % vedvarende<\/td>\n      <td>Svarstiderne stiger<\/td>\n      <td>Kontroller RAM-headroom, finjuster Cgroup-gr\u00e6nser<\/td>\n    <\/tr>\n    <tr>\n      <td>PSI-hukommelse fuld (avg10)<\/td>\n      <td>&gt; 0,1 % m\u00e6rkbart<\/td>\n      <td>Korte d\u00f8dtider<\/td>\n      <td>Identificer \u00e5rsagen, stop thrashing<\/td>\n    <\/tr>\n    <tr>\n      <td>MemAvailable<\/td>\n      <td>&lt; 10 % af RAM&#039;en<\/td>\n      <td>Lille buffer<\/td>\n      <td>Aflaste cache\/arbejdsbelastning, planl\u00e6gge kapacitet<\/td>\n    <\/tr>\n    <tr>\n      <td>vmstat mandag\/s\u00f8ndag<\/td>\n      <td>konstant &gt; 0<\/td>\n      <td>Swap-tryk<\/td>\n      <td>Tilpas Swappiness\/Swap, beskyt Hotset<\/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\/08\/memorypressurekonferenz3542.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Symptomer i hostingmilj\u00f8er<\/h2>\n\n<p>P\u00e5 travle servere ser jeg f\u00f8rst spidsbelastninger i latenstiden, mens CPU-belastningen tilsyneladende forbliver moderat; kernen k\u00f8rer i \u00bbreclaim\u00ab-sl\u00f8jfer, I\/O hober sig op, og anmodninger st\u00e5r i k\u00f8. Den gennemsnitlige belastning stiger, selvom kernerne ser ud til at v\u00e6re ledige, fordi mange opgaver blokerer p\u00e5 hukommelsen eller I\/O; dette er et tydeligt tegn p\u00e5 \u00f8get <strong>Tryk<\/strong>. Vedvarende si\/so-v\u00e6rdier i vmstat viser, at systemet aktivt udf\u00f8rer swapping, hvilket bremser TLS-h\u00e5ndtryk, dynamisk indhold og foresp\u00f8rgselsstier. Hvis dette ikke l\u00f8ses, g\u00e5r systemet i thrashing: CPU\u2019en bruger st\u00f8rstedelen af tiden p\u00e5 paging og swapping i stedet for at udf\u00f8re nyttigt arbejde. I den eskalerende situation griber OOM-killer ind og afslutter processer med h\u00f8j score; en m\u00e5lrettet <a href=\"https:\/\/webhosting.de\/da\/oom-killer-linux-hukommelse-out-of-memory-analyse-hosting\/\">Analyse af OOM-Killer<\/a> hj\u00e6lper mig med at opdage m\u00f8nstre og fejlkonfigurationer.<\/p>\n\n<h2>Relevans for hosting-workloads og cgroups<\/h2>\n\n<p>I f\u00e6llesdriftede milj\u00f8er er det nok med enkelte ressourcekr\u00e6vende applikationer til at \u00f8ge ventetiderne for mange kunder; cgroups mindsker virkningerne, men de kan ikke redde et system, der er forkert dimensioneret <strong>Forekomster<\/strong>. I VPS- og cloud-instanser f\u00f8rer begr\u00e6nset RAM eller en d\u00e5rlig swap-strategi hurtigere til belastningsspidser; isolering beskytter andre, men ikke ens egen tjeneste. Databaser er afh\u00e6ngige af store bufferpuljer; hvis Reclaim fortr\u00e6nger disse, eller swap tr\u00e6der i kraft, stiger foresp\u00f8rgselstiderne, og genneml\u00f8bshastigheden falder markant. Containerorkestreringer bruger memory.low, memory.high og memory.max til at beskytte vigtige tjenester, d\u00e6mpe fastl\u00e5sninger og i n\u00f8dstilf\u00e6lde afslutte dem m\u00e5lrettet. Jeg v\u00e6lger derfor bevidst gr\u00e6nser og overv\u00e5ger PSI pr. tjeneste for at kunne gribe ind i tide og sikre reserver til kritiske <strong>Arbejdsbyrder<\/strong> skal holdes fri.<\/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\/08\/linux-memory-pressure-hosting-4823.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Overv\u00e5gningsstrategi og m\u00e5leparametre<\/h2>\n\n<p>Jeg tjekker MemAvailable, Buffers og Cached for at f\u00e5 et overblik over, hvor meget hukommelse der kan frig\u00f8res p\u00e5 kort sigt; rene MemFree-v\u00e6rdier kan let v\u00e6re vildledende. Samtidig kigger jeg p\u00e5 vmstat: Vedvarende si\/so-v\u00e6rdier tyder p\u00e5 swap-pres, som s\u00e6tter I\/O i h\u00f8jt gear og \u00f8ger latenstiderne; for baggrundsinformation om <a href=\"https:\/\/webhosting.de\/da\/swap-brug-serverydelse-hosting-optimus\/\">Udnyttelse af swaps<\/a> Jeg bruger gennempr\u00f8vede diagnosem\u00f8nstre. PSI giver mig den manglende brik, fordi \u201esome\u201c og \u201efull\u201c kvantificerer reelle forsinkelser; jeg udl\u00f8ser alarmer ved t\u00e6rskelv\u00e6rdier og skelner mellem belastningsspidser og kroniske flaskehalse. Tidsserier via sar eller observability-stakken synligg\u00f8r m\u00f8nstre og hj\u00e6lper mig med at bekr\u00e6fte resultaterne af finjusteringen. dmesg afsl\u00f8rer OOM-h\u00e6ndelser, der peger p\u00e5 h\u00e5rde gr\u00e6nser eller fejlkonfigurationer; p\u00e5 den m\u00e5de opbygger jeg et sammenh\u00e6ngende billede ud fra kernelperspektivet, I\/O-adf\u00e6rd og <strong>Anvendelse<\/strong>.<\/p>\n\n<h2>Typiske arbejdsbelastninger under pres<\/h2>\n\n<p>Webservere som Nginx eller Apache leverer indhold langsommere, n\u00e5r Reclaim og Swap k\u00f8rer i baggrunden; Keep-Alive-forbindelser forbliver \u00e5bne l\u00e6ngere, hvilket forv\u00e6rrer k\u00f8erne. PHP- og Python-stakke optager RAM gennem framework-caches, JIT-komponenter og sessionsdata; ved fortr\u00e6ngning pendler disse data mellem RAM og lagerplads og forl\u00e6nger svarstiderne markant. Databaser mister hastighed, s\u00e5 snart bufferpuljer krymper, eller dele ender p\u00e5 swap; selv en lille ekstra latenstid pr. I\/O l\u00f8ber op, n\u00e5r der er mange <strong>Foresp\u00f8rgsler<\/strong>. Caching-tjenester som Redis eller Memcached er afh\u00e6ngige af RAM-hit; hvis n\u00f8gleomr\u00e5der ender p\u00e5 swap, forsvinder fordelen, og risikoen for at blive afbrudt under belastning stiger. I alle tilf\u00e6lde giver PSI- og swap-metrikker de tydeligste tegn p\u00e5, at hukommelsen er blevet en flaskehals, og ikke <strong>CPU<\/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\/08\/linux_kernel_memory_pressure_4092.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Systemoptimering og kerneparametre<\/h2>\n\n<p>Jeg starter med vm.swappiness: En moderat reduceret indstilling forhindrer overdreven brug af swap uden at blokere n\u00f8dvendig genvinding af plads; jeg m\u00e5ler konsekvent effekterne med PSI. Derefter optimerer jeg vm.dirty_ratio og relaterede gr\u00e6nsev\u00e6rdier, s\u00e5 jeg ikke udl\u00f8ser lange flush-b\u00f8lger og alligevel ikke fremprovokerer en voldsom skrivning af sm\u00e5 data; begge dele har m\u00e6rkbare <strong>Effekter<\/strong> p\u00e5 ventetider. I Cgroups v2 indstiller jeg memory.low til kritiske tjenester, memory.high til begr\u00e6nsning ved overbelastning og memory.max som en fast gr\u00e6nse med kontrollerbare OOM-tilstande. Jeg er s\u00e6rlig opm\u00e6rksom p\u00e5 NUMA-topologier: Der kan opst\u00e5 lokal belastning, selvom der globalt set stadig er ledig RAM; proces- og hukommelsesbinding afb\u00f8der s\u00e5danne faldgruber. Til sidst tjekker jeg sidecache-adf\u00e6rd; un\u00f8dvendig fortr\u00e6ngning s\u00e6nker hit-raterne og koster direkte tid ved web- og DB-arbejdsbelastninger, hvorved <a href=\"https:\/\/webhosting.de\/da\/server-page-cache-eviction-linux-memory-print-optimisation-insight\/\">Optimering af sidecachen<\/a> giver nyttige indsigter.<\/p>\n\n<h2>Et indg\u00e5ende kig p\u00e5 Reclaim-stier<\/h2>\n<p>For at kunne v\u00e6lge de rette foranstaltninger skelner jeg mellem <strong>kswapd<\/strong> og <strong>Direkte genvinding<\/strong>. kswapd fungerer asynkront, n\u00e5r vandm\u00e6rkerne underskrides; den er relativt sk\u00e5nsom, s\u00e5 l\u00e6nge der findes tilstr\u00e6kkelig cache, der let kan genvindes. Direct Reclaim griber synkront ind i eksekveringskontekster, n\u00e5r tr\u00e5de har akut brug for sider \u2013 det er her, de forsinkelser opst\u00e5r, som brugerne kan m\u00e6rke. Jeg observerer, om frig\u00f8relsen prim\u00e6rt rammer filcache eller anonyme sider: Hvis kernen prim\u00e6rt fortr\u00e6nger filcache, stiger antallet af cache-misses; hvis den fortr\u00e6nger anonym hukommelse (f.eks. heap), er der risiko for h\u00e5rde stop og swap-aktivitet. Moderne working-set-mekanismer tager h\u00f8jde for refault-afstande for at beholde nyttige sider l\u00e6ngere; hvis jeg alligevel ser mange gentagne refaults, ved jeg, at hotsets er st\u00f8rre end den tilg\u00e6ngelige <strong>Headroom<\/strong> er blevet.<\/p>\n<p>Derudover tager jeg h\u00f8jde for komprimering og defragmentering: <strong>kcompactd<\/strong> fors\u00f8ger at skabe sammenh\u00e6ngende omr\u00e5der, f.eks. til store tildelinger eller <strong>THP<\/strong>. Hvis komprimeringen halter bagefter, ser jeg \u00f8get CPU-udnyttelse i kcompactd, stigende ventetider og \u00f8get andel af \u201efuld\u201c PSI ved belastningstoppe. I s\u00e5danne tilf\u00e6lde er det ofte mere fornuftigt at s\u00e6nke trykket eller justere THP-politikkerne i stedet for blot at give \u201emere swap\u201c.<\/p>\n\n<h2>Swap-strategier i detaljer<\/h2>\n<p>Swap er ikke en fjende, men et v\u00e6rkt\u00f8j \u2013 men hvis det bruges forkert, kan det forv\u00e6rre ventetiden. Jeg skelner mellem:<\/p>\n<ul>\n  <li><strong>Ingen swap<\/strong>: Sikker mod swap-forsinkelser, men risikabel ved spidsbelastninger \u2013 OOM-fejl opst\u00e5r tidligere, og Reclaim har ingen reservebuffer.<\/li>\n  <li><strong>Moderat swap<\/strong> p\u00e5 en hurtig SSD: Godt til at flytte sj\u00e6ldent anvendte, anonyme sider til swap; beskytter hotsets i RAM, hvis swappiness og cgroup-gr\u00e6nser er indstillet fornuftigt.<\/li>\n  <li><strong>zswap\/zram<\/strong>: Komprimering aflaster I\/O; egnet til v\u00e6rter med lavere I\/O-belastning eller som buffer mod kortvarige belastningsspidser. Jeg tjekker CPU-kapaciteten og komprimeringsgraden for at undg\u00e5, at systemet bliver bremset af CPU\u2019en.<\/li>\n<\/ul>\n<p>Jeg indstiller ikke swappiness til et generelt lavt niveau; ved arbejdsbelastninger med en stor filcache er det fornuftigt at have en lidt h\u00f8jere swappiness for at skubbe kolde, anonyme sider v\u00e6k og holde filcachen stabil. Kritiske tjenester (f.eks. databaser) beskytter jeg med `memory.low` og om n\u00f8dvendigt ved at l\u00e5se deres hotsets i RAM, s\u00e5 swap ikke rammer de forkerte omr\u00e5der. Det afg\u00f8rende er, at <strong>vmstat mandag\/s\u00f8ndag<\/strong> og PSI falder konsekvent, n\u00e5r jeg justerer strategien; ellers foretager jeg en korrektion.<\/p>\n\n<h2>THP, komprimering og fragmentering<\/h2>\n<p><strong>Gennemsigtige store sider (THP)<\/strong> De sparer TLB-hits og hj\u00e6lper CPU-tunge, hukommelseskr\u00e6vende applikationer. Under belastning medf\u00f8rer de dog komprimeringsarbejde; \u201ealways\u201c kan i s\u00e5 fald f\u00f8re til store afbrydelser. Jeg bruger \u201emadvise\u201c m\u00e5lrettet til arbejdsbelastninger, der drager fordel heraf (f.eks. visse in-memory-motorer), og for latenstf\u00f8lsomme web-stacks foretr\u00e6kker jeg at deaktivere THP m\u00e5lrettet eller kun aktivere det via madvise. Derudover observerer jeg <strong>vm.compaction_proactiveness<\/strong> og unders\u00f8g, om proaktiv komprimering blot udskyder stalden eller rent faktisk reducerer den. Hvis THP-siderne ofte bliver sk\u00e5ret i stykker, eller hvis komprimeringen k\u00f8rer for varmt, tyder det p\u00e5, at der er for lidt <strong>Headroom<\/strong> eller uhensigtsm\u00e6ssige fordelingsm\u00f8nstre i applikationen.<\/p>\n\n<h2>NUMA-f\u00e6lder og lokal belastning<\/h2>\n<p>P\u00e5 NUMA-v\u00e6rter er den globale \u201eledige RAM\u201c vildledende: Et socket kan v\u00e6re under pres, mens et andet forbliver uudnyttet. Jeg tjekker NUMA-statistikker og forankrer processer lokalt (CPU-\/hukommelsesbinding), s\u00e5 hotsets forbliver t\u00e6t p\u00e5 regnebelastningen. Direct Reclaim p\u00e5 en node p\u00e5 trods af globale reserver indikerer NUMA-ubalancer; her hj\u00e6lper interleaved-allokeringer til bredt spredte tjenester eller streng binding til monolitiske arbejdsbelastninger. PSI pr. cgroup kombineret med NUMA-statistikker viser mig, om en enkelt node genererer k\u00f8erne.<\/p>\n\n<h2>Foranstaltninger t\u00e6t p\u00e5 anvendelsen<\/h2>\n\n<p>Jeg analyserer hukommelsesprofiler med ps, top, htop og profileringsv\u00e6rkt\u00f8jer for at finde de virkelige hukommelsesslugere og l\u00e6kager; i den forbindelse holder jeg \u00f8je med, hvordan hotsets \u00e6ndrer sig over tid. Jeg v\u00e6lger applikationscacher bevidst: Er de for store, skaber det pres; er de for sm\u00e5, g\u00e5r hastighed tabt; jeg justerer med udgangspunkt i PSI og responstider, ikke p\u00e5 mavefornemmelse. N\u00e5r der opfanges belastningssignaler, kan applikationen frivilligt frigive mindre kritiske cacher eller midlertidige data; p\u00e5 den m\u00e5de reducerer jeg afbrydelser uden at r\u00f8re ved globale gr\u00e6nser. Jeg tilpasser startparametre og GC-tuning (f.eks. for JVM\u2019er) s\u00e5ledes, at working sets holdes p\u00e6nt inden for RAM\u2019en; aggressive allokeringsm\u00f8nstre afb\u00f8der jeg ved hj\u00e6lp af batching. Jeg holder ogs\u00e5 \u00f8je med build-artefakter og debug-symboler, for oversete rester koster skjulte omkostninger <strong>Hukommelse<\/strong> og \u00f8ger risikoen for senere stall.<\/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\/08\/MemoryPressureLinuxKernel1234.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Cgroups v2-finesser og OOM-strategier<\/h2>\n<p>Med Cgroups v2 adskiller jeg beskyttelse, begr\u00e6nsning og h\u00e5rde gr\u00e6nser tydeligt: <strong>hukommelse.lav<\/strong> reserverer headroom til kritiske tjenester; den \u00f8vrige Reclaim tildeles mindre vigtige grupper. <strong>hukommelse.h\u00f8j<\/strong> begr\u00e6nser ydeevnen ved overskridelse gennem m\u00e5lrettet begr\u00e6nsning og tvinger applikationer til at frigive hukommelse, f\u00f8r systemet p\u00e5virkes negativt. <strong>hukommelse.max<\/strong> er den sidste forsvarslinje \u2013 overskrides den, betyder det OOM inden for de fastlagte rammer. Jeg indstiller <strong>PSI<\/strong> pr. cgroup, s\u00e5 alarmer udl\u00f8ses d\u00e9r, hvor der opst\u00e5r fastl\u00e5sninger; den globale PSI forbliver stabil, mens en enkelt tjeneste bryder sammen \u2013 det er netop dette m\u00f8nster, jeg \u00f8nsker at identificere. Sammen med OOM-prioriteter fastl\u00e6gger jeg klare regler for, hvad der skal ofres: uvigtige batch-workere lukkes ned f\u00f8rst, mens kerne-API\u2019er bevarer deres <strong>Headroom<\/strong>.<\/p>\n\n<h2>Virtualisering: Ballooning, KSM og Overcommit<\/h2>\n<p>I virtualiserede milj\u00f8er st\u00e5r jeg over for et dobbelt pres: G\u00e6sten ser tilsyneladende ledig RAM, mens hypervisoren via <strong>Ballonflyvning<\/strong> fjerner. Dette spil \u00f8ger Reclaim-omkostningerne for begge parter. Jeg m\u00e5ler PSI i g\u00e6sten og sammenholder det med hypervisor-metrikker; hvis PSI stiger ved ballooning-h\u00e6ndelser, har VM\u2019en brug for mere garanteret kapacitet eller bedre cgroup-politikker i v\u00e6rten. <strong>KSM<\/strong> sparer RAM ved at deduplicere identiske sider, men belaster CPU\u2019en; i hosting-ops\u00e6tninger med mange ensartede VM\u2019er kan det v\u00e6re en fordel, s\u00e5 l\u00e6nge den ekstra CPU-belastning ikke truer SLO\u2019erne. Overcommit (f.eks. aggressiv tildeling af mange sm\u00e5 VM'er) planl\u00e6gger jeg kun med faste SLO-reserver og strengt <strong>hukommelse.lav<\/strong> til systemer, hvor ventetiden er afg\u00f8rende.<\/p>\n\n<h2>Arkitektoniske valg i forbindelse med hosting<\/h2>\n\n<p>Jeg satser p\u00e5 horisontal fordeling, s\u00e5 de enkelte instanser uds\u00e6ttes for f\u00e6rre belastningsspidser; skalerbare puljer d\u00e6mper udsving og holder latenstiderne p\u00e5 et lavere niveau. Jeg adskiller rollerne tydeligt: Databaser, applikationer og caching f\u00e5r hver deres egne ressourcepuljer, s\u00e5 reclaim-processer ikke skaber uventede bivirkninger p\u00e5 tv\u00e6rs af systemgr\u00e6nser. Jeg v\u00e6lger storage med fokus p\u00e5 skrivelatens, da dirty page flushes har direkte indflydelse p\u00e5 svartiderne; en hurtig sti reducerer reclaim-tiderne m\u00e6rkbart. I klynger planl\u00e6gger jeg RAM-reserver pr. node og styrer via scheduler-politikker, s\u00e5 belastning og hukommelsesforbrug forbliver j\u00e6vnt fordelt. Jeg automatiserer skalering med PSI-t\u00e6rskelv\u00e6rdier, s\u00e5 stigende \u201esome\u201c-v\u00e6rdier udl\u00f8ser handlinger, inden det kommer til fuldst\u00e6ndige nedbremsninger og <strong>Dr\u00e6b<\/strong>-begivenheder.<\/p>\n\n<h2>Kapacitetsplanl\u00e6gning og headroom-modeller<\/h2>\n<p>Jeg definerer headroom p\u00e5 en m\u00e5lbar m\u00e5de: Jeg s\u00f8rger for tilstr\u00e6kkelige reserver, s\u00e5 \u201esome\u201c-PSI under normale spidsbelastninger forbliver under definerede t\u00e6rskelv\u00e6rdier, og \u201efull\u201c praktisk talt ikke forekommer. Til dette bruger jeg percentiler (f.eks. 99. percentil af den timelige belastning) og planl\u00e6gger 10\u201330 % ekstra RAM afh\u00e6ngigt af arbejdsbelastningens volatilitet. Databaser f\u00e5r st\u00f8rre faste reserver, mens web-frontends skaleres mere dynamisk. Jeg kalibrerer rebound-tider: Hvor hurtigt falder PSI og si\/so efter en spidsbelastning? Forbliver de forh\u00f8jede, er det et tegn p\u00e5 for sm\u00e5 reserver eller en uhensigtsm\u00e6ssig swap-\/dirty-strategi. P\u00e5 den m\u00e5de bliver kapacitetsplanl\u00e6gning en l\u00f8bende proces i stedet for en \u00e5rlig sk\u00f8n.<\/p>\n\n<h2>Alarm og SLO-styret tuning<\/h2>\n<p>Jeg kobler PSI sammen med bruger-SLO\u2019er: Hvis \u201esome avg10\u201c stiger samtidig med API-latenserne, griber jeg ind. Jeg inddeler alarmer i \u201egul\u201c (vedvarende 2\u20133 % \u201esome\u201c, \u201efull\u201c t\u00e6t p\u00e5 0) og \u201er\u00f8d\u201c (over 5 % \u201esome\u201c eller \u201efull\u201c &gt; 0,1 %). cgroup-baserede alarmer hj\u00e6lper med at isolere den \u00bbst\u00f8jende minoritet\u00ab. Derudover udl\u00f8ser jeg alarmer ved stigende dirty-k\u00f8er og skrivningsventetider, s\u00e5 jeg kan udj\u00e6vne dirty-b\u00f8lger i tide. M\u00e5let er, at optimeringstiltag (swappiness, memory.high, cache-st\u00f8rrelser) skal v\u00e6re observerbare og reversible; jeg implementerer \u00e6ndringer trinvist og sammenligner f\u00f8r\/efter ved hj\u00e6lp af de samme m\u00e5linger.<\/p>\n\n<h2>Trin-for-trin-diagnose i hverdagen<\/h2>\n\n<p>F\u00f8rst tjekker jeg `free -h` og `MemAvailable`: Hvis v\u00e6rdien falder markant, leder jeg efter cacher, der med fordel kan frigives, og efter tjenester med voksende hotsets. Derefter k\u00f8rer jeg `vmstat` med korte intervaller for at identificere si\/so-tendenser; vedvarende swapping bekr\u00e6fter presset og f\u00f8rer mig til I\/O-stien. Derefter l\u00e6ser jeg \/proc\/pressure\/memory og analyserer \u201esome\u201c og \u201efull\u201c over 10, 60 og 300 sekunder; stigende gennemsnitsv\u00e6rdier knytter jeg direkte til observerede latenstider. dmesg viser mig OOM-spor og afsl\u00f8rer, hvilke processer der senest har udl\u00f8st eller v\u00e6ret ramt af hukommelseskriser; herfra udleder jeg gr\u00e6nser og prioriteter for Cgroups. Ud fra alt dette danner jeg en hypotese, gennemf\u00f8rer sm\u00e5 finjusteringer, verificerer via PSI og holder \u00f8je med <strong>Svartid<\/strong> p\u00e5 et \u00f8jeblik.<\/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\/08\/hosting-serverraum-4671.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Runbooks og typiske \u00e5rsagsk\u00e6der<\/h2>\n<p>Der er nogle m\u00f8nstre, jeg st\u00f8der p\u00e5 igen og igen:<\/p>\n<ul>\n  <li><strong>Backup- eller scanningsopgaver fortr\u00e6nger sidecachen<\/strong>: Pludselig falder cache-hit-raterne, og web\/DB bliver langsommere. Foranstaltning: Begr\u00e6ns jobbene (I\/O-prioritet), flyt tidsvinduet, indstil \u00bbmemory.high\u00ab for job-cgroupen, og beskyt sidecache-budgettet for de kritiske tjenester.<\/li>\n  <li><strong>Sikkerhedshuller i worker-processer<\/strong>: Langsomt stigende anonym hukommelse, PSI \u201esome\u201c stiger i l\u00f8bet af flere timer. Foranstaltning: Identificer l\u00e6kagen, indf\u00f8r politikker for automatisk genstart\/genbrug, fasts\u00e6t hukommelsesgr\u00e6nser, s\u00e5 l\u00e6kager ikke udg\u00f8r en risiko for hele v\u00e6rten.<\/li>\n  <li><strong>THP-relaterede stall-tilf\u00e6lde<\/strong>: kcompactd-belastningen stiger under trafikspidser. Foranstaltning: Indstil THP til \u201emadvise\u201c, tilpas de ber\u00f8rte tjenester, kontroller komprimeringsparametrene, \u00f8g headroom.<\/li>\n  <li><strong>NUMA-lokal udskrivning<\/strong>: En socket thrasher, selvom der er ledig global RAM. L\u00f8sning: Korrig\u00e9r affiniteterne, brug interleave til bredt spredte arbejdsbelastninger, juster belastningsfordelingen i scheduleren.<\/li>\n  <li><strong>Swap p\u00e5 langsomme diske<\/strong>: Hvis dette stiger, eksploderer svartiderne. Foranstaltning: Flyt swap til hurtigere lagerplads, vurder zswap\/zram, finjuster swappiness og cgroup-politikker.<\/li>\n<\/ul>\n<p>Hvert runbook afsluttes med en validering: Falder \u201esome\/full\u201c, og stabiliserer latenstiderne sig? Hvis ikke, var antagelsen forkert eller ufuldst\u00e6ndig \u2013 s\u00e5 forts\u00e6tter jeg med at iterere.<\/p>\n\n<h2>V\u00e6rkt\u00f8jer og sporing i driften<\/h2>\n<p>Ud over de klassiske v\u00e6rkt\u00f8jer fokuserer jeg p\u00e5 en mere dybdeg\u00e5ende analyse: Jeg overv\u00e5ger forholdet mellem sidecache og anon, sidefejlfrekvenser, refault-m\u00f8nstre og writeback-k\u00f8er. eBPF- og tracing-metoder viser mig pr\u00e6cist, hvor ventetiderne opst\u00e5r \u2013 for eksempel langs reclaim-stierne, i writeback eller ved allokering af store blokke. For mig er det vigtigt med en ressourcebesparende instrumentering, der er egnet til produktion: korte aktiveringsvinduer, sampling i stedet for kontinuerlig registrering og en klar sammenh\u00e6ng med applikationsmetrikker. P\u00e5 den m\u00e5de finder jeg \u00e5rsagerne, f\u00f8r jeg begynder at justere parametre i stor skala.<\/p>\n\n<h2>Hovedpunkter og n\u00e6ste skridt<\/h2>\n\n<p>Memory Pressure beskriver den tid, der g\u00e5r tabt p\u00e5 grund af hukommelsesmangel, ikke blot optaget RAM; jeg m\u00e5ler den med PSI, opdager tendenser tidligt og handler p\u00e5 baggrund af data. Hvis man ser MemAvailable, vmstat si\/so, PSI og dmesg i sammenh\u00e6ng, finder man de egentlige \u00e5rsager til latenstop og thrashing. Ved hj\u00e6lp af swappiness-, dirty- og cgroup-tuning reducerer jeg m\u00e5lrettet systemstop og sikrer vigtige tjenester deres <strong>Headroom<\/strong>. P\u00e5 arkitekturniveau d\u00e6mper horisontal fordeling, klart afgr\u00e6nsede roller og hurtige lagringsstier konsekvenserne af enhver belastningsspids. I sidste ende er det afg\u00f8rende, at jeg l\u00f8bende kobler diagnose og modforanstaltninger sammen: m\u00e5le, justere, m\u00e5le igen \u2013 indtil ydeevnen og <strong>Stabilitet<\/strong> passer igen.<\/p>","protected":false},"excerpt":{"rendered":"<p>Find ud af, hvordan hukommelsespres i Linux-kernen p\u00e5virker hostingydelsen, hvordan PSI-metrikker fungerer, og hvilke optimeringer der er n\u00f8dvendige for serverhukommelsen.<\/p>","protected":false},"author":1,"featured_media":20205,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[676],"tags":[],"class_list":["post-20212","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-server_vm"],"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":"89","_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":"Memory Pressure","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":"20205","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/posts\/20212","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=20212"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/posts\/20212\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/media\/20205"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/media?parent=20212"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/categories?post=20212"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/tags?post=20212"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}