Geheugendruk in de Linux-kernel: gevolgen voor hostingsystemen

Memory Pressure in de Linux-kernel heeft directe gevolgen voor hostingsystemen: als de druk toeneemt, verschuiven CPU-tijd en I/O naar rekenintensieve taken Reclaim, de responstijden lopen op en het risico op OOM-fouten neemt toe. Ik leg duidelijk uit hoe ik geheugendruk herken, meet en verlicht, zodat Hosting-Constant reageren op workloads.

Centrale punten

Ik concentreer me op de cruciale factoren die in hostingomgevingen bepalend zijn voor de prestaties en storingen. De volgende punten vormen de rode draad waaraan ik mijn diagnose en optimalisatie afstem. Met dit overzicht voorkom ik verkeerde interpretaties van „vol RAM“ en herken ik echte Druk op tijd.

• PSI-statistieken geven wachttijden weer in plaats van alleen de bezettingsgraad en brengen vertragingen in een vroeg stadium aan het licht.
• Swap-last wijst op Reclaim-problemen die de I/O en latenties vergroten.
• Cgroups-limieten Beheer van de beperking, beveiliging en het OOM-gedrag per service.
• Cache-vervanging heeft een directe invloed op de prestaties van websites en databases.
• Capaciteitsplanning en afstemming zorgen voor headroom en voorkomen thrashing.

Zo structureer ik mijn analyses, van de kernel tot de applicatie, en voer ik de juiste maatregelen op basis van prioriteit uit. De focus blijft liggen op meetbare effecten, niet op werk op afbetaling.

Wat betekent 'memory pressure' in de Linux-kernel?

Geheugendruk betekent dat de kernel merkbaar tijd besteedt aan het vrijmaken van geheugen, in plaats van het werk van de gebruikersprocessen voort te zetten; de CPU besteedt dan meer tijd aan scans, schrijfbewerkingen en verdrijvingen, terwijl verzoeken in de wachtrij staan. Ik maak een duidelijk onderscheid tussen „vol RAM“ en „gebrek aan bruikbaar Headroom“: Een „volle“ cache is gezond; er ontstaan pas knelpunten wanneer de Reclaim-investeringen toenemen. De kernel scant inactieve lijsten en schrijft vies-pagina’s verwijdert, de bestandscache leegmaakt en anonieme pagina’s uitlaagt zodra de watermarks worden onderschreden. Doorslaggevend is de tijd die aan deze activiteiten wordt besteed; dit komt tot uiting in wachttijden van de taken en langere responstijden. Een host kan bij een 95 %-belasting soepel draaien zolang de cache gemakkelijk kan worden teruggewonnen, maar bij een lage belasting ernstig vastlopen wanneer actieve anonieme pagina’s moeten worden verdrongen.

PSI begrijpen en meten

Pressure Stall Information (PSI) maakt geheugendruk tastbaar, omdat ik niet de bezetting meet, maar de vertragingen. In /proc/druk/geheugen Ik zie „some“ en „full“: „some“ geeft momenten aan waarop ten minste één taak op geheugen wacht, „full“ duidt op fasen waarin ze allemaal in de wachtrij staan. Voorbeeld: „some avg10=4,67“ betekent dat er in de afgelopen 10 seconden 4,67 % aan stilstand is opgetreden door geheugenbottlenecks; „full avg10=0,30“ duidt op zeldzame volledige blokkades. Ik breng stijgende „some“-waarden al in een vroeg stadium in verband met responstijden en schaal, optimaliseer of ontlast het systeem voordat er ernstige OOM’s optreden. Dit inzicht voorkomt dat ik me laat misleiden door schijnbaar „veel vrij“ RAM, want vrije pagina’s zonder snelle Reclaim-maken er weinig gebruik van.

Gemeten variabele	Richtwaarde	Symptoom	Actie
PSI-geheugen (gem. 10)	> 2–3 % aanhoudend	De responstijden nemen toe	RAM-headroom controleren, cgroup-limieten nauwkeurig afstemmen
PSI-geheugen vol (gem. 10)	> 0,1 % merkbaar	Korte stilstandtijden	De oorzaak vaststellen, het thrashing stoppen
MemBeschikbaar	< 10 % van het RAM-geheugen	Kleine buffer	Cache/werkbelasting ontlasten, capaciteit plannen
vmstat si/so	blijvend > 0	Swap-druk	Swappiness/Swap aanpassen, Hotset beveiligen

Symptomen in hostingomgevingen

Op drukke hosts zie ik eerst pieken in de latentie, terwijl de CPU-belasting ogenschijnlijk gematigd blijft; de kernel zit vast in reclaim-lussen, I/O loopt vast en verzoeken staan in de wachtrij. De load average stijgt, hoewel er kernen vrij lijken te zijn, omdat veel taken vastlopen op geheugen of I/O; dit is een duidelijk teken van verhoogde Drukken. Aanhoudende si/so-waarden in vmstat geven aan dat het systeem actief aan het swappen is, wat TLS-handshakes, dynamische inhoud en query-paden vertraagt. Als dit onbehandeld blijft, raakt het systeem in een thrashing-toestand: de CPU besteedt het grootste deel van de tijd aan paging en swapping, in plaats van nuttig werk te verrichten. In het ergste geval grijpt de OOM-killer in en beëindigt processen met een hoge score; een gerichte Analyse van de OOM-killer helpt me patronen en verkeerde configuraties te herkennen.

Relevantie voor hosting-workloads en cgroups

In gedeelde omgevingen zijn enkele applicaties die veel geheugen verbruiken al voldoende om de latentie voor veel klanten te verhogen; cgroups verzachten de gevolgen, maar bieden geen oplossing voor verkeerd gedimensioneerde Instanties. In VPS- en cloud-instanties leidt een krap bemeten RAM-geheugen of een slechte swap-strategie sneller tot piekbelastingen; isolatie beschermt andere diensten, maar niet de eigen dienst. Databases zijn afhankelijk van grote bufferpools; wanneer Reclaim deze verdringt of swap ingrijpt, nemen de query-tijden toe en daalt de doorvoersnelheid aanzienlijk. Container-orkestraties gebruiken memory.low, memory.high en memory.max om belangrijke services te beschermen, vertragingen te beperken en in noodgevallen gericht te beëindigen. Ik kies daarom bewust limieten en houd de PSI per service in de gaten om tijdig in te grijpen en reserves aan te leggen voor kritieke Werklasten vrijhouden.

Monitoringstrategie en meetcriteria

Ik bekijk MemAvailable, Buffers en Cached om te begrijpen hoeveel geheugen op korte termijn kan worden vrijgemaakt; alleen MemFree-waarden kunnen gemakkelijk misleidend zijn. Tegelijkertijd bekijk ik vmstat: aanhoudende si/so-waarden duiden op swapdruk, die de I/O enorm opvoert en de latentie doet stijgen; voor achtergrondinformatie over de Swapgebruik Ik maak gebruik van beproefde diagnosemodellen. PSI vult het ontbrekende stukje in, omdat „some“ en „full“ daadwerkelijke vertragingen kwantificeren; ik geef waarschuwingen bij drempelwaarden en maak onderscheid tussen piekbelastingen en chronische knelpunten. Tijdreeksen via sar of de observability-stack maken patronen zichtbaar en helpen me om het succes van optimalisaties te bevestigen. dmesg onthult OOM-gebeurtenissen die wijzen op harde limieten of verkeerde configuraties; zo bouw ik een samenhangend beeld op vanuit het perspectief van de kernel, het I/O-gedrag en Toepassing.

Typische workloads onder druk

Webservers zoals Nginx of Apache leveren inhoud langzamer aan wanneer Reclaim en Swap op de achtergrond draaien; Keep-Alive-verbindingen blijven langer openstaan, wat wachtrijen vergroot. PHP- en Python-stacks nemen RAM in beslag door framework-caches, JIT-onderdelen en sessiegegevens; bij verdringing schommelen deze gegevens heen en weer tussen RAM en opslag, waardoor de responstijden aanzienlijk toenemen. Databases verliezen snelheid zodra bufferpools krimpen of delen op swap terechtkomen; zelfs een geringe extra latentie per I/O loopt bij grote aantallen op tot Query's. Cachingdiensten zoals Redis of Memcached zijn afhankelijk van RAM-treffers; als sleutelgebieden op de swap terechtkomen, gaat het voordeel verloren en neemt het risico toe dat ze bij hoge belasting worden beëindigd. In alle gevallen geven PSI- en swap-statistieken de duidelijkste aanwijzingen dat het geheugen een bottleneck is geworden, en niet de CPU.

Systeemoptimalisatie en kernelparameters

Ik begin met vm.swappiness: een matig verlaagde instelling voorkomt overmatig gebruik van de swapruimte, zonder dat de noodzakelijke vrijmaking wordt geblokkeerd; ik meet de effecten consequent met PSI. Vervolgens optimaliseer ik vm.dirty_ratio en aanverwante limieten, zodat ik geen lange flush-golven veroorzaak en toch geen overmatige schrijfactiviteit uitlok; beide hebben merkbare Effecten op latenties. Bij Cgroups v2 stel ik memory.low in voor kritieke diensten, memory.high voor beperking bij overbelasting en memory.max als harde limiet met beheersbare OOM’s. Ik let vooral op NUMA-topologieën: er kan lokale druk ontstaan, ook al is er globaal nog RAM vrij; proces- en geheugenbinding voorkomen dergelijke valkuilen. Ten slotte controleer ik het gedrag van de paginacache; onnodige verdringing drukt de hit-percentages en kost bij web- en DB-workloads direct tijd, waardoor de Optimalisatie van de paginacache biedt nuttige inzichten.

Een diepgaande blik op Reclaim-paden

Om de juiste maatregelen te kiezen, maak ik onderscheid tussen kswapd en Direct Reclaim. kswapd werkt asynchroon wanneer de watermarks worden onderschreden; het werkt relatief soepel zolang er voldoende gemakkelijk terug te winnen cache beschikbaar is. Direct Reclaim grijpt synchroon in op uitvoeringscontexten wanneer threads dringend pagina’s nodig hebben – hier ontstaan de voor gebruikers merkbare vertragingen. Ik kijk of Reclaim vooral de bestandscache of anonieme pagina’s treft: als de kernel voornamelijk bestandscache verdringt, nemen cache-misses toe; als hij anoniem geheugen (bijv. de heap) verdringt, dreigen harde stops en swap-activiteit. Moderne workingset-mechanismen houden rekening met refault-afstanden om nuttige pagina’s langer vast te houden; als ik toch veel herhaalde refaults zie, weet ik dat hotsets groter zijn dan de beschikbare Headroom zijn geworden.

Daarnaast let ik ook op verdichting en defragmentatie: kcompactd probeert samenhangende gebieden te creëren, bijvoorbeeld voor grote toewijzingen of THP. Als de compactificatie achterblijft, zie ik een hoger CPU-gebruik in kcompactd, toenemende latenties en een hoger aandeel „full“-PSI’s bij piekbelastingen. In dergelijke gevallen is het vaak zinvoller om de druk te verlagen of het THP-beleid aan te passen, in plaats van alleen maar „meer swap“ toe te voegen.

Swap-strategieën in detail

Swap is geen vijand, maar een hulpmiddel – bij verkeerd gebruik kan het echter de latentie vergroten. Ik maak het volgende onderscheid:

• Geen swap: Veilig tegen swap-lags, maar riskant bij pieken – OOM’s treden eerder op, Reclaim heeft geen reservebuffer.
• Gematigde swap op een snelle SSD: Geschikt om weinig gebruikte, anonieme pagina’s uit te wisselen; beschermt hotsets in het RAM-geheugen, mits de swappiness en cgroup-limieten verstandig zijn ingesteld.
• zswap/zram: Compressie ontlast de I/O; geschikt voor hosts met minder I/O-activiteit of als buffer tegen kortstondige piekbelastingen. Ik controleer het CPU-budget en de compressieverhouding om te voorkomen dat de CPU een bottleneck wordt.

Ik stel de swappiness niet zonder meer laag in; bij workloads met een grote bestandscache is een iets hogere swappiness zinvol om koude, anonieme pagina’s te verdringen en de bestandscache stabiel te houden. Kritieke services (bijv. databases) bescherm ik met `memory.low` en, indien nodig, door hun hotsets in het RAM te vergrendelen, zodat swap niet de verkeerde gegevens raakt. Het is van cruciaal belang dat vmstat si/so en PSI dalen consistent wanneer ik de strategie aanpas; anders pas ik deze bij.

THP, verdichting en fragmentatie

Transparante grote pagina's (THP) besparen TLB-hits en helpen bij CPU-intensieve, geheugenintensieve toepassingen. Onder druk veroorzaken ze echter compactiewerk; „always“ kan dan tot grote vertragingen leiden. Ik gebruik „madvise“ doelgericht voor workloads die hiervan profiteren (bijv. bepaalde in-memory-engines), en bij latentiegevoelige webstacks laat ik THP liever doelgericht uitgeschakeld of alleen via madvise ingeschakeld. Daarnaast houd ik vm.compaction_proactiveness en ga na of proactieve verdichting de stilstand uitstelt of daadwerkelijk vermindert. Als THP-pagina’s vaak worden opgesplitst of als de verdichting oververhit raakt, wijst dat erop dat er te weinig Headroom of onjuiste toewijzingspatronen in de applicatie.

NUMA-valkuilen en lokale druk

Op NUMA-hosts is het globale „vrije RAM“ misleidend: de ene socket kan onder druk staan, terwijl een andere onbenut blijft. Ik controleer NUMA-statistieken en veranker processen lokaal (CPU-/geheugenbinding), zodat hotsets dicht bij de rekenbelasting blijven. Direct Reclaim op een knooppunt ondanks globale reserves duidt op NUMA-onevenwichtigheden; hier helpen interleaved toewijzingen voor wijdverspreide services of strikte binding voor monolithische workloads. PSI per cgroup in combinatie met NUMA-statistieken laat me zien of één enkel knooppunt de wachtrijen veroorzaakt.

Maatregelen die dicht bij de toepassing liggen

Ik analyseer geheugenprofielen met ps, top, htop en profiler-tools om echte geheugenvreters en lekken op te sporen; daarbij let ik op hoe hotsets in de loop van de tijd veranderen. Ik kies bewust voor applicatiecaches: te groot zorgt voor druk, te klein gaat ten koste van de snelheid; ik stem af op basis van PSI en responstijden, niet op basis van een onderbuikgevoel. Bij signalen van druk kan de applicatie vrijwillig minder kritieke caches of tijdelijke gegevens vrijgeven; zo verminder ik stilstanden zonder globale limieten aan te passen. Startparameters en GC-tuning (bijv. voor JVM’s) pas ik zo aan dat working sets netjes binnen het RAM blijven; agressieve toewijzingspatronen temper ik door middel van batching. Ook houd ik build-artefacten en debug-symbolen in de gaten, want over het hoofd geziene restanten kosten stilletjes Geheugen en verhogen het risico op latere stallen.

Fijnheden van Cgroups v2 en OOM-strategieën

Met Cgroups v2 maak ik een duidelijk onderscheid tussen bescherming, beperking en harde limieten: geheugen.laag reserveert headroom voor kritieke diensten; de overige teruggewonnen capaciteit gaat naar minder belangrijke groepen. geheugen.hoog beperkt het gebruik bij overschrijding door middel van gerichte beperking en dwingt applicaties om geheugen vrij te maken voordat het systeem eronder lijdt. geheugen.max is de laatste verdedigingslinie – als deze wordt overschreden, betekent dit OOM binnen een gecontroleerd kader. Ik stel PSI per cgroup, zodat er alarmen afgaan op de plek waar het vastloopt; de globale PSI blijft stabiel terwijl een enkele dienst instort – precies dit patroon wil ik herkennen. Samen met OOM-prioriteiten stel ik duidelijke opofferingsregels vast: onbelangrijke batch-workers worden als eerste beëindigd, kern-API’s behouden hun Headroom.

Virtualisatie: ballooning, KSM en overcommit

In gevirtualiseerde omgevingen word ik geconfronteerd met een dubbele druk: de gast ziet schijnbaar vrij RAM, terwijl de hypervisor via Ballonvaren onttrekt. Dit spel verhoogt de reclaim-kosten aan beide kanten. Ik meet de PSI in de gast en breng dit in verband met hypervisor-statistieken; als de PSI stijgt bij ballooning-gebeurtenissen, heeft de VM meer gegarandeerde capaciteit nodig of betere cgroup-beleidsregels in de host. KSM bespaart RAM door identieke pagina’s te dedupliceren, maar kost CPU-capaciteit; in hostingomgevingen met veel vergelijkbare VM’s kan het de moeite waard zijn, zolang de extra CPU-belasting de SLO’s niet in gevaar brengt. Overcommit (bijvoorbeeld het agressief toewijzen van veel kleine VM’s) plan ik alleen met vaste SLO-reserves en strikte geheugen.laag voor systemen waarbij latentie van cruciaal belang is.

Architecturale keuzes bij hosting

Ik zet in op horizontale verdeling, zodat afzonderlijke instanties minder last hebben van piekbelastingen; schaalbare pools dempen uitschieters en houden de latentie binnen strakkere grenzen. Ik maak een duidelijke scheiding tussen de rollen: databases, applicaties en caching krijgen hun eigen resourcepools, zodat reclaim-processen geen onverwachte neveneffecten over systeemgrenzen heen veroorzaken. Bij de keuze van opslag houd ik rekening met schrijflatentie, want dirty-page-flushes hebben direct invloed op de responstijden; een snel pad verkort de reclaim-tijden merkbaar. In clusters plan ik RAM-reserves per knooppunt in en stuur ik via scheduler-beleidsregels aan, zodat de belasting en het geheugengebruik gelijkmatiger verdeeld blijven. Ik automatiseer schaalbaarheid met PSI-drempels, zodat stijgende „some“-waarden acties in gang zetten voordat er sprake is van abrupte vertragingen en Doden-gebeurtenissen.

Capaciteitsplanning en headroom-modellen

Ik definieer headroom op een meetbare manier: ik zorg voor voldoende reserves, zodat „some“-PSI bij normale pieken onder vastgestelde drempels blijft en „full“ praktisch niet voorkomt. Hiervoor gebruik ik percentielen (bijv. het 99e percentiel van de uurbelasting) en plan ik 10–30 % extra RAM, afhankelijk van de volatiliteit van de workload. Databases krijgen grotere vaste reserves, terwijl web-frontends dynamischer schalen. Ik kalibreer de hersteltijden: hoe snel dalen PSI en si/so na een piek? Blijven ze verhoogd, dan is dat een teken van te geringe reserves of een ongeschikte swap-/dirty-strategie. Zo wordt capaciteitsplanning een continu proces in plaats van een jaarlijkse schatting.

Alarmering en SLO-gestuurde afstemming

Ik koppel PSI aan gebruikers-SLO’s: als „some avg10“ tegelijkertijd met de latentie van de API stijgt, grijp ik in. Ik deel alarmen in twee niveaus in: „geel“ (aanhoudend 2–3 % „some“, „full“ dicht bij 0) en „rood“ (meer dan 5 % „some“ of „full“ > 0,1 %). Op cgroups gebaseerde alarmen helpen om de luidruchtige minderheid te isoleren. Daarnaast geef ik alarm bij stijgende dirty-queues en schrijfwachttijden, zodat ik dirty-golven tijdig kan afvlakken. Het doel is dat afstemmingsmaatregelen (swappiness, memory.high, cachegroottes) waarneembaar en omkeerbaar zijn; ik voer wijzigingen stapsgewijs door en vergelijk de situatie voor en na aan de hand van dezelfde statistieken.

Stap-voor-stap-diagnose in het dagelijks leven

Ik controleer eerst `free -h` en `MemAvailable`: als de waarde aanzienlijk daalt, zoek ik naar caches die op een zinvolle manier kunnen worden vrijgegeven, en naar services met groeiende hotsets. Daarna laat ik `vmstat` met korte tussenpozen draaien om trends in si/so te herkennen; aanhoudend swappen bevestigt de druk en leidt me naar het I/O-pad. Vervolgens lees ik /proc/pressure/memory en analyseer ik „some“ en „full“ over 10, 60 en 300 seconden; stijgende gemiddelden koppel ik direct aan waargenomen latenties. dmesg toont me OOM-sporen en onthult welke processen recentelijk geheugencrises hebben veroorzaakt of ondervonden; daaruit leid ik limieten en prioriteiten voor Cgroups af. Uit dit alles vorm ik een hypothese, voer ik kleine afstemmingsstappen door, verifieer ik deze via PSI en houd ik de Reactietijd in één oogopslag.

Runbooks en typische oorzaak-gevolgketens

Er zijn een aantal patronen die ik steeds weer tegenkom:

• Back-up- of scantaken verdringen de paginacache: Plotseling dalen de cache-hitpercentages, en worden het web en de database trager. Maatregel: taken afremmen (I/O-prioriteit), het tijdvenster verschuiven, `memory.high` instellen voor de taak-cgroup, het paginacachebudget van de kritieke diensten beschermen.
• Lekken in worker-processen: Langzaam toenemend anoniem geheugen; PSI „some“ stijgt gedurende uren. Maatregel: het lek opsporen, beleidsregels voor het automatisch herstarten en recyclen invoeren, geheugenlimieten instellen, zodat lekken niet de hele host in gevaar brengen.
• Door THP veroorzaakte stallen: De belasting van kcompactd neemt toe tijdens piekmomenten in het verkeer. Maatregel: THP instellen op „madvise“, de betreffende services aanpassen, de compactatieparameters controleren, de headroom vergroten.
• NUMA-lokale druk: Een socket vertoont thrashing, hoewel er globaal gezien voldoende RAM beschikbaar is. Oplossing: affiniteiten corrigeren, interleave instellen voor breed gespreide workloads, de belastingverdeling in de scheduler aanpassen.
• Swap op trage schijven: als si/so stijgt, schieten de responstijden omhoog. Maatregel: swap verplaatsen naar snellere opslag, zswap/zram evalueren, swappiness en cgroup-beleidsregels aanscherpen.

Elk runbook eindigt met een validatie: is „some/full“ verdwenen en stabiliseren de latenties zich? Zo niet, dan was de aanname onjuist of onvolledig – in dat geval ga ik verder met itereren.

Gereedschap en tracering tijdens het gebruik

Naast de klassieke tools richt ik me op een diepgaander inzicht: ik houd de verhoudingen tussen paginacache en anonieme gegevens, de paginafoutpercentages, refault-patronen en writeback-wachtrijen in de gaten. eBPF- en tracing-benaderingen laten me precies zien waar wachttijden ontstaan – bijvoorbeeld langs de reclaim-paden, in de writeback of bij de toewijzing van grote blokken. Ik hecht veel waarde aan een zuinige, productiegeschikte instrumentatie: korte activeringsvensters, steekproeven in plaats van continu meten en een duidelijke correlatie met applicatiestatistieken. Zo vind ik de oorzaken voordat ik op grote schaal aan parameters ga sleutelen.

Belangrijkste punten en volgende stappen

Memory Pressure beschrijft de tijd die verloren gaat door geheugentekort, niet alleen door bezet RAM; ik meet dit met PSI, herken trends in een vroeg stadium en onderneem actie op basis van gegevens. Wie MemAvailable, vmstat si/so, PSI en dmesg in samenhang bekijkt, ontdekt de werkelijke oorzaken van latentiepieken en thrashing. Met het afstemmen van swappiness, dirty en cgroups verminder ik op gerichte wijze vertragingen en zorg ik ervoor dat belangrijke diensten hun Headroom. Op architectuurniveau zorgen horizontale verdeling, duidelijk afgebakende rollen en snelle opslagpaden ervoor dat de gevolgen van elke piekbelasting worden getemperd. Uiteindelijk gaat het erom dat ik diagnose en tegenmaatregelen voortdurend met elkaar verbind: meten, aanpassen, opnieuw meten – totdat de prestaties en Stabiliteit weer passen.