{"id":21199,"date":"2026-08-31T11:49:34","date_gmt":"2026-08-31T09:49:34","guid":{"rendered":"https:\/\/webhosting.de\/linux-cgroup-v2-memory-controller-erklaerung-hosting-resourcen-focus\/"},"modified":"2026-08-31T11:49:34","modified_gmt":"2026-08-31T09:49:34","slug":"forklaring-af-linux-cgroup-v2-hukommelseskontrolleren-fokus-pa-hostingressourcer","status":"publish","type":"post","link":"https:\/\/webhosting.de\/da\/linux-cgroup-v2-memory-controller-erklaerung-hosting-resourcen-focus\/","title":{"rendered":"Linux cgroup v2 Memory Controller forklaret \u2013 S\u00e5dan begr\u00e6nses ressourcerne p\u00e5 en ordentlig m\u00e5de"},"content":{"rendered":"<p>Jeg forklarer, hvordan <strong>cgroup v2<\/strong> med sin hukommelsescontroller h\u00e5ndterer hukommelsesgr\u00e6nser korrekt, beskytter tjenester og indkapsler lokale OOM-h\u00e6ndelser. P\u00e5 den m\u00e5de kan administratorer fastl\u00e6gge klare <strong>Ressourcer<\/strong>-fastl\u00e6gger regler, d\u00e6mper spidsbelastninger p\u00e5 en kontrolleret m\u00e5de og beskytter kritiske processer mod tab af lagerplads.<\/p>\n\n<h2>Centrale punkter<\/h2>\n<p>Den f\u00f8lgende liste opsummerer de centrale aspekter, som jeg uddyber i artiklen.<\/p>\n<ul>\n  <li><strong>Standardiseret<\/strong> Arkitektur: cgroup v2 forenkler styring og overv\u00e5gning.<\/li>\n  <li><strong>H\u00e5rd<\/strong> Begr\u00e6nsning: memory.max forhindrer ukontrollerede allokeringer.<\/li>\n  <li><strong>Blid<\/strong> Bremse: memory.high reducerer trykket uden at dr\u00e6be med det samme.<\/li>\n  <li><strong>Mere m\u00e5lrettet<\/strong> Beskyttelse: memory.low og memory.min prioriterer tjenester.<\/li>\n  <li><strong>Gennemsigtig<\/strong> Kontrol: memory.current leverer m\u00e5lev\u00e6rdier til tuning.<\/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\/08\/serverraum-ressourcen-6912.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Hvad cgroup v2 g\u00f8r anderledes med hensyn til hukommelsen<\/h2>\n\n<p>Jeg sammenfatter processer i <strong>Kontrol<\/strong> Grupper samles, og deres hukommelsesbehov styres som en enhed. Med version v2 standardiserer kernen gr\u00e6nsefladerne, hvilket g\u00f8r det muligt for mig at anvende begr\u00e6nsninger, beskyttelsest\u00e6rskler og telemetri p\u00e5 en ensartet m\u00e5de. Hukommelseslogikken adskiller h\u00e5rd afsk\u00e6rmning fra bl\u00f8de bremser, hvilket ikke straks stopper allokeringer, men i stedet bremser dem gradvist. Dermed kan jeg reagere p\u00e5 uregelm\u00e6ssigheder uden at p\u00e5virke det samlede system, da afbrydelser sker lokalt i den ber\u00f8rte gruppe. For hosting og containere giver det planbare <strong>Ressourcer<\/strong>-Fordeling og forudsigelige reaktioner p\u00e5 belastningssprung.<\/p>\n\n<p>Jeg udnytter disse egenskaber til at samle tjenester med lignende profiler og fastl\u00e6gge klare regler. Jeg adskiller containere, PHP-workere og databaseprocesser tydeligt, s\u00e5 hvert s\u00e6t af arbejdsbelastninger har sine egne gr\u00e6nser. P\u00e5 den m\u00e5de undg\u00e5r jeg krydsindflydelser som f.eks. globalt lagerpres, der p\u00e5virker harml\u00f8se opgaver. Denne isolering kan finjusteres trin for trin, indtil belastningsfordelingen reagerer forudsigeligt. Dermed opn\u00e5r jeg <strong>Forudsigelighed<\/strong> i drift og sikrer, at servicekvaliteten holdes p\u00e5 det rette niveau under spidsbelastning.<\/p>\n\n<h2>Oversigt over skattedokumenterne<\/h2>\n\n<p>Hukommelsesstyringen drejer sig om nogle f\u00e5 <strong>Parametre<\/strong>, som jeg indstiller i cgroup-filsystemet. Hver cgroup f\u00e5r sine egne v\u00e6rdier for h\u00e5rde gr\u00e6nser, bl\u00f8de bremsepunkter og beskyttelsesgr\u00e6nser. P\u00e5 den m\u00e5de kan jeg skalere fra mild genvinding til kompromisl\u00f8s afsk\u00e6rmning, afh\u00e6ngigt af tjenestens vigtighed. Overv\u00e5gningen afl\u00e6ser samtidig den aktuelle udnyttelse og alarmerer, n\u00e5r beskyttelsest\u00e6rsklerne udl\u00f8ses. Dermed opst\u00e5r der en lukket reguleringskreds best\u00e5ende af specifikationer og m\u00e5lev\u00e6rdier, som <strong>Ressourcer<\/strong>-forbruget kan kontrolleres.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Parametre<\/th>\n      <th>Venlig<\/th>\n      <th>Effekt<\/th>\n      <th>Typisk brug<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>hukommelse.max<\/td>\n      <td>H\u00e5rd <strong>Gr\u00e6nse<\/strong><\/td>\n      <td>Blokerer nye tildelinger over gr\u00e6nsen; lokal OOM-afbrydelse<\/td>\n      <td>Databaser, JVM\u2019er, PHP-FPM-puljer med klare begr\u00e6nsninger<\/td>\n    <\/tr>\n    <tr>\n      <td>hukommelse.h\u00f8j<\/td>\n      <td>Bl\u00f8d <strong>bremse<\/strong><\/td>\n      <td>\u00d8ger Reclaim og latenstid ved allokeringer; ingen \u00f8jeblikkelige drab<\/td>\n      <td>Blid nedtrapning f\u00f8r eskalering<\/td>\n    <\/tr>\n    <tr>\n      <td>hukommelse.lav<\/td>\n      <td>Bl\u00f8d<strong>Beskyttelse<\/strong><\/td>\n      <td>Bedst mulig beskyttelse mod reclaim under t\u00e6rsklen<\/td>\n      <td>Vigtig middleware, cacher, centrale tjenester<\/td>\n    <\/tr>\n    <tr>\n      <td>hukommelse.min<\/td>\n      <td>H\u00e5rdere <strong>Beskyttelse<\/strong><\/td>\n      <td>Ingen \u00bbReclaim\u00ab under t\u00e6rsklen; OOM rammer snarere andre grupper<\/td>\n      <td>Kritiske n\u00f8glekomponenter<\/td>\n    <\/tr>\n    <tr>\n      <td>memory.current<\/td>\n      <td>Live-<strong>V\u00e6rdi<\/strong><\/td>\n      <td>Viser aktuel forbrug; grundlag for alarmer og optimering<\/td>\n      <td>Dashboards, tendensanalyser<\/td>\n    <\/tr>\n    <tr>\n      <td>memory.oom.group<\/td>\n      <td>Kill-<strong>Omfang<\/strong><\/td>\n      <td>Samler OOM-drab p\u00e5 gruppeniveau<\/td>\n      <td>Konsekvent afslutning af sammenh\u00e6ngende processer<\/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\/linuxcgroup-memory-2321.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>At forst\u00e5 hierarkier og arv<\/h2>\n\n<p>Jeg konfigurerer cgroups <strong>hierarkisk<\/strong>: Overordnede grupper fastl\u00e6gger rammerne, b\u00f8rn arver gr\u00e6nser og deler den tilg\u00e6ngelige hukommelse. Denne struktur g\u00f8r retningslinjerne forudsigelige, men kr\u00e6ver klare regler. For\u00e6ldrenes \u00bbmemory.max\u00ab begr\u00e6nser summen af b\u00f8rnene; \u00bbmemory.low\u00ab og \u00bbmemory.min\u00ab fungerer ved konkurrence p\u00e5 s\u00f8skendeniveau som <strong>Prioriteringer<\/strong>: En gruppe med h\u00f8jere beskyttelsesniveau bevarer i h\u00f8jere grad sin basishukommelse, mens mindre vigtige grupper i h\u00f8jere grad genbruges. Det hj\u00e6lper mig med at sikre centrale stier uden at sv\u00e6kke de globale lofter.<\/p>\n\n<p>Jeg bem\u00e6rker, at beskyttelsesv\u00e6rdierne <strong>additivt<\/strong> Er hensigten: For h\u00f8je v\u00e6rdier for memory.min p\u00e5 tv\u00e6rs af alle underordnede niveauer blokerer Reclaim i hierarkiet og flytter presset opad, helt til v\u00e6rten. Derfor kalibrerer jeg beskyttelsesbudgetterne pr. niveau og s\u00f8rger altid for at efterlade en buffer. I trinmodeller definerer jeg klasser (kritisk, vigtig, best effort) og anvender ensartede b\u00e5ndbredder og beskyttelsest\u00e6rskler for hver klasse. Dermed forbliver belastningsfordelingen retf\u00e6rdig og gennemsigtig \u2013 ogs\u00e5 selvom teams selvst\u00e6ndigt administrerer undergrupper.<\/p>\n\n<h2>Streng gr\u00e6nse: Indstil memory.max korrekt<\/h2>\n\n<p>Jeg s\u00e6tter <strong>hukommelse.max<\/strong> s\u00e5ledes at processen har tilstr\u00e6kkelig plads til spidsbelastninger, men ikke dominerer serveren. Til det form\u00e5l m\u00e5ler jeg realistiske spidsbelastninger, l\u00e6gger en reserve til og begr\u00e6nser derefter konsekvent. Hvis en tjeneste n\u00e5r denne \u00f8vre gr\u00e6nse, foretages der ingen allokeringer, og kernen afslutter lokale processer inden for gruppen. Denne indkapsling forhindrer dominoeffekter p\u00e5 andre arbejdsbelastninger. For hukommelseskr\u00e6vende tjenester medf\u00f8rer dette en klar <strong>Sikkerhed<\/strong> uden tv\u00e6rg\u00e5ende skader.<\/p>\n\n<p>Ved store heaps eller caches indregner jeg bevidst en buffer, da garbage collection og baggrundsopgaver skaber udsving. Jeg validerer gr\u00e6nsen med belastningstests, s\u00e5 der ikke opst\u00e5r OOM-h\u00e6ndelser under normal drift. Hvis udnyttelsen vedvarende ligger t\u00e6t p\u00e5 gr\u00e6nsen, \u00f8ger jeg f\u00f8rst reserven eller reducerer den egentlige arbejdsm\u00e6ngde. P\u00e5 den m\u00e5de holder jeg fejlmargenen lille og effektiviteten h\u00f8j. Denne disciplin betaler sig i <strong>Tilg\u00e6ngelighed<\/strong> fra.<\/p>\n\n<h2>Bl\u00f8d bremse: memory.high i hverdagen<\/h2>\n\n<p>Med <strong>hukommelse.h\u00f8j<\/strong> s\u00e6tter jeg et advarsels- og bremsepunkt f\u00f8r den skarpe kant. Hvis gruppen overskrider v\u00e6rdien, aktiverer Reclaim-kernen og bremser allokeringerne, uden at rydde op med det samme. Denne tid bruger jeg til at t\u00f8mme cacher, sprede batch-belastningen eller s\u00e6nke foresp\u00f8rgselsgr\u00e6nserne. Dermed udj\u00e6vner jeg spidsbelastninger, endnu f\u00f8r det bliver n\u00f8dvendigt at afbryde processer. Det forbedrer <strong>Service-kvalitet<\/strong> ved pludselige belastningsspidser.<\/p>\n\n<p>Jeg v\u00e6lger en m\u00e6rkbar afstand mellem memory.high og memory.max, s\u00e5 systemet har et reelt spillerum. Er afstanden for lille, ender jeg for hurtigt med en OOM. Er den for stor, mister jeg kontrollen over latenstiderne. Jeg tester begge dele under produktionsprofiler og kalibrerer det optimale punkt. P\u00e5 den m\u00e5de skaber jeg en p\u00e5lidelig <strong>Gash\u00e5ndtag<\/strong>, der tr\u00e6der i kraft i tide.<\/p>\n\n<h2>Swap-politik: V\u00e6lg memory.swap.max med omhu<\/h2>\n\n<p>Jeg bestemmer, om og i hvilket omfang en gruppe <strong>Bytte<\/strong> m\u00e5 bruge. Med `memory.swap.max` begr\u00e6nser jeg swap-brugen uafh\u00e6ngigt af RAM-gr\u00e6nsen. Hvis jeg s\u00e6tter v\u00e6rdien til 0, forbyder jeg swap for gruppen \u2013 hvilket er fornuftigt for tjenester, der er f\u00f8lsomme over for latenstid, og som ikke m\u00e5 blokere. Hvis jeg tillader moderat swap, f\u00e5r jeg st\u00f8rre fleksibilitet for cacher og sj\u00e6ldent anvendte sider. Det er vigtigt, at jeg <strong>haster<\/strong> af de forskellige arbejdsbelastninger: Databaser og JVM\u2019er drager ofte fordel af en streng eller meget stram swap-politik, mens batch- eller rapporteringsopgaver er mere fleksible, hvad ang\u00e5r udskiftning.<\/p>\n\n<p>Jeg tilpasser swap-strategien til v\u00e6rtskonfigurationen (f.eks. swappiness, zram\/zswap), s\u00e5 foranstaltningerne ikke modarbejder hinanden. Overdreven brug af swap skjuler kun hukommelsesmangel p\u00e5 kort sigt og flytter belastningen over p\u00e5 IO \u2013 jeg bruger det m\u00e5lrettet som <strong>Buffer<\/strong>, ikke som en permanent tilstand. M\u00e5lev\u00e6rdier som \u00bbMajor Page Faults\u00ab og latenstider viser hurtigt, om swap hj\u00e6lper eller bremser. P\u00e5 den m\u00e5de bevarer jeg kontrollen over forsinkelser og \u00bbtail-latenstider\u00ab.<\/p>\n\n<h2>Beskyttelsesgr\u00e6nser: memory.low og memory.min<\/h2>\n\n<p>Jeg bruger <strong>hukommelse.lav<\/strong>, for at sikre vigtige tjenester deres basishukommelse. S\u00e5 l\u00e6nge brugen holder sig under dette niveau, sk\u00e5ner kernen denne andel og genvinder hellere hukommelse andre steder. Til komponenter med h\u00f8j prioritet bruger jeg desuden memory.min. Denne strenge beskyttelsesgr\u00e6nse g\u00f8r det klart for kernen, at jeg ikke tillader genvinding her. P\u00e5 den m\u00e5de forbliver kernen i en applikation funktionsdygtig selv under ekstrem belastning og <strong>lydh\u00f8r<\/strong>.<\/p>\n\n<p>Jeg fastl\u00e6gger bevidst v\u00e6gtningen: centrale databaser f\u00e5r \u00bbmemory.min\u00ab, kritisk middleware f\u00e5r \u00bbmemory.low\u00ab, og ikke-kritiske batch-jobs f\u00e5r ingen ekstra beskyttelse. Denne prioritering g\u00f8r det lettere at tr\u00e6ffe beslutninger i tilf\u00e6lde af flaskehalse. Hvis der opst\u00e5r en OOM, beskytter denne inddeling mine n\u00f8glebaner. Jeg bevarer kontrollen over, hvem der f\u00f8rst skal afgive hukommelse. Det giver mig klare <strong>Prioriteringer<\/strong> i tilf\u00e6lde af flaskehalse.<\/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-control-explained-2984.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Gennemsigtighed: memory.current i overv\u00e5gningen<\/h2>\n\n<p>Jeg l\u00e6ste <strong>memory.current<\/strong> Jeg overv\u00e5ger det l\u00f8bende og sammenholder det med applikationsmetrikker. P\u00e5 den m\u00e5de kan jeg identificere tendenser, opbygning af backlog og spidsbelastninger. Hvis systemet registrerer flere overskridelser af memory.high eller OOM-h\u00e6ndelser, justerer jeg gr\u00e6nserne eller arbejdsbelastningen. Dashboards og alarmer giver mig et forspring i forhold til forstyrrelser. Ud fra disse data udleder jeg <strong>Indstilling<\/strong>-beslutninger, der p\u00e5 lang sigt forhindrer udfald.<\/p>\n\n<p>Ud over selve v\u00e6rdien overv\u00e5ger jeg page-fault-frekvenser, cache-hit-rate og ventetider. Dette overblik viser, om \u00bbReclaim\u00ab bremser for meget, eller om beskyttelsesmekanismerne tr\u00e6der i kraft. Jeg justerer intervaller og t\u00e6rskelv\u00e6rdier, indtil alarmerne er nyttige og ikke irriterende. Derefter automatiserer jeg modforanstaltninger som cache-trim eller k\u00f8begr\u00e6nsning. P\u00e5 den m\u00e5de forbliver reaktionen hurtig og <strong>m\u00e5lrettet<\/strong>.<\/p>\n\n<h2>Telemetri i dybden: memory.stat, memory.events og PSI<\/h2>\n\n<p>Jeg tilf\u00f8jer f\u00f8lgende til memory.current: <strong>memory.stat<\/strong> og <strong>memory.events<\/strong>, for at identificere \u00e5rsagerne i stedet for blot symptomerne. memory.stat opdeler brugen i kategorier som Anon, File-Cache, Slab og andre. Ud fra disse andele kan jeg se, om allokeringerne til en applikation eller sidecachen vokser \u2013 og justere indstillingerne i overensstemmelse hermed (f.eks. cache-st\u00f8rrelser kontra antal arbejdsprocesser). memory.events og memory.events.local t\u00e6ller udl\u00f8sere s\u00e5som overskridelser af low\/high\/max samt <strong>oom<\/strong> og <strong>oom_kill<\/strong>. Det giver p\u00e5lidelige udl\u00f8sere til alarmer og automatisk afhj\u00e6lpning.<\/p>\n\n<p>Jeg bruger ogs\u00e5 <strong>PSI<\/strong> (Pressure Stall Information) for at kvantificere trykket i stedet for at g\u00e6tte. Hvis Memory-PSI-v\u00e6rdierne stiger vedvarende, oplever tr\u00e5de ventetider p\u00e5 sider; jeg begr\u00e6nser arbejdsbyrden, \u00f8ger memory.high eller aflaster b\u00e5ndbredderne i pipelinen. Samlet set skaber dette en telemetri, der giver mig gradvis <strong>Tidlige advarsler<\/strong> leverer \u2013 inden de strenge gr\u00e6nser tr\u00e6der i kraft.<\/p>\n\n<h2>Containere og orkestrering<\/h2>\n\n<p>Hvis jeg indstiller hukommelsesgr\u00e6nser i Kubernetes, bliver disse gemt som <strong>cgroup<\/strong>-v\u00e6rdier som memory.max og eventuelt memory.high i runtime. Orkestreringen anvender politikker pr. pod, mens jeg definerer finjusteringerne pr. navnerum eller deployment. For at sikre p\u00e5lidelige SLO\u2019er knytter jeg gr\u00e6nser til HPA-strategier og pod-budgetter. Denne helhedsorienterede tilgang forhindrer, at enkelte pods dominerer hukommelsen. En god introduktion til <a href=\"https:\/\/webhosting.de\/da\/cgroups-hosting-ressourceisolering-linux-containerlimits-serverboost\/\">Ressourceisolering med cgroups<\/a> g\u00f8r det lettere at planl\u00e6gge containere med klare afgr\u00e6nsninger og indk\u00f8rsler.<\/p>\n\n<p>Jeg tjekker desuden, om sidecars og init-containere f\u00e5r deres egne begr\u00e6nsninger, s\u00e5 hj\u00e6lpeprocesser ikke begr\u00e6nser kerne-workloads. For stateful workloads indstiller jeg memory.low eller memory.min, s\u00e5 cacher og buffere ikke straks krymper. Jeg dokumenterer disse beslutninger i implementeringen, s\u00e5 teamet nemt kan forst\u00e5 dem. P\u00e5 den m\u00e5de sikrer jeg <strong>Konsistens<\/strong> mellem infrastruktur og applikation. Det resulterer i forudsigelige arbejdsbelastningsprofiler.<\/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\/Tech_Office_Linux_cgroup_7458.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Systemd-integration og automatisering<\/h2>\n\n<p>Jeg bruger systemd til at indstille cgroup v2-parametre deklarativt: <strong>MemoryMax<\/strong> svarer til memory.max, <strong>HukommelseH\u00f8j<\/strong> memory.high, <strong>MemoryLow<\/strong> og <strong>MemoryMin<\/strong> fastl\u00e6gger beskyttelseslinjer, <strong>MemorySwapMax<\/strong> styrer swap. Denne struktur g\u00f8r det muligt at f\u00f8lge politikkerne i koderepositoriet og letter rollbacks. I st\u00f8rre milj\u00f8er koordinerer jeg dermed konsistente <strong>Standarder<\/strong> pr. serviceklasse og adskille driften fra manuelle indgreb.<\/p>\n\n<p>Til automatiske indgreb kombinerer jeg begivenheder fra memory.events\/PSI med policy-engines. Hvis en gruppe gentagne gange overskrider memory.high, reducerer jeg antallet af workers, begr\u00e6nser burst-rater eller udl\u00f8ser <strong>m\u00e5lrettet<\/strong> Cache-Trim. Hvis disse trin ikke virker, lader jeg systemets egne OOM-mekanismer virke p\u00e5 en kontrolleret m\u00e5de \u2013 via memory.oom.group forbliver effekten lokal og forudsigelig. P\u00e5 den m\u00e5de opn\u00e5s en gradvis, selvhelende adf\u00e6rd uden overraskelser.<\/p>\n\n<h2>Multi-tenant-hosting med CloudLinux<\/h2>\n\n<p>Jeg indkapsler kundemilj\u00f8er i separate <strong>cgroups<\/strong> og fasts\u00e6tter klare gr\u00e6nser for hver enkelt tenant. CloudLinux supplerer dette med v\u00e6rkt\u00f8jer, der afgr\u00e6nser RAM, CPU og IO for hver enkelt konto. P\u00e5 den m\u00e5de holdes naboeffekterne under kontrol, og enkelte udskud tr\u00e6kker ikke alle konti med ned. Hvis man \u00f8nsker at dykke dybere ned i emnet, finder man en praktisk oversigt over <a href=\"https:\/\/webhosting.de\/da\/cgroup-v2-cloudlinux-delt-hosting-stabil\/\">CloudLinux og cgroup v2<\/a> i forbindelse med shared hosting. P\u00e5 den m\u00e5de sikrer jeg rimelige <strong>Ressourcer<\/strong>-Fordeling p\u00e5 mange kunder.<\/p>\n\n<p>Jeg indstiller `memory.max` pr. kunde ud fra den m\u00e5lte daglige profil, tildeler cacherne en `memory.low`-v\u00e6rdi og sikrer kerneprocesser med `memory.min`. Ved overskridelser af gr\u00e6nserne s\u00e6nkes hastigheden f\u00f8rst via throttling i stedet for at bremse konti h\u00e5rdt op. Opst\u00e5r der en OOM, rammer det kun den ber\u00f8rte gruppe lokalt. Dermed forbliver platformen tilg\u00e6ngelig for andre lejere. Denne fremgangsm\u00e5de styrker <strong>Planl\u00e6gbarhed<\/strong> i forhold til trafikspidser.<\/p>\n\n<h2>S\u00e6rlige tilf\u00e6lde: Sidecache, THP og store sider<\/h2>\n\n<p>Jeg skelner mellem <strong>Anon<\/strong>-hukommelse (heaps, stacks) og <strong>Filcache<\/strong> (Sidecache). Under belastning er det lettere at frigive filcache, mens anonyme sider kr\u00e6ver swap eller f\u00f8rer til OOM. memory.high og beskyttelsesgr\u00e6nser hj\u00e6lper mig med at reducere filcachen uden at p\u00e5virke kritiske heaps. Ved Transparent Huge Pages (THP) unders\u00f8ger jeg, om de gavner applikationen eller \u00f8ger fragmentering og latenstider \u2013 afh\u00e6ngigt af profilen tilpasser jeg THP-politikken, s\u00e5 samspillet med hukommelsescontrolleren forbliver harmonisk.<\/p>\n\n<p>Bruger et program <strong>Hugepages<\/strong> Jeg isolerer eksplicit deres behov via de tilh\u00f8rende controllere, adskilt fra RAM-styringen. P\u00e5 den m\u00e5de forhindrer jeg, at store sider fortr\u00e6nger den almindelige RAM. Jeg holder disse s\u00e6rlige reserver p\u00e5 et lavt niveau og koordinerer dem med de \u00f8vrige begr\u00e6nsninger, s\u00e5 der ikke opst\u00e5r uventede flaskehalse. Alt i alt skabes der klare retningslinjer for almindeligt og specielt hukommelsesforbrug.<\/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_cgroup_me_script_1283.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Bedste praksis for gr\u00e6nser<\/h2>\n\n<p>Jeg tager udgangspunkt i reelle forbrugsprofiler og fastl\u00e6gger <strong>hukommelse.max<\/strong> med en reserve, s\u00e5 spidsbelastninger ikke straks udl\u00f8ser OOM. Jeg s\u00e6tter memory.high m\u00e6rkbart lavere for at udj\u00e6vne belastningsspidser og bremse allokeringerne. Det er vigtigt at prioritere: Databasen f\u00e5r `memory.min`, middleware f\u00e5r `memory.low`, og batch-belastningen f\u00e5r ingen s\u00e6rlig rolle. Overv\u00e5gning ledsager driften og viser, om t\u00e6rskelv\u00e6rdierne virker, eller om de er valgt for strengt. P\u00e5 baggrund af disse signaler justerer jeg gr\u00e6nserne og \u00f8ger samtidig <strong>Effektivitet<\/strong> i applikationen.<\/p>\n\n<p>Jeg dokumenterer v\u00e6rdierne for hver tjeneste, beskriver begrundelserne og registrerer \u00e6ndringer p\u00e5 en m\u00e5de, der g\u00f8r dem lette at forst\u00e5. P\u00e5 den m\u00e5de forankrer jeg beslutningerne i teamet og undg\u00e5r, at man efter flere uger ender med at g\u00e6tte. F\u00f8r opdateringer eller arkitektur\u00e6ndringer ser jeg p\u00e5 forl\u00f8bskurverne, s\u00e5 jeg ikke strammer eller lemper indstillingerne i blinde. En lille testfase sparer senere for en masse besv\u00e6r i produktionen. Denne rytme sikrer <strong>Constance<\/strong> i den daglige drift.<\/p>\n\n<h2>Praksis: Strukturering af webhosting-servere<\/h2>\n\n<p>Jeg opretter en separat for hver kunde <strong>cgroup<\/strong> og flytter PHP-FPM, databasen og cachen derind. Jeg tildeler hvert s\u00e6t memory.max plus buffer, mens memory.high tr\u00e6der i kraft tidligere og udj\u00e6vner udsving. Kundens kritiske tjenester f\u00e5r beskyttelsesgr\u00e6nser, s\u00e5 deres kernememory ikke falder. Logfiler og dashboards viser, hvem der bremser, hvem der s\u00e6tter gang i tingene, og hvor der er risiko for OOM. Derudover hj\u00e6lper tip om <a href=\"https:\/\/webhosting.de\/da\/serverkontekst-isolation-namespaces-cgroups-hosting-sikkerhed\/\">Navneomr\u00e5der og isolationskoncepter<\/a>, s\u00e5 klienterne forbliver klart adskilt, og <strong>Sikkerhed<\/strong> \u00f8ges.<\/p>\n\n<p>Jeg justerer desuden antallet af PHP-workere, OPcache-st\u00f8rrelser og query-caches for at reducere hukommelsesforbruget. Ofte er det nok blot at reducere spidsbelastningerne via `memory.high` for at forkorte responstiden. Til test bruger jeg reelle belastningsm\u00f8nstre, ikke syntetiske idealv\u00e6rdier. Derefter dokumenterer jeg nye gr\u00e6nsev\u00e6rdier og knytter dem til SLA\u2019er. P\u00e5 den m\u00e5de vokser <strong>Gennemsigtighed<\/strong> over for kunder og den interne support.<\/p>\n\n<h2>Fejlfinding ved udskrivning fra hukommelsen<\/h2>\n\n<p>Stiger <strong>memory.current<\/strong> N\u00e5r der sker noget pludseligt, tjekker jeg f\u00f8rst \u00e6ndringer i trafikken, i deployments eller i konfigurationerne. Jeg sammenligner kurverne for overskridelser af maksimumsgr\u00e6nser, page-faults og latenstider. Hvis der opst\u00e5r en r\u00e6kke OOM\u2019er, identificerer jeg de ber\u00f8rte processer via kernel-loggen og justerer gr\u00e6nser eller arbejdsbelastning. Ligger \u00e5rsagen i fejlbeh\u00e6ftede cacher, foretager jeg m\u00e5lrettede justeringer i stedet for at l\u00f8se problemet globalt. Denne diagnosek\u00e6de f\u00f8rer mig hurtigt til <strong>\u00c5rsag<\/strong>, ikke blot et symptom.<\/p>\n\n<p>Hvis belastningen forbliver h\u00f8j, fordeler jeg arbejdet: indf\u00f8rer burst-gr\u00e6nser for indl\u00e6sning, reducerer k\u00f8-l\u00e6ngder og udskyder batch-opgaver. Samtidig \u00f8ger jeg kortvarigt memory.high for at vinde tid uden at h\u00e6ve memory.max. Hvis der opdages l\u00e6kager, strammer jeg guardrails, indtil der er en l\u00f8sning p\u00e5 plads. I sv\u00e6re tilf\u00e6lde reducerer jeg serviceomfanget eller replikerer instansen. S\u00e5dan holder jeg <strong>Betjening<\/strong> fungerer p\u00e5lideligt, selv under pres.<\/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-cgroup-memory-4297.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Automatisering: Begivenhedsstyrede modforanstaltninger<\/h2>\n\n<p>Jeg knytter <strong>Handlinger<\/strong> H\u00e6ndelser: memory.events leverer t\u00e6llere, som jeg behandler via en watcher eller en metrik-pipeline. Ved gentagne high-hits t\u00f8mmer jeg m\u00e5lrettet cacher, s\u00e6nker samtidighedsniveauet eller iv\u00e6rks\u00e6tter reclaim-fors\u00f8g, f\u00f8r brugerne bem\u00e6rker noget. Hvis milde indgreb sl\u00e5r fejl, skifter jeg til h\u00e5rde foranstaltninger: anmodningsstop, k\u00f8-drain, \u00e6ndring af prioritering. Det er vigtigt, at beslutninger <strong>deterministisk<\/strong> er \u2013 samme udl\u00f8sere, samme reaktion \u2013 s\u00e5 teams kan forst\u00e5 og gentage adf\u00e6rden.<\/p>\n\n<p>Desuden beholder jeg <strong>Omfang<\/strong> med fokus p\u00e5 OOM. Med memory.oom.group undg\u00e5r jeg delvise afbrydelser, der bringer applikationer i inkonsekvente tilstande. Hvis noget skal afsluttes, skal det ske sammenh\u00e6ngende og hurtigt, s\u00e5 den resterende kapacitet hurtigt bliver tilg\u00e6ngelig igen. Kombineret med telemetri og dokumenterede playbooks skabes der en robust feedback-loop, der fungerer under reelle produktionsbetingelser.<\/p>\n\n<h2>Udsigter og opsummering<\/h2>\n\n<p>Hukommelsescontrolleren fra <strong>cgroup<\/strong> v2 giver mig et differentieret v\u00e6rkt\u00f8jss\u00e6t: strenge begr\u00e6nsninger, bl\u00f8de bremser og beskyttelsesgr\u00e6nser med klare prioriteter. Hvis jeg bevidst anvender memory.max, memory.high, memory.low og memory.min, reagerer jeg struktureret p\u00e5 belastningsspidser og sikrer, at tjenesterne forbliver funktionsdygtige. Overv\u00e5gning via memory.current afsl\u00f8rer tidligt, hvor gr\u00e6nserne strammes, eller hvor der mangler reserver. I container- og multi-tenant-ops\u00e6tninger sikrer disse mekanismer en retf\u00e6rdig ressourcefordeling uden krydskonflikter. Med disciplin, m\u00e5lev\u00e6rdier og sm\u00e5 korrektioner opn\u00e5r jeg p\u00e5lidelig <strong>Ydelse<\/strong> \u2013 fra en enkelt virtuel maskine til en t\u00e6tpakket v\u00e6rt.<\/p>","protected":false},"excerpt":{"rendered":"<p>L\u00e6r, hvordan Linux cgroup v2-hukommelseskontrolleren fungerer, og hvordan du ved hj\u00e6lp af m\u00e5lrettede ressourcebegr\u00e6nsninger i Linux kan oprette stabile hosting- og containermilj\u00f8er.<\/p>","protected":false},"author":1,"featured_media":21192,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[676],"tags":[],"class_list":["post-21199","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":"220","_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":"cgroup v2","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":"21192","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/posts\/21199","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=21199"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/posts\/21199\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/media\/21192"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/media?parent=21199"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/categories?post=21199"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/tags?post=21199"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}