{"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":"linux-cgroup-v2-minneskontroller-foerklaring-fokus-pa-resurser-foer-webbhotell","status":"publish","type":"post","link":"https:\/\/webhosting.de\/sv\/linux-cgroup-v2-memory-controller-erklaerung-hosting-resourcen-focus\/","title":{"rendered":"Linux cgroup v2 Memory Controller f\u00f6rklarad \u2013 att begr\u00e4nsa resurser p\u00e5 ett korrekt s\u00e4tt"},"content":{"rendered":"<p>Jag f\u00f6rklarar hur <strong>cgrupp v2<\/strong> med sin minneskontroller hanterar minnesgr\u00e4nser p\u00e5 ett korrekt s\u00e4tt, skyddar tj\u00e4nster och isolerar lokala OOM-h\u00e4ndelser. P\u00e5 s\u00e5 s\u00e4tt kan administrat\u00f6rer fastst\u00e4lla tydliga <strong>Resurser<\/strong>-fastst\u00e4ller regler, d\u00e4mpar belastningstoppar p\u00e5 ett kontrollerat s\u00e4tt och skyddar kritiska processer mot avbrott i energif\u00f6rs\u00f6rjningen.<\/p>\n\n<h2>Centrala punkter<\/h2>\n<p>F\u00f6ljande lista sammanfattar de viktigaste aspekterna som jag konkretiserar i inl\u00e4gget.<\/p>\n<ul>\n  <li><strong>Standardiserad<\/strong> Arkitektur: cgroup v2 f\u00f6renklar styrning och \u00f6vervakning.<\/li>\n  <li><strong>H\u00e5rd<\/strong> Begr\u00e4nsning: memory.max f\u00f6rhindrar okontrollerade allokeringar.<\/li>\n  <li><strong>Mild<\/strong> Broms: memory.high minskar trycket utan att omedelbart orsaka d\u00f6dsfall.<\/li>\n  <li><strong>Mer m\u00e5linriktad<\/strong> Skydd: memory.low och memory.min prioriterar tj\u00e4nster.<\/li>\n  <li><strong>Transparent<\/strong> Kontroll: memory.current levererar m\u00e4tv\u00e4rden f\u00f6r inst\u00e4llning.<\/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>Hur cgroup v2 skiljer sig \u00e5t n\u00e4r det g\u00e4ller minne<\/h2>\n\n<p>Jag sammanfattar processer i <strong>Kontroll<\/strong> Grupperas och hanterar deras minnesbehov som en enhet. I version v2 standardiserar k\u00e4rnan gr\u00e4nssnitten, vilket g\u00f6r att jag kan till\u00e4mpa gr\u00e4nsv\u00e4rden, skyddstr\u00f6sklar och telemetri p\u00e5 ett enhetligt s\u00e4tt. Minneslogiken skiljer h\u00e5rd avgr\u00e4nsning fr\u00e5n mjuka bromsar, vilket inneb\u00e4r att allokeringar inte stryps omedelbart utan saktas ner p\u00e5 ett ordnat s\u00e4tt. P\u00e5 s\u00e5 s\u00e4tt kan jag reagera p\u00e5 avvikelser utan att hela systemet p\u00e5verkas, eftersom avst\u00e4ngningar sker lokalt i den ber\u00f6rda gruppen. F\u00f6r hosting och containrar inneb\u00e4r detta att det g\u00e5r att planera <strong>Resurser<\/strong>-F\u00f6rdelning och f\u00f6ruts\u00e4gbara reaktioner p\u00e5 belastningssv\u00e4ngningar.<\/p>\n\n<p>Jag utnyttjar dessa egenskaper f\u00f6r att gruppera tj\u00e4nster med liknande profil och fastst\u00e4lla tydliga regler. Jag separerar containrar, PHP-arbetare och databasprocesser noggrant, s\u00e5 att varje upps\u00e4ttning arbetsbelastningar har sina egna gr\u00e4nser. P\u00e5 s\u00e5 s\u00e4tt undviker jag st\u00f6rningar som global lagringsbelastning, som kan drabba ofarliga jobb. Denna isolering kan finjusteras stegvis tills lastf\u00f6rdelningen reagerar f\u00f6ruts\u00e4gbart. P\u00e5 s\u00e5 s\u00e4tt vinner jag <strong>F\u00f6ruts\u00e4gbarhet<\/strong> i drift och ser till att servicekvaliteten h\u00e5lls p\u00e5 r\u00e4tt niv\u00e5 \u00e4ven under h\u00f6g belastning.<\/p>\n\n<h2>En \u00f6versikt \u00f6ver skattedokumenten<\/h2>\n\n<p>Lagringshanteringen handlar om ett f\u00e5tal <strong>Parametrar<\/strong>, som jag st\u00e4ller in i cgroup-filsystemet. Varje cgroup f\u00e5r sina egna v\u00e4rden f\u00f6r h\u00e5rda gr\u00e4nser, mjuka bromsgr\u00e4nser och skyddsgr\u00e4nser. P\u00e5 s\u00e5 s\u00e4tt kan jag skala fr\u00e5n mild \u00e5tervinning till kompromissl\u00f6s avsk\u00e4rmning, beroende p\u00e5 tj\u00e4nstens betydelse. \u00d6vervakningen avl\u00e4ser samtidigt den aktuella anv\u00e4ndningen och larmar n\u00e4r skyddsgr\u00e4nserna tr\u00e4der i kraft. Detta skapar en sluten reglerkrets av specifikationer och m\u00e4tv\u00e4rden, som <strong>Resurser<\/strong>-g\u00f6r f\u00f6rbrukningen m\u00e4tbar.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Parametrar<\/th>\n      <th>Sn\u00e4ll<\/th>\n      <th>Effekt<\/th>\n      <th>Typisk anv\u00e4ndning<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>minne.max<\/td>\n      <td>H\u00e5rd <strong>Gr\u00e4ns<\/strong><\/td>\n      <td>Blockerar nya tilldelningar \u00f6ver gr\u00e4nsv\u00e4rdet; lokal OOM-avst\u00e4ngning<\/td>\n      <td>Databaser, JVM:er, PHP-FPM-pooler med tydliga begr\u00e4nsningar<\/td>\n    <\/tr>\n    <tr>\n      <td>minne.h\u00f6g<\/td>\n      <td>Mjuk <strong>broms<\/strong><\/td>\n      <td>\u00d6kar \u201dReclaim\u201d och latensen vid tilldelningar; inga omedelbara d\u00f6dande<\/td>\n      <td>Mild nedtrappning innan situationen eskalerar<\/td>\n    <\/tr>\n    <tr>\n      <td>minne.l\u00e5g<\/td>\n      <td>Mjuk<strong>Skydd<\/strong><\/td>\n      <td>B\u00e4sta m\u00f6jliga skydd mot \u00e5terkrav under tr\u00f6skelv\u00e4rdet<\/td>\n      <td>Viktig middleware, cacher, centrala tj\u00e4nster<\/td>\n    <\/tr>\n    <tr>\n      <td>minne.min<\/td>\n      <td>H\u00e5rdare <strong>Skydd<\/strong><\/td>\n      <td>Ingen \u00e5tervinning under tr\u00f6skelv\u00e4rdet; OOM drabbar snarare andra grupper<\/td>\n      <td>Kritiska nyckelkomponenter<\/td>\n    <\/tr>\n    <tr>\n      <td>memory.current<\/td>\n      <td>Live-<strong>V\u00e4rde<\/strong><\/td>\n      <td>Visar aktuell anv\u00e4ndning; underlag f\u00f6r larm och inst\u00e4llningar<\/td>\n      <td>Dashboards, trendanalyser<\/td>\n    <\/tr>\n    <tr>\n      <td>memory.oom.group<\/td>\n      <td>Kill-<strong>Omfattning<\/strong><\/td>\n      <td>Sammanst\u00e4ller OOM-kills p\u00e5 gruppniv\u00e5<\/td>\n      <td>Konsekvent avslutning av sammanh\u00e4ngande 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>Att f\u00f6rst\u00e5 hierarkier och arv<\/h2>\n\n<p>Jag organiserar cgroups <strong>hierarkiskt<\/strong>: \u00d6verordnade grupper s\u00e4tter ramarna, barnen \u00e4rver gr\u00e4nser och delar p\u00e5 det tillg\u00e4ngliga minnet. Denna struktur g\u00f6r riktlinjerna f\u00f6ruts\u00e4gbara, men kr\u00e4ver tydliga regler. F\u00f6r\u00e4ldrarnas `memory.max` begr\u00e4nsar summan av barnen; `memory.low` och `memory.min` fungerar vid konkurrens p\u00e5 syskonplanet som <strong>Prioriteringar<\/strong>: En grupp med h\u00f6gre skyddsniv\u00e5 beh\u00e5ller oftare sitt basminne, medan mindre viktiga grupper \u00e5teranv\u00e4nds i st\u00f6rre utstr\u00e4ckning. Det hj\u00e4lper mig att s\u00e4kra viktiga v\u00e4gar utan att urholka de globala gr\u00e4nserna.<\/p>\n\n<p>Jag noterar att skyddsv\u00e4rdena <strong>additivt<\/strong> Tanken \u00e4r f\u00f6ljande: F\u00f6r h\u00f6ga v\u00e4rden f\u00f6r memory.min f\u00f6r alla underordnade enheter blockerar \u00e5tervinningen i hierarkin och f\u00f6rskjuter belastningen upp\u00e5t, \u00e4nda upp till v\u00e4rddatorn. D\u00e4rf\u00f6r kalibrerar jag skyddsbudgetarna per niv\u00e5 och l\u00e4mnar alltid en buffert ledig. I stegmodeller definierar jag klasser (kritisk, viktig, best effort) och till\u00e4mpar konsekventa bandbredder och skyddstr\u00f6sklar f\u00f6r varje klass. P\u00e5 s\u00e5 s\u00e4tt f\u00f6rblir lastf\u00f6rdelningen r\u00e4ttvis och transparent \u2013 \u00e4ven om teamen sj\u00e4lva hanterar undergrupper.<\/p>\n\n<h2>Strikt gr\u00e4ns: st\u00e4lla in memory.max korrekt<\/h2>\n\n<p>Jag st\u00e4ller in <strong>minne.max<\/strong> s\u00e5 att processen har tillr\u00e4ckligt med utrymme f\u00f6r toppar, men utan att dominera servern. F\u00f6r detta m\u00e4ter jag realistiska toppar, l\u00e4gger till en reserv och begr\u00e4nsar sedan konsekvent. Om en tj\u00e4nst n\u00e5r denna \u00f6vre gr\u00e4ns uteblir tilldelningar och k\u00e4rnan avslutar lokala processer inom gruppen. Denna inkapselning f\u00f6rhindrar dominoeffekter p\u00e5 andra arbetsbelastningar. F\u00f6r minneskr\u00e4vande tj\u00e4nster inneb\u00e4r detta en tydlig <strong>S\u00e4kerhet<\/strong> utan tv\u00e4rg\u00e5ende skador.<\/p>\n\n<p>F\u00f6r stora heap eller cacheminnen planerar jag medvetet in buffertar, eftersom sopuppsamling och bakgrundsuppgifter orsakar fluktuationer. Jag validerar gr\u00e4nsen med belastningstester f\u00f6r att undvika OOM-h\u00e4ndelser under normal drift. Om utnyttjandet l\u00e5ngvarigt ligger n\u00e4ra gr\u00e4nsen \u00f6kar jag f\u00f6rst reserven eller minskar den faktiska arbetsm\u00e4ngden. P\u00e5 s\u00e5 s\u00e4tt h\u00e5ller jag felmarginalen liten och effektiviteten h\u00f6g. Denna disciplin l\u00f6nar sig i <strong>Tillg\u00e4nglighet<\/strong> fr\u00e5n.<\/p>\n\n<h2>Mjuk broms: memory.high i vardagen<\/h2>\n\n<p>Med <strong>minne.h\u00f6g<\/strong> s\u00e4tter jag upp en varnings- och bromsgr\u00e4ns f\u00f6re den skarpa kanten. Om gruppen \u00f6verskrider v\u00e4rdet aktiverar k\u00e4rnan Reclaim och saktar ner allokeringarna utan att omedelbart rensa upp. Denna tid anv\u00e4nder jag f\u00f6r att t\u00f6mma cacher, sprida ut batchbelastningen eller s\u00e4nka beg\u00e4randegr\u00e4nserna. P\u00e5 s\u00e5 s\u00e4tt utj\u00e4mnar jag toppar redan innan det blir n\u00f6dv\u00e4ndigt att avbryta processer. Detta f\u00f6rb\u00e4ttrar <strong>Kvalitet p\u00e5 tj\u00e4nster<\/strong> vid pl\u00f6tsliga belastningsv\u00e5gor.<\/p>\n\n<p>Jag v\u00e4ljer ett m\u00e4rkbart avst\u00e5nd mellan memory.high och memory.max s\u00e5 att systemet har ett reellt handlingsutrymme. Om avst\u00e5ndet \u00e4r f\u00f6r litet hamnar jag f\u00f6r snabbt i OOM-l\u00e4ge. Om det \u00e4r f\u00f6r stort tappar jag kontrollen \u00f6ver latenserna. Jag testar b\u00e5da alternativen i produktionsprofiler och kalibrerar den optimala inst\u00e4llningen. P\u00e5 s\u00e5 s\u00e4tt skapar jag en tillf\u00f6rlitlig <strong>Gasreglage<\/strong>, som tr\u00e4der i kraft i r\u00e4tt tid.<\/p>\n\n<h2>Swap-policy: v\u00e4lj memory.swap.max medvetet<\/h2>\n\n<p>Jag best\u00e4mmer om och i vilken utstr\u00e4ckning en grupp <strong>Byta<\/strong> f\u00e5r anv\u00e4nda. Med memory.swap.max begr\u00e4nsar jag utlagringen separat fr\u00e5n RAM-gr\u00e4nsen. Om jag s\u00e4tter v\u00e4rdet till 0 f\u00f6rbjuder jag swap f\u00f6r gruppen \u2013 vilket \u00e4r l\u00e4mpligt f\u00f6r latensk\u00e4nsliga tj\u00e4nster som inte f\u00e5r blockeras. Om jag till\u00e5ter m\u00e5ttlig swap f\u00e5r jag \u00f6kad flexibilitet f\u00f6r cacher och sidor som s\u00e4llan anv\u00e4nds. Det \u00e4r viktigt att jag <strong>br\u00e5dskande<\/strong> k\u00e4nner till arbetsbelastningarna: Databaser och JVM:er drar ofta nytta av en strikt eller mycket sn\u00e4v swap-policy, medan batch- eller rapporteringsjobb hanterar utlagring p\u00e5 ett mer flexibelt s\u00e4tt.<\/p>\n\n<p>Jag anpassar swap-strategin efter v\u00e4rdkonfigurationen (t.ex. swappiness, zram\/zswap) f\u00f6r att undvika att \u00e5tg\u00e4rderna motverkar varandra. \u00d6verdriven swap d\u00f6ljer minnesbrist endast p\u00e5 kort sikt och f\u00f6rskjuter belastningen till I\/O \u2013 jag anv\u00e4nder den m\u00e5lmedvetet som <strong>Buffert<\/strong>, inte som ett permanent tillst\u00e5nd. M\u00e4tv\u00e4rden som \u201dMajor Page Faults\u201d och latenser visar snabbt om swap hj\u00e4lper eller bromsar. P\u00e5 s\u00e5 s\u00e4tt beh\u00e5ller jag kontrollen \u00f6ver f\u00f6rdr\u00f6jningar och svanslatenser.<\/p>\n\n<h2>Skyddsgr\u00e4nser: memory.low och memory.min<\/h2>\n\n<p>Jag anv\u00e4nder <strong>minne.l\u00e5g<\/strong>, f\u00f6r att s\u00e4kerst\u00e4lla basminnet f\u00f6r viktiga tj\u00e4nster. S\u00e5 l\u00e4nge anv\u00e4ndningen ligger under denna gr\u00e4ns skonar k\u00e4rnan denna andel och \u00e5tervinner hellre minne p\u00e5 andra st\u00e4llen. F\u00f6r komponenter med h\u00f6g prioritet anv\u00e4nder jag dessutom memory.min. Denna strikta skyddsgr\u00e4ns g\u00f6r det tydligt f\u00f6r k\u00e4rnan att jag inte till\u00e5ter n\u00e5gon \u00e5tervinning h\u00e4r. P\u00e5 s\u00e5 s\u00e4tt f\u00f6rblir k\u00e4rnan i en applikation funktionsduglig \u00e4ven under extrem belastning och <strong>lyh\u00f6rd<\/strong>.<\/p>\n\n<p>Jag fastst\u00e4ller viktningen medvetet: centrala databaser f\u00e5r \u201dmemory.min\u201d, kritisk middleware \u201dmemory.low\u201d och icke-kritiska batchjobb f\u00e5r inget extra skydd. Denna prioritering underl\u00e4ttar beslutsfattandet vid resursbrist. Om ett OOM-fel intr\u00e4ffar skyddar denna klassificering mina nyckelv\u00e4gar. Jag beh\u00e5ller kontrollen \u00f6ver vem som f\u00f6rst avst\u00e5r minne. Det ger mig tydliga <strong>Prioriteringar<\/strong> vid flaskhalsar.<\/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>\u00d6ppenhet: memory.current i \u00f6vervakningen<\/h2>\n\n<p>Jag l\u00e4ste <strong>memory.current<\/strong> Jag analyserar det kontinuerligt och korrelerar det med applikationsm\u00e5tt. P\u00e5 s\u00e5 s\u00e4tt uppt\u00e4cker jag trender, uppbyggnad av backlog och toppar. Om systemet registrerar allt fler \u00f6verskridanden av memory.high eller OOM-h\u00e4ndelser justerar jag gr\u00e4nsv\u00e4rdena eller arbetsbelastningen. Dashboarder och larm ger mig ett f\u00f6rspr\u00e5ng inf\u00f6r st\u00f6rningar. Utifr\u00e5n dessa data drar jag slutsatser <strong>Tuning<\/strong>-beslut som p\u00e5 l\u00e5ng sikt f\u00f6rhindrar avbrott.<\/p>\n\n<p>F\u00f6rutom sj\u00e4lva v\u00e4rdet h\u00e5ller jag koll p\u00e5 antalet sidfel, cachetr\u00e4fffrekvensen och latenserna. Denna \u00f6versikt visar om \u00e5tervinningen bromsar systemet f\u00f6r mycket eller om skyddsmekanismerna tr\u00e4der i kraft. Jag justerar intervall och tr\u00f6skelv\u00e4rden tills larmsignalerna \u00e4r anv\u00e4ndbara och inte st\u00f6rande. D\u00e4refter automatiserar jag mot\u00e5tg\u00e4rder som cache-trimning eller k\u00f6begr\u00e4nsning. P\u00e5 s\u00e5 s\u00e4tt f\u00f6rblir reaktionen snabb och <strong>riktade<\/strong>.<\/p>\n\n<h2>Telemetri i detalj: memory.stat, memory.events och PSI<\/h2>\n\n<p>Jag kompletterar memory.current med <strong>memory.stat<\/strong> och <strong>memory.events<\/strong>, f\u00f6r att identifiera orsakerna ist\u00e4llet f\u00f6r bara symptomen. memory.stat delar upp anv\u00e4ndningen efter Anon, File-Cache, Slab och andra kategorier. Utifr\u00e5n dessa andelar kan jag avl\u00e4sa om allokeringarna f\u00f6r en applikation eller sidcachen \u00f6kar \u2013 och justera inst\u00e4llningarna d\u00e4refter (t.ex. cache-storlekar kontra antal arbetare). memory.events och memory.events.local r\u00e4knar utl\u00f6sare som \u00f6verskridanden av low\/high\/max samt <strong>oom<\/strong> och <strong>oom_kill<\/strong>. Det ger tillf\u00f6rlitliga utl\u00f6sare f\u00f6r larm och automatisk \u00e5tg\u00e4rd.<\/p>\n\n<p>Jag anv\u00e4nder ocks\u00e5 <strong>PSI<\/strong> (Pressure Stall Information) f\u00f6r att kvantifiera trycket ist\u00e4llet f\u00f6r att gissa. Om Memory-PSI-v\u00e4rdena stiger kontinuerligt drabbas tr\u00e5dar av v\u00e4ntetider p\u00e5 sidor; jag minskar arbetsbelastningen, \u00f6kar memory.high eller avlastar bandbredden i pipelinen. Sammantaget skapas en telemetri som ger mig gradvis <strong>Tidiga varningar<\/strong> ger \u2013 innan strikta gr\u00e4nser tr\u00e4der i kraft.<\/p>\n\n<h2>Containrar och orkestrering<\/h2>\n\n<p>Om jag st\u00e4ller in minnesgr\u00e4nser i Kubernetes blir de <strong>cgroup<\/strong>-V\u00e4rden som memory.max och, i f\u00f6rekommande fall, memory.high i runtime. Orkestreringen till\u00e4mpar policyer per pod, medan jag definierar detaljinst\u00e4llningarna per namnomr\u00e5de eller distribution. F\u00f6r tillf\u00f6rlitliga SLO:er kopplar jag gr\u00e4nsv\u00e4rden till HPA-strategier och pod-budgetar. Denna helhetsstrategi f\u00f6rhindrar att enskilda podar dominerar minnet. En bra introduktion till <a href=\"https:\/\/webhosting.de\/sv\/cgroups-hosting-resursisolering-linux-containerbegraensningar-serverboost\/\">Resursisolering med cgroups<\/a> underl\u00e4ttar planeringen av containrar med tydliga gr\u00e4nser och infarter.<\/p>\n\n<p>Jag kontrollerar dessutom om sidecars och init-containrar f\u00e5r egna gr\u00e4nsv\u00e4rden, s\u00e5 att hj\u00e4lpprocesser inte begr\u00e4nsar k\u00e4rnarbetsbelastningarna. F\u00f6r tillst\u00e5ndsberoende arbetsbelastningar st\u00e4ller jag in memory.low eller memory.min, s\u00e5 att cacher och buffertar inte krymper omedelbart. Jag dokumenterar dessa beslut i distributionen s\u00e5 att teamet l\u00e4tt kan f\u00f6rst\u00e5 dem. P\u00e5 s\u00e5 s\u00e4tt s\u00e4kerst\u00e4ller jag <strong>Samst\u00e4mmighet<\/strong> mellan infrastruktur och applikation. Resultatet blir f\u00f6ruts\u00e4gbara arbetsbelastningsprofiler.<\/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 och automatisering<\/h2>\n\n<p>Jag anv\u00e4nder systemd f\u00f6r att deklarativt st\u00e4lla in cgroup v2-parametrar: <strong>MemoryMax<\/strong> motsvarar memory.max, <strong>MinneH\u00f6g<\/strong> memory.high, <strong>MemoryLow<\/strong> och <strong>MemoryMin<\/strong> fastst\u00e4ller skyddslinjer, <strong>MemorySwapMax<\/strong> hanteras av Swap. Denna struktur g\u00f6r policyerna tydliga i kodf\u00f6rvaret och underl\u00e4ttar \u00e5terst\u00e4llningar. I st\u00f6rre milj\u00f6er anv\u00e4nder jag den f\u00f6r att samordna enhetliga <strong>Standarder<\/strong> per serviceklass och separera driften fr\u00e5n manuella ingrepp.<\/p>\n\n<p>F\u00f6r automatiska ingrepp kombinerar jag h\u00e4ndelser fr\u00e5n memory.events\/PSI med policy-motorer. Om en grupp upprepade g\u00e5nger \u00f6verskrider memory.high minskar jag antalet arbetare parallellt, begr\u00e4nsar burst-hastigheter eller utl\u00f6ser <strong>riktade<\/strong> Cache-Trim. Om dessa niv\u00e5er inte fungerar l\u00e5ter jag systemets egna OOM-mekanismer verka p\u00e5 ett kontrollerat s\u00e4tt \u2013 tack vare memory.oom.group f\u00f6rblir effekten lokal och f\u00f6ruts\u00e4gbar. P\u00e5 s\u00e5 s\u00e4tt uppst\u00e5r ett stegvis, sj\u00e4lvl\u00e4kande beteende utan \u00f6verraskningar.<\/p>\n\n<h2>Hosting f\u00f6r flera kunder med CloudLinux<\/h2>\n\n<p>Jag isolerar kundmilj\u00f6erna i separata <strong>cgroups<\/strong> och tilldelar tydliga gr\u00e4nser f\u00f6r varje tenant. CloudLinux kompletterar detta med verktyg som avgr\u00e4nsar RAM, CPU och IO f\u00f6r varje konto. P\u00e5 s\u00e5 s\u00e4tt h\u00e5lls grannskapseffekterna under kontroll, och enstaka utslag drar inte med sig alla konton. Den som vill f\u00f6rdjupa sig hittar en praktisk \u00f6versikt \u00f6ver <a href=\"https:\/\/webhosting.de\/sv\/cgroup-v2-cloudlinux-delad-hosting-stabil\/\">CloudLinux och cgroup v2<\/a> i samband med delad hosting. P\u00e5 s\u00e5 s\u00e4tt kan jag uppr\u00e4tth\u00e5lla r\u00e4ttvisa <strong>Resurser<\/strong>-F\u00f6rdelning \u00f6ver m\u00e5nga kunder.<\/p>\n\n<p>Jag st\u00e4ller in `memory.max` per kund utifr\u00e5n den uppm\u00e4tta dagliga profilen, anger `memory.low` f\u00f6r cacher och skyddar k\u00e4rnprocesser med `memory.min`. Vid gr\u00e4ns\u00f6verskridningar stryps f\u00f6rst fl\u00f6det med hj\u00e4lp av strypning, ist\u00e4llet f\u00f6r att kraftigt bromsa kontona. Om ett OOM-fel intr\u00e4ffar drabbas endast den ber\u00f6rda gruppen lokalt. P\u00e5 s\u00e5 s\u00e4tt f\u00f6rblir plattformen anv\u00e4ndbar f\u00f6r andra hyresg\u00e4ster. Denna metod st\u00e4rker <strong>Planerbarhet<\/strong> i f\u00f6rh\u00e5llande till trafiktoppar.<\/p>\n\n<h2>S\u00e4rskilda fall: sidcache, THP och stora sidor<\/h2>\n\n<p>Jag skiljer mellan <strong>Anon<\/strong>-minnen (heaps, stacks) och <strong>Filcache<\/strong> (sidcache). Under h\u00f6g belastning \u00e4r det l\u00e4ttare att frig\u00f6ra filcache, medan anonyma sidor kr\u00e4ver swap eller leder till OOM. memory.high och skyddsgr\u00e4nser hj\u00e4lper mig att minska filcachen utan att p\u00e5verka kritiska heap. N\u00e4r det g\u00e4ller Transparent Huge Pages (THP) kontrollerar jag om de gynnar applikationen eller \u00f6kar fragmenteringen och latensen \u2013 beroende p\u00e5 profilen anpassar jag THP-policyn s\u00e5 att samspelet med minneskontrollern f\u00f6rblir harmoniskt.<\/p>\n\n<p>Anv\u00e4nd en applikation <strong>Hugepages<\/strong> Uttryckligen isolerar jag deras behov via de tillh\u00f6rande styrenheterna separat fr\u00e5n RAM-kontrollen. P\u00e5 s\u00e5 s\u00e4tt f\u00f6rhindrar jag att stora sidor tr\u00e4nger undan det vanliga arbetsminnet. Jag h\u00e5ller dessa specialreserver knappt dimensionerade och samordnar dem med de \u00f6vriga gr\u00e4nserna, s\u00e5 att det inte uppst\u00e5r ov\u00e4ntade flaskhalsar. Sammantaget skapas tydliga riktlinjer f\u00f6r vanlig och s\u00e4rskild minnesanv\u00e4ndning.<\/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>B\u00e4sta praxis f\u00f6r gr\u00e4nsv\u00e4rden<\/h2>\n\n<p>Jag utg\u00e5r fr\u00e5n verkliga f\u00f6rbrukningsprofiler och utg\u00e5r fr\u00e5n <strong>minne.max<\/strong> med en reserv, s\u00e5 att toppar inte omedelbart utl\u00f6ser OOM. Jag s\u00e4tter memory.high m\u00e4rkbart l\u00e4gre f\u00f6r att j\u00e4mna ut belastningsv\u00e5gor och bromsa allokeringarna. Det \u00e4r viktigt att prioritera: databasen tilldelas memory.min, middleware memory.low, medan batchbelastningen inte ges n\u00e5gon s\u00e4rskild roll. \u00d6vervakningen f\u00f6ljer driften och visar om tr\u00f6skelv\u00e4rdena fungerar eller om de \u00e4r f\u00f6r str\u00e4nga. Utifr\u00e5n dessa signaler justerar jag gr\u00e4nserna och \u00f6kar samtidigt <strong>Effektivitet<\/strong> i applikationen.<\/p>\n\n<p>Jag dokumenterar v\u00e4rdena f\u00f6r varje tj\u00e4nst, beskriver motiveringarna och registrerar \u00e4ndringarna p\u00e5 ett \u00f6versk\u00e5dligt s\u00e4tt. P\u00e5 s\u00e5 s\u00e4tt f\u00f6rankrar jag besluten i teamet och f\u00f6rhindrar att man m\u00e5ste gissa sig fram efter flera veckor. Innan uppdateringar eller arkitekturf\u00f6r\u00e4ndringar tittar jag p\u00e5 utvecklingskurvorna f\u00f6r att inte sk\u00e4rpa eller l\u00e4tta p\u00e5 kraven i blindo. En liten testmilj\u00f6 sparar mycket besv\u00e4r senare i produktionen. Denna rytm s\u00e4kerst\u00e4ller <strong>Constance<\/strong> i den dagliga verksamheten.<\/p>\n\n<h2>Praktik: Strukturera webbhotellsservrar<\/h2>\n\n<p>Jag skapar en separat f\u00f6r varje kund <strong>cgroup<\/strong> och flyttar PHP-FPM, databasen och cachen dit. Jag tilldelar varje upps\u00e4ttning memory.max plus buffert, medan memory.high tr\u00e4der i kraft tidigare och j\u00e4mnar ut sv\u00e4ngningar. Kundens kritiska tj\u00e4nster f\u00e5r skyddsgr\u00e4nser s\u00e5 att deras k\u00e4rnminne inte sjunker. Loggar och instrumentpaneler visar vem som bromsar, vem som drar ig\u00e5ng och var det finns risk f\u00f6r OOM. Dessutom hj\u00e4lper tips om <a href=\"https:\/\/webhosting.de\/sv\/server-sammanhang-isolering-namnrymder-cgroups-hosting-saekerhet\/\">Namnrymder och isoleringskoncept<\/a>, s\u00e5 att klienterna f\u00f6rblir tydligt \u00e5tskilda och <strong>S\u00e4kerhet<\/strong> \u00f6kar.<\/p>\n\n<p>Jag justerar dessutom antalet PHP-arbetare, OPcache-storlekar och fr\u00e5gecacher f\u00f6r att minska minnesanv\u00e4ndningen. Ofta r\u00e4cker det med att minska toppbelastningarna via memory.high f\u00f6r att korta ner tiden. F\u00f6r tester anv\u00e4nder jag verkliga belastningsm\u00f6nster, inte syntetiska idealv\u00e4rden. D\u00e4refter dokumenterar jag nya gr\u00e4nsv\u00e4rden och kopplar dem till SLA:er. P\u00e5 s\u00e5 s\u00e4tt v\u00e4xer <strong>\u00d6ppenhet<\/strong> gentemot kunder och intern support.<\/p>\n\n<h2>Fels\u00f6kning vid minnesutskrift<\/h2>\n\n<p>Stiger <strong>memory.current<\/strong> N\u00e4r problem uppst\u00e5r snabbt kontrollerar jag f\u00f6rst om det skett n\u00e5gra f\u00f6r\u00e4ndringar i trafiken, i drifts\u00e4ttningarna eller i konfigurationerna. Jag j\u00e4mf\u00f6r kurvorna f\u00f6r \u00f6verskridanden av h\u00f6gsta v\u00e4rden, sidfel och latenser. Om OOM-fel upptr\u00e4der i serie identifierar jag de drabbade processerna via k\u00e4rnloggen och justerar gr\u00e4nsv\u00e4rden eller arbetsbelastningen. Om orsaken ligger i felaktiga cacher trimmar jag specifikt ist\u00e4llet f\u00f6r att l\u00f6sa problemet globalt. Denna diagnoskedja leder mig snabbt till <strong>Orsak<\/strong>, inte bara ett symptom.<\/p>\n\n<p>Om belastningen f\u00f6rblir h\u00f6g f\u00f6rdelar jag arbetet: s\u00e4tter burst-gr\u00e4nser f\u00f6r Ingress, minskar k\u00f6ernas l\u00e4ngd och skjuter upp batchjobb. Samtidigt \u00f6kar jag memory.high tillf\u00e4lligt f\u00f6r att vinna tid utan att h\u00f6ja memory.max. Om jag uppt\u00e4cker minnesl\u00e4ckor sk\u00e4rper jag s\u00e4kerhetsgr\u00e4nserna tills en l\u00f6sning finns. I sv\u00e5rl\u00f6sta fall minskar jag tj\u00e4nstens omfattning eller replikerar instansen. P\u00e5 s\u00e5 s\u00e4tt h\u00e5ller jag <strong>Drift<\/strong> fungerar p\u00e5litligt, \u00e4ven under press.<\/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: H\u00e4ndelsestyrda mot\u00e5tg\u00e4rder<\/h2>\n\n<p>Jag knyter <strong>\u00c5tg\u00e4rder<\/strong> H\u00e4ndelser: memory.events tillhandah\u00e5ller r\u00e4knare som jag bearbetar via en watcher eller en metrikpipeline. Vid upprepade \u201dhigh-hits\u201d t\u00f6mmer jag specifika cacher, s\u00e4nker samtidigheten eller initierar \u00e5tervinningsf\u00f6rs\u00f6k innan anv\u00e4ndarna hinner m\u00e4rka n\u00e5got. Om milda ingripanden misslyckas g\u00e5r jag \u00f6ver till h\u00e5rda \u00e5tg\u00e4rder: beg\u00e4ranstopp, k\u00f6avlastning, prioriterings\u00e4ndringar. Det viktiga \u00e4r att besluten <strong>deterministisk<\/strong> \u00e4r \u2013 samma utl\u00f6sande faktorer, samma reaktion \u2013 s\u00e5 att teamen kan f\u00f6rst\u00e5 och \u00e5terge beteendet.<\/p>\n\n<p>Jag beh\u00e5ller dessutom <strong>Omfattning<\/strong> med fokus p\u00e5 OOM. Med memory.oom.group undviker jag partiella avst\u00e4ngningar som f\u00f6rs\u00e4tter applikationer i inkonsekventa tillst\u00e5nd. Om n\u00e5got m\u00e5ste avslutas ska det ske p\u00e5 ett sammanh\u00e4ngande och snabbt s\u00e4tt, s\u00e5 att \u00e5terst\u00e5ende kapacitet snabbt blir tillg\u00e4nglig igen. I kombination med telemetri och dokumenterade playbooks skapas en robust \u00e5terkopplingsslinga som fungerar under verkliga produktionsf\u00f6rh\u00e5llanden.<\/p>\n\n<h2>Utsikter och sammanfattning<\/h2>\n\n<p>Minneskontrollern fr\u00e5n <strong>cgroup<\/strong> v2 ger mig ett differentierat verktygsl\u00e5da: h\u00e5rda gr\u00e4nser, mjuka bromsar och skyddslinjer med tydlig prioritering. Om jag medvetet anv\u00e4nder memory.max, memory.high, memory.low och memory.min kan jag reagera p\u00e5 ett strukturerat s\u00e4tt p\u00e5 pl\u00f6tsliga belastnings\u00f6kningar och se till att tj\u00e4nsterna f\u00f6rblir funktionsdugliga. \u00d6vervakning via memory.current avsl\u00f6jar i ett tidigt skede var gr\u00e4nserna b\u00f6rjar bli tr\u00e5nga eller d\u00e4r reserver saknas. I container- och multitenant-milj\u00f6er s\u00e4kerst\u00e4ller dessa mekanismer en r\u00e4ttvis resursf\u00f6rdelning utan att andra delar p\u00e5verkas negativt. Med disciplin, m\u00e4tv\u00e4rden och sm\u00e5 korrigeringssteg uppn\u00e5r jag tillf\u00f6rlitlig <strong>Prestanda<\/strong> \u2013 fr\u00e5n en enskild virtuell maskin till en fullbelagd v\u00e4rd.<\/p>","protected":false},"excerpt":{"rendered":"<p>L\u00e4r dig hur Linux cgroup v2 Memory Controller fungerar och hur du kan skapa stabila hosting- och containermilj\u00f6er med hj\u00e4lp av v\u00e4l avgr\u00e4nsade resursbegr\u00e4nsningar i Linux.<\/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":"226","_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\/sv\/wp-json\/wp\/v2\/posts\/21199","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/comments?post=21199"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/posts\/21199\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/media\/21192"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/media?parent=21199"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/categories?post=21199"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/tags?post=21199"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}