{"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":"uitleg-over-de-linux-cgroup-v2-geheugencontroller-en-de-focus-op-hostingbronnen","status":"publish","type":"post","link":"https:\/\/webhosting.de\/nl\/linux-cgroup-v2-memory-controller-erklaerung-hosting-resourcen-focus\/","title":{"rendered":"Linux cgroup v2 Memory Controller uitgelegd \u2013 Hulpbronnen netjes beperken"},"content":{"rendered":"<p>Ik leg uit hoe <strong>cgroep v2<\/strong> met zijn geheugencontroller geheugenlimieten netjes implementeert, diensten beschermt en lokale OOM-gebeurtenissen afschermt. Zo kunnen beheerders duidelijke <strong>Bronnen<\/strong>-regels vaststellen, piekbelastingen op gecontroleerde wijze afremmen en kritieke processen beveiligen tegen een tekort aan opslagcapaciteit.<\/p>\n\n<h2>Centrale punten<\/h2>\n<p>De volgende lijst geeft een overzicht van de belangrijkste punten die ik in het artikel concreet toelicht.<\/p>\n<ul>\n  <li><strong>Gestandaardiseerd<\/strong> Architectuur: cgroup v2 vereenvoudigt de besturing en monitoring.<\/li>\n  <li><strong>Hard<\/strong> Beperking: memory.max voorkomt ongecontroleerde toewijzingen.<\/li>\n  <li><strong>Zacht<\/strong> Rem: memory.high vermindert de druk zonder dat dit direct tot uitval leidt.<\/li>\n  <li><strong>Gerichter<\/strong> Beveiliging: memory.low en memory.min geven voorrang aan diensten.<\/li>\n  <li><strong>Transparant<\/strong> Controle: memory.current levert meetwaarden voor het afstellen.<\/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>Wat cgroup v2 anders doet op het gebied van geheugen<\/h2>\n\n<p>Ik vat processen samen in <strong>Controle<\/strong> Groepen samenvoegen en hun geheugenbehoefte als \u00e9\u00e9n geheel beheren. Met versie v2 standaardiseert de kernel interfaces, waardoor ik limieten, beveiligingsdrempels en telemetrie op een consistente manier kan toepassen. De geheugenlogica maakt een onderscheid tussen harde afscherming en zachte remmen, waardoor toewijzingen niet onmiddellijk worden afgebroken, maar op een geordende manier worden vertraagd. Zo reageer ik op uitschieters zonder het totale systeem te be\u00efnvloeden, omdat het be\u00ebindigen van processen lokaal plaatsvindt binnen de betreffende groep. Voor hosting en containers biedt dit de voorspelbare <strong>Bronnen<\/strong>-Verdeling en voorspelbare reacties op belastingssprongen.<\/p>\n\n<p>Ik maak gebruik van deze eigenschappen om diensten met een vergelijkbaar profiel te bundelen en duidelijke regels vast te stellen. Containers, PHP-workers en databaseprocessen scheid ik netjes van elkaar, zodat elke set workloads zijn eigen grenzen heeft. Zo voorkom ik kruisinvloeden, zoals algemene opslagdruk die onschuldige taken treft. Deze isolatie kan stapsgewijs worden verfijnd, totdat de belastingverdeling voorspelbaar reageert. Hierdoor win ik <strong>Voorspelbaarheid<\/strong> in bedrijf en zorg ervoor dat de servicekwaliteit tijdens piekbelasting op peil blijft.<\/p>\n\n<h2>De belastingbestanden in \u00e9\u00e9n oogopslag<\/h2>\n\n<p>Bij het beheer van de opslagruimte draait het om een paar <strong>Parameters<\/strong>, die ik in het cgroup-bestandssysteem instel. Elke cgroup krijgt zijn eigen waarden voor harde limieten, zachte rempunten en beschermingsgrenzen. Zo schaal ik van milde terugwinning tot compromisloze afscherming, afhankelijk van het belang van de dienst. Het monitoringsysteem leest tegelijkertijd het actuele verbruik uit en geeft een alarm af wanneer de beschermingsdrempels worden bereikt. Zo ontstaat een gesloten regelkring van specificaties en meetwaarden, die <strong>Bronnen<\/strong>-het verbruik beheersbaar maakt.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Parameters<\/th>\n      <th>Vriendelijk<\/th>\n      <th>Effect<\/th>\n      <th>Typisch gebruik<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>geheugen.max<\/td>\n      <td>Hard <strong>Grens<\/strong><\/td>\n      <td>Blokkeert nieuwe toewijzingen boven de limiet; lokale OOM-kill<\/td>\n      <td>Databases, JVM's, PHP-FPM-pools met duidelijke limieten<\/td>\n    <\/tr>\n    <tr>\n      <td>geheugen.hoog<\/td>\n      <td>Zacht <strong>rem<\/strong><\/td>\n      <td>Verhoogt de \u2018Reclaim\u2019 en de latentie bij toewijzingen; geen onmiddellijke \u2018kills\u2019<\/td>\n      <td>Geleidelijke afbouw om escalatie te voorkomen<\/td>\n    <\/tr>\n    <tr>\n      <td>geheugen.laag<\/td>\n      <td>Zacht<strong>Bescherming<\/strong><\/td>\n      <td>De best mogelijke bescherming tegen terugvordering onder de drempel<\/td>\n      <td>Belangrijke middleware, caches, centrale diensten<\/td>\n    <\/tr>\n    <tr>\n      <td>geheugen.min<\/td>\n      <td>Harder <strong>Bescherming<\/strong><\/td>\n      <td>Geen Reclaim onder de drempel; OOM treft eerder andere groepen<\/td>\n      <td>Kritieke kerncomponenten<\/td>\n    <\/tr>\n    <tr>\n      <td>memory.current<\/td>\n      <td>Live-<strong>Waarde<\/strong><\/td>\n      <td>Geeft het huidige verbruik weer; basis voor waarschuwingen en afstelling<\/td>\n      <td>Dashboards, trendanalyses<\/td>\n    <\/tr>\n    <tr>\n      <td>memory.oom.group<\/td>\n      <td>Kill-<strong>Reikwijdte<\/strong><\/td>\n      <td>Telt OOM-kills op groepsniveau bij elkaar op<\/td>\n      <td>Consistente be\u00ebindiging van samenhangende processen<\/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>Hi\u00ebrarchie\u00ebn en overerving begrijpen<\/h2>\n\n<p>Ik stel cgroups in <strong>hi\u00ebrarchisch<\/strong>: Bovenliggende groepen bepalen het kader; kinderen nemen de limieten over en delen de beschikbare opslagruimte. Deze structuur maakt de richtlijnen voorspelbaar, maar vereist wel duidelijke regels. memory.max van de ouders beperkt de som van de kinderen; memory.low en memory.min fungeren bij concurrentie op het niveau van de broers en zussen als <strong>Prioriteiten<\/strong>: Een groep met een hoger beschermingsniveau behoudt eerder haar basispgeheugen, terwijl minder belangrijke groepen vaker worden vrijgemaakt. Dit helpt mij om kernpaden te beveiligen zonder de globale limieten te verzwakken.<\/p>\n\n<p>Ik merk op dat de veiligheidswaarden <strong>additief<\/strong> bedoeld zijn: te hoge waarden voor memory.min voor alle onderliggende elementen blokkeren het vrijmaken van geheugen in de hi\u00ebrarchie en verplaatsen de druk naar boven, tot aan de host. Daarom stel ik beschermingsbudgetten per niveau in en houd ik altijd een buffer vrij. In trapsgewijze modellen definieer ik klassen (kritiek, belangrijk, best effort) en pas ik consistente bandbreedtes en beschermingsdrempels per klasse toe. Hierdoor blijft de lastverdeling eerlijk en transparant \u2013 ook als teams zelfstandig subgroepen beheren.<\/p>\n\n<h2>Strikte limiet: memory.max correct instellen<\/h2>\n\n<p>Ik stel <strong>geheugen.max<\/strong> zodat het proces voldoende ruimte heeft voor pieken, maar de server niet overbelast. Hiervoor meet ik realistische pieken, tel daar een reserve bij op en pas vervolgens consequent een limiet toe. Als een dienst deze bovengrens bereikt, worden er geen toewijzingen meer gedaan en be\u00ebindigt de kernel lokale processen binnen de groep. Deze afscherming voorkomt domino-effecten op andere workloads. Voor diensten die veel geheugen verbruiken, biedt dit een duidelijke <strong>Beveiliging<\/strong> zonder zijdelingse schade.<\/p>\n\n<p>Voor grote heaps of caches bouw ik bewust buffers in, omdat garbage collection en achtergrondtaken schommelingen veroorzaken. Ik valideer de limiet met belastingstests, zodat er tijdens normaal gebruik geen OOM-incidenten optreden. Als het gebruik blijvend dicht bij de limiet blijft, verhoog ik eerst de reserve of verminder ik de daadwerkelijke werklast. Zo houd ik de foutmarge klein en de effici\u00ebntie hoog. Deze discipline loont zich in <strong>Beschikbaarheid<\/strong> van.<\/p>\n\n<h2>Zachte rem: memory.high in het dagelijks leven<\/h2>\n\n<p>Met <strong>geheugen.hoog<\/strong> Ik stel een waarschuwings- en rempunt in v\u00f3\u00f3r de harde grens. Als de groep deze waarde overschrijdt, treedt de kernel-reclaim in werking en vertraagt deze de toewijzingen, zonder meteen op te ruimen. Deze tijd gebruik ik om caches leeg te maken, batch-belasting te spreiden of verzoeklimieten te verlagen. Zo vlak ik pieken af, nog voordat het nodig is om processen te be\u00ebindigen. Dit verbetert de <strong>Servicekwaliteit<\/strong> bij plotselinge belastingspieken.<\/p>\n\n<p>Ik kies een merkbaar verschil tussen memory.high en memory.max, zodat het systeem voldoende speelruimte heeft. Als het verschil te klein is, raak ik te snel OOM. Als het te groot is, verlies ik de controle over de latenties. Ik test beide onder productieprofielen en kalibreer de sweet spot. Zo cre\u00eber ik een betrouwbare <strong>Gashendel<\/strong>, die tijdig in werking treedt.<\/p>\n\n<h2>Swap-beleid: memory.swap.max bewust instellen<\/h2>\n\n<p>Ik bepaal of en in welke mate een groep <strong>Wissel<\/strong> mag gebruiken. Met `memory.swap.max` beperk ik het swappen los van de RAM-limiet. Als ik de waarde op 0 zet, verbied ik swappen voor de groep \u2013 handig voor latentiegevoelige diensten die niet mogen blokkeren. Als ik gematigd swappen toestaat, win ik flexibiliteit voor caches en zelden gebruikte pagina\u2019s. Het is belangrijk dat ik de <strong>urgentie<\/strong> van de workloads: databases en JVM\u2019s hebben vaak baat bij een strikt of zeer strak swapbeleid, terwijl batch- of rapportagetaken wat soepeler omgaan met het gebruik van swapruimte.<\/p>\n\n<p>Ik stem de swap-strategie af op de hostconfiguratie (bijv. swappiness, zram\/zswap), zodat maatregelen elkaar niet tegenspreken. Overmatig gebruik van swap maskeert geheugentekort slechts op korte termijn en verplaatst de belasting naar IO \u2013 ik gebruik het doelgericht als <strong>Buffer<\/strong>, niet als een permanente toestand. Meetwaarden zoals Major Page Faults en latenties laten al snel zien of swap helpt of juist remt. Zo houd ik de vertragingen en tail-latenties onder controle.<\/p>\n\n<h2>Beveiligingsgrenzen: memory.low en memory.min<\/h2>\n\n<p>Ik gebruik <strong>geheugen.laag<\/strong>, om het basisgeheugen voor belangrijke diensten te reserveren. Zolang het gebruik onder deze grens blijft, laat de kernel dit deel met rust en haalt hij liever elders geheugen terug. Voor componenten met een hoge prioriteit gebruik ik bovendien memory.min. Deze strikte beschermingsgrens maakt de kernel duidelijk dat ik hier geen terugwinning toestaat. Zo blijft het hart van een toepassing ook onder extreme belasting operationeel en <strong>responsief<\/strong>.<\/p>\n\n<p>Ik stel de prioriteiten bewust in: centrale databases krijgen memory.min, kritieke middleware memory.low, niet-kritieke batch-taken krijgen geen extra bescherming. Deze prioritering maakt het makkelijker om beslissingen te nemen bij knelpunten. Als er een OOM optreedt, beschermt deze indeling mijn sleutelpaden. Ik behoud de controle over wie als eerste geheugen vrijgeeft. Dat levert me duidelijke <strong>Prioriteiten<\/strong> bij knelpunten.<\/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>Transparantie: memory.current in de monitoring<\/h2>\n\n<p>Ik lees <strong>memory.current<\/strong> Ik analyseer deze gegevens continu en breng ze in verband met applicatiestatistieken. Zo herken ik trends, de opbouw van de backlog en pieken. Als het systeem vaker overschrijdingen van memory.high of OOM-gebeurtenissen registreert, pas ik de limieten of de werklast aan. Dashboards en waarschuwingen geven me een voorsprong op storingen. Uit deze gegevens leid ik <strong>Afstemmen<\/strong>-beslissingen die op de lange termijn uitval voorkomen.<\/p>\n\n<p>Naast de waarde zelf houd ik ook de page-fault-percentages, de cache-hit-ratio en de latenties in de gaten. Dit overzicht laat zien of \u2018Reclaim\u2019 te veel vertraging veroorzaakt of dat de beveiligingsmaatregelen in werking treden. Ik pas de intervallen en drempelwaarden aan totdat de waarschuwingen nuttig zijn en niet meer irritant. Vervolgens automatiseer ik tegenmaatregelen zoals cache-trim of wachtrijbeperking. Zo blijft de reactie snel en <strong>gericht<\/strong>.<\/p>\n\n<h2>Telemetrie uitgediept: memory.stat, memory.events en PSI<\/h2>\n\n<p>Ik voeg het volgende toe aan `memory.current`: <strong>memory.stat<\/strong> en <strong>memory.events<\/strong>, om de oorzaken te achterhalen in plaats van alleen de symptomen. memory.stat splitst het gebruik op in Anon, File-Cache, Slab en andere categorie\u00ebn. Aan de hand van deze percentages kan ik afleiden of de toewijzingen van een toepassing of de paginacache toenemen \u2013 en daarop mijn instellingen aanpassen (bijv. cachegroottes versus aantal workers). memory.events en memory.events.local tellen triggers zoals overschrijdingen van low\/high\/max en <strong>oom<\/strong> en <strong>oom_kill<\/strong>. Dit levert betrouwbare triggers op voor alarmen en automatische herstelmaatregelen.<\/p>\n\n<p>Ik gebruik ook <strong>PSI<\/strong> (Pressure Stall Information), om de druk te kwantificeren in plaats van te gissen. Als de Memory-PSI-waarden blijvend stijgen, ondervinden threads wachttijden op pagina\u2019s; ik beperk de workload, verhoog memory.high of ontlast de bandbreedtes in de pijplijn. Al met al ontstaat er telemetrie die mij geleidelijke <strong>Vroegtijdige waarschuwingen<\/strong> levert \u2013 voordat er strenge beperkingen worden opgelegd.<\/p>\n\n<h2>Containers en orkestratie<\/h2>\n\n<p>Als ik geheugenlimieten instel in Kubernetes, worden deze opgeslagen als <strong>cgroup<\/strong>-waarden zoals `memory.max` en eventueel `memory.high` in de runtime. De orkestratie past beleidsregels per pod toe, terwijl ik de details per namespace of deployment definieer. Voor betrouwbare SLO\u2019s koppel ik limieten aan HPA-strategie\u00ebn en pod-budgetten. Deze alomvattende aanpak voorkomt dat individuele pods het geheugen domineren. Een goede inleiding tot <a href=\"https:\/\/webhosting.de\/nl\/cgroups-hosting-bronisolatie-linux-containerlimieten-serverboost\/\">Isolatie van bronnen met cgroups<\/a> maakt het plannen van containers met duidelijke grenzen en opritten eenvoudiger.<\/p>\n\n<p>Ik controleer bovendien of sidecars en init-containers hun eigen limieten krijgen, zodat ondersteunende processen de kernworkloads niet beperken. Voor stateful workloads stel ik `memory.low` of `memory.min` in, zodat caches en buffers niet onmiddellijk inkrimpen. Ik documenteer deze beslissingen in de deployment, zodat het team ze gemakkelijk begrijpt. Zo zorg ik ervoor dat <strong>Consistentie<\/strong> tussen infrastructuur en applicatie. Dit leidt tot voorspelbare workloadprofielen.<\/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-integratie en automatisering<\/h2>\n\n<p>Ik gebruik systemd om cgroup v2-parameters op een declaratieve manier in te stellen: <strong>MemoryMax<\/strong> komt overeen met memory.max, <strong>GeheugenHoog<\/strong> de memory.high, <strong>MemoryLow<\/strong> en <strong>MemoryMin<\/strong> beschermingslijnen vast, <strong>MemorySwapMax<\/strong> wordt geregeld door Swap. Deze afbeelding maakt het beleid inzichtelijk in de coderepository en vergemakkelijkt het terugdraaien van wijzigingen. In grotere omgevingen gebruik ik dit om consistente <strong>Normen<\/strong> per serviceklasse en ontkoppel de werking van handmatige ingrepen.<\/p>\n\n<p>Voor automatische ingrepen combineer ik events uit memory.events\/PSI met policy-engines. Als een groep herhaaldelijk memory.high overschrijdt, verminder ik tegelijkertijd het aantal workers, beperk ik de burst-rates of activeer ik <strong>gerichte<\/strong> Cache-Trim. Als deze stappen geen effect hebben, laat ik de ingebouwde OOM-mechanismen op een gecontroleerde manier hun werk doen \u2013 dankzij `memory.oom.group` blijft het effect lokaal en voorspelbaar. Zo ontstaat een gefaseerd, zelfherstellend gedrag zonder verrassingen.<\/p>\n\n<h2>Multi-tenant-hosting met CloudLinux<\/h2>\n\n<p>Ik zet klantomgevingen in aparte <strong>cgroups<\/strong> en stel per tenant duidelijke limieten in. CloudLinux vult dit aan met tools die het RAM-geheugen, de CPU en de IO per account afbakenen. Zo blijven naburigheidseffecten beheersbaar en zorgen individuele uitschieters er niet voor dat alle accounts eronder lijden. Wie zich hier verder in wil verdiepen, vindt een praktisch overzicht van <a href=\"https:\/\/webhosting.de\/nl\/cgroup-v2-cloudlinux-shared-hosting-stabiel\/\">CloudLinux en cgroup v2<\/a> in de context van shared hosting. Zo houd ik eerlijke <strong>Bronnen<\/strong>-Verspreid over een groot aantal klanten.<\/p>\n\n<p>Ik stel `memory.max` per klant in op basis van het gemeten dagprofiel, geef caches een `memory.low`-waarde en bescherm kernprocessen met `memory.min`. Bij overschrijding van de limieten worden eerst throttles toegepast, in plaats van accounts hard af te remmen. Als er een OOM optreedt, treft dit lokaal de betreffende groep. Hierdoor blijft het platform voor andere huurders bruikbaar. Deze aanpak versterkt <strong>Planbaarheid<\/strong> ten opzichte van verkeerspieken.<\/p>\n\n<h2>Bijzondere gevallen: paginacache, THP en grote pagina\u2019s<\/h2>\n\n<p>Ik maak onderscheid tussen <strong>Anon<\/strong>-geheugens (heaps, stacks) en <strong>Bestandscache<\/strong> (Paginacache). Onder druk is het gemakkelijker om bestandscache vrij te maken, terwijl anonieme pagina\u2019s swapruimte nodig hebben of tot OOM leiden. memory.high en beschermingslimieten helpen me om bestandscache terug te nemen zonder kritieke heaps aan te tasten. Bij Transparent Huge Pages (THP) controleer ik of ze de toepassing ten goede komen of juist fragmentatie en latentie vergroten \u2013 afhankelijk van het profiel pas ik het THP-beleid aan, zodat de interactie met de geheugencontroller soepel blijft verlopen.<\/p>\n\n<p>Gebruik een toepassing <strong>Hugepages<\/strong> Ik zorg er expliciet voor dat het verbruik hiervan via de bijbehorende controllers losstaat van het RAM-beheer. Zo voorkom ik dat grote pagina\u2019s het reguliere werkgeheugen verdringen. Ik houd deze speciale reserves beperkt en stem ze af op de overige limieten, zodat er geen onverwachte knelpunten ontstaan. Al met al ontstaan er duidelijke richtlijnen voor regulier en speciaal geheugengebruik.<\/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>Best practices voor limieten<\/h2>\n\n<p>Ik begin met echte verbruiksprofielen en ga verder met <strong>geheugen.max<\/strong> met een reserve, zodat pieken niet meteen een OOM-fout veroorzaken. Ik stel `memory.high` aanzienlijk lager in om piekbelastingen af te vlakken en toewijzingen te vertragen. Het is belangrijk om prioriteiten te stellen: de database krijgt memory.min, middleware memory.low, en de batchbelasting krijgt geen speciale rol. Monitoring begeleidt de werking en laat zien of drempels effectief zijn of te streng zijn ingesteld. Op basis van deze signalen pas ik de limieten aan en verhoog ik tegelijkertijd de <strong>Effici\u00ebntie<\/strong> van de applicatie.<\/p>\n\n<p>Ik leg de waarden per dienst vast, beschrijf de redenen en documenteer wijzigingen op een begrijpelijke manier. Zo zorg ik ervoor dat beslissingen in het team worden verankerd en voorkom ik dat er na enkele weken in het duister wordt getast. Voorafgaand aan updates of architectuurwijzigingen bekijk ik de trendgrafieken, om te voorkomen dat ik blindelings de instellingen aanscherp of versoepel. Een kleine testomgeving bespaart later veel gedoe in de productie. Dit ritme zorgt voor <strong>Constance<\/strong> in de dagelijkse praktijk.<\/p>\n\n<h2>Praktijk: Webhostingservers structureren<\/h2>\n\n<p>Ik maak voor elke klant een aparte <strong>cgroup<\/strong> en verplaats PHP-FPM, de database en de cache daarheen. Aan elke set wijs ik memory.max plus buffer toe, terwijl memory.high eerder in werking treedt en pieken afvlakt. Kritieke diensten van de klant krijgen beschermingslimieten, zodat hun kerngeheugen niet daalt. Logs en dashboards laten zien wie het systeem vertraagt, wie het belast en waar OOM dreigt. Daarnaast helpen aanwijzingen over <a href=\"https:\/\/webhosting.de\/nl\/server-context-isolatie-namespaces-cgroups-hosting-beveiliging\/\">Naamruimten en isolatieconcepten<\/a>, zodat clients duidelijk gescheiden blijven en <strong>Beveiliging<\/strong> neemt toe.<\/p>\n\n<p>Daarnaast pas ik het aantal PHP-workers, de OPcache-grootte en de query-caches aan om het geheugengebruik te verminderen. Vaak volstaat het al om pieken te verminderen via `memory.high` om de tijd te verkorten. Voor tests gebruik ik re\u00eble belastingpatronen, geen synthetische ideale waarden. Vervolgens documenteer ik nieuwe limieten en koppel ik deze aan SLA's. Zo groeit de <strong>Transparantie<\/strong> ten opzichte van klanten en de interne ondersteuning.<\/p>\n\n<h2>Foutopsporing bij het afdrukken van geheugen<\/h2>\n\n<p>Stijgt <strong>memory.current<\/strong> Als er plotselinge pieken optreden, controleer ik eerst of er wijzigingen zijn aangebracht in het verkeer, de deployments of de configuraties. Ik vergelijk de grafieken van overschrijdingen van de maximumwaarden, page-faults en latenties. Als er een reeks OOM\u2019s optreedt, identificeer ik de getroffen processen aan de hand van het kernel-log en pas ik limieten of de workload aan. Als de oorzaak ligt in defecte caches, voer ik gerichte aanpassingen uit in plaats van een algemene oplossing toe te passen. Deze diagnoseketen brengt me snel naar de <strong>Oorzaak<\/strong>, niet alleen als symptoom.<\/p>\n\n<p>Als de belasting hoog blijft, spreid ik het werk: burst-limieten voor Ingress, wachtrijlengtes verlagen, batch-taken uitstellen. Tegelijkertijd verhoog ik tijdelijk memory.high om wat respijt te krijgen, zonder memory.max te verhogen. Als er lekken worden gevonden, stel ik de guardrails strakker in totdat er een oplossing is. In hardnekkige gevallen beperk ik de service-scope of repliceer ik de instantie. Zo houd ik de <strong>Operatie<\/strong> werkt betrouwbaar, zelfs onder druk.<\/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: gebeurtenisgestuurde tegenmaatregelen<\/h2>\n\n<p>Ik knoop <strong>Acties<\/strong> op gebeurtenissen: memory.events levert tellers die ik via een watcher of metriekpijplijn verwerk. Bij herhaalde \u2018high-hits\u2019 leeg ik gericht caches, verlaag ik de concurrency of start ik \u2018reclaim\u2019-pogingen, voordat gebruikers er iets van merken. Als milde ingrepen niet werken, schakel ik over op harde maatregelen: het stoppen van verzoeken, het leegmaken van wachtrijen, het wijzigen van prioriteiten. Het is belangrijk dat beslissingen <strong>deterministisch<\/strong> zijn \u2013 dezelfde triggers, dezelfde reactie \u2013 zodat teams gedrag kunnen begrijpen en nabootsen.<\/p>\n\n<p>Ik behoud bovendien de <strong>Reikwijdte<\/strong> OOM in de gaten houden. Met memory.oom.group voorkom ik gedeeltelijke afsluitingen die applicaties in inconsistente toestanden brengen. Als er iets moet worden be\u00ebindigd, dan moet dat op een samenhangende en snelle manier gebeuren, zodat resterende capaciteit snel weer beschikbaar is. In combinatie met telemetrie en gedocumenteerde playbooks ontstaat zo een robuuste feedbacklus die onder re\u00eble productieomstandigheden goed functioneert.<\/p>\n\n<h2>Vooruitzichten en samenvatting<\/h2>\n\n<p>De geheugencontroller van <strong>cgroup<\/strong> v2 biedt me een gelaagde reeks hulpmiddelen: strenge limieten, zachte remmen en beschermingslijnen met een duidelijke prioriteit. Door bewust gebruik te maken van memory.max, memory.high, memory.low en memory.min, reageer ik op een gestructureerde manier op pieken in de belasting en houd ik diensten operationeel. Monitoring via memory.current laat in een vroeg stadium zien waar limieten krap worden of reserves ontbreken. In container- en multi-tenant-omgevingen zorgen deze mechanismen voor een eerlijke toewijzing van resources zonder dat dit ten koste gaat van anderen. Met discipline, meetwaarden en kleine correctiestappen bereik ik betrouwbare <strong>Prestaties<\/strong> \u2013 van een enkele VM tot een druk bezette host.<\/p>","protected":false},"excerpt":{"rendered":"<p>Ontdek hoe de Linux cgroup v2-geheugencontroller werkt en hoe je met gerichte Linux-bronlimieten stabiele hosting- en containeromgevingen kunt opzetten.<\/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":"223","_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\/nl\/wp-json\/wp\/v2\/posts\/21199","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/comments?post=21199"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/posts\/21199\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/media\/21192"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/media?parent=21199"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/categories?post=21199"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/tags?post=21199"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}