De vm.swappiness correct instellen voor optimale serverprestaties

Ik laat zien hoe je vm.swappiness zo kunt instellen dat web- en databasediensten op hostingservers sneller reageren en minder I/O veroorzaken. Met duidelijke stappen, zinvolle startwaarden en monitoring haal je meer uit het beschikbare RAM-geheugen en verlaag je Latencies en voorkomt onnodig swappen.

Centrale punten

Deze punten geven je een snel overzicht van aanpassingen die je direct kunt doorvoeren.

• Swappiness-gedrag: Bepaalt hoe vroeg de kernel RAM naar de swapruimte verplaatst.
• Verband met de werkbelasting: Pas de waarden aan het type toepassing aan, zoals een database of een website.
• Tijdelijk testen: Eerst live testen, dan definitief vastleggen.
• Swap-indeling: rekening houden met omvang, middelen en prioriteiten.
• Controle: I/O, RAM en responstijden monitoren en aanpassen.

Wat vm.swappiness is en hoe het werkt

De kernelparameter vm.swappiness bepaalt hoe agressief Linux geheugenpagina’s van het RAM-geheugen naar de swapruimte verplaatst. Je vindt de huidige waarde in het pseudobestandssysteem onder /proc/sys/vm/swappiness en kunt deze tijdens de uitvoering of permanent wijzigen. Een hoge waarde leidt tot eerder uitwisselen, een lage waarde houdt de inhoud langer in het RAM-geheugen. Het doel is een goede balans tussen RAM-gebruik, paginacache en gecontroleerd swapgedrag. Ik houd in gedachten: RAM is veel sneller dan welke SSD dan ook, dus ik geef de voorkeur aan Werkgeheugen duidelijk vóór de swap.

Waarom Swappiness belangrijk is op hostingservers

Op web- en applicatieservers is de instelling van Wisseligheid over reactietijd en doorvoer. Agressief swappen zorgt voor extra I/O-belasting en vertraagt verzoeken, vooral bij database-intensieve workloads. Te lage waarden brengen daarentegen het risico met zich mee dat er later OOM-gebeurtenissen optreden, waardoor processen abrupt worden beëindigd. Daarom beoordeel ik naast RAM en swapruimte ook typische piekbelastingen, caches en verzoekpatronen. Wie de latentie verlaagt, voorkomt haperingen en houdt transacties merkbaar vloeibaar.

Aanbevelingen op basis van de werkbelasting

Eén enkele waarde is zelden geschikt voor alle scenario’s; daarom begin ik met in de praktijk beproefde bereiken en pas ik deze vervolgens aan op basis van meetgegevens. Databases hebben baat bij zeer lage instellingen, terwijl pure webservers vaak iets hogere waarden aankunnen. Test- of ontwikkelingssystemen kunnen dichter bij de standaard draaien, omdat gebruiksgemak daar een grotere rol speelt. Het volgende schema gebruik ik als pragmatische start voor Hosting-Workloads. Vervolgens houd ik de I/O, het swapgebruik en de responstijden in de gaten en pas ik de instellingen waar nodig aan.

Werkbelasting	Aanbevolen Swappiness	Doel
Databases (MySQL, PostgreSQL)	0–10	Geheugen in het RAM vasthouden, latenties laag houden
Realtime/lage latentie	0–10	I/O-pieken voorkomen door gebruik te maken van swap
webserver met caches	10–20 (soms 10–30)	Koude pagina’s uitbesturen, actieve verzoeken in het RAM-geheugen
Ontwikkeling/Testen	30–60	Comfort en stabiliteit gaan boven latentie

De huidige waarde controleren

Voordat ik waarden wijzig, lees ik de status uit en leg ik de Basislijn. Ik gebruik hiervoor cat /proc/sys/vm/swappiness of sysctl vm.swappiness; beide methoden leveren een getal op, bijvoorbeeld 60. Tegelijkertijd bekijk ik met free -h het RAM- en swapgebruik. Met `swapon –show` kan ik de grootte, prioriteit en het medium van de actieve swap-apparaten achterhalen. Deze uitgangsgegevens helpen me om later de effecten te toewijzen te kunnen.

Eerst tijdelijk testen in plaats van meteen definitief aan te passen

Ik ga Swappiness eerst op proef gebruiken om te zien hoe mensen er in de praktijk op reageren Belasting te zien. Het commando `sysctl vm.swappiness=10` werkt onmiddellijk, maar blijft slechts van kracht tot de volgende herstart. Tijdens de tests houd ik `top` of `htop` in de gaten, controleer ik `vmstat` en `iostat` en meet ik de responstijden van de diensten. Als de swap-frequentie afneemt en de latenties stabiel blijven, ga ik in logische stappen verder. Pas als de statistieken overtuigend zijn, noteer ik de waarde permanent vast.

Permanent configureren

Als de testwaarde klopt, voer ik deze in een sysctl-configuratiebestand in en laad ik de instellingen opnieuw. In /etc/sysctl.conf voeg ik de regel vm.swappiness=10 toe en activeer ik deze met sysctl -p. Ik vind het overzichtelijker om een apart bestand aan te maken in /etc/sysctl.d/, bijvoorbeeld 99-swappiness.conf, en dit te laden met sysctl –system. Dit leent zich goed voor versiebeheer en kan gemakkelijk in automatisaties worden opgenomen. Een uitgebreider overzicht van gerelateerde parameters vind je in dit artikel over sysctl afstemming, die me helpt bij het structureren van de wijzigingen en Duidelijkheid brengt.

Swapgrootte, geheugenindeling en opslagmedia

Swappiness werkt nooit op zichzelf, daarom beoordeel ik de grootte en de ligging van de Wissel altijd. Te weinig swapruimte raakt snel vol, terwijl te veel swapruimte de I/O-fasen onder druk verlengt. Op SSD of NVMe is swap sneller dan op HDD, maar RAM blijft meerdere ordes van grootte voor. Meerdere swapapparaten met prioriteiten helpen om eerst het snelste medium te gebruiken. Wie zich verder wil verdiepen in de voor- en nadelen, vindt in dit overzicht Swap bij hosting nuttige denkimpulsen voor de Praktijk.

Workflow in de praktijk: stap voor stap

Ik begin met een stand van zaken: de huidige Swappiness-waarde, het RAM- en swapgebruik, de CPU en I/O vastleggen en als Referentie vastleggen. Daarna classificeer ik de workload: voornamelijk database, web met cache, gemengd gebruik of gecontaineriseerd. Vervolgens stel ik een streefwaarde vast: voor databases 0–10, voor web meestal 10–20, voor gemengde workloads voorzichtig aftasten. Ik stel de waarde tijdelijk in, observeer meerdere belastingfasen en vergelijk de statistieken. Als het beeld herhaaldelijk klopt, leg ik de waarde vast, documenteer ik de wijziging en controleer ik deze na kernel-, hardware- of Vrijgave-Opnieuw wisselen.

Specifieke scenario's: containers, VM's en de cloud

In containers en VM’s pas ik de swappiness aan op host- en gastniveau samen uit. Orkestratietools zoals Kubernetes profiteren meestal van zeer lage instellingen op de worker-nodes om de latentie van pods laag te houden. In VM’s stel ik intern passende waarden in, maar let erop dat de hypervisor dit niet tegenwerkt. In elastische cloudopstellingen helpen conservatieve waarden om pieken af te vlakken totdat schaalbaarheid in werking treedt. Ik voorkom dat één enkele container door intensief swapgedrag de gehele Platform remt af.

Bewaking en probleemoplossing

Typische waarschuwingssignalen voor een onjuiste swappiness zie ik in een hoge I/O-belasting terwijl er nog RAM vrij is, schommelende responstijden en trage databasequery’s. Dergelijke patronen controleer ik met vmstat, iostat, sar en statistieken uit mijn observability-stack. Als het systeem veel gebruikmaakt van swap ondanks vrij RAM, verlaag ik de swappiness meestal. Als ik OOM-logs of afbrekingen zie bij beperkt RAM, verhoog ik de swappiness licht of pas ik de swap-configuratie aan. De volgende tabel geeft een overzicht van symptomen die wijzen op een waarschijnlijke Oorzaak en geeft een eerste richting aan.

Symptoom	Vermoedelijke oorzaak	Volgende stap
Hoge I/O bij beschikbare RAM	Swappiness te hoog	De waarde verlagen, het effect meten
OOM-gebeurtenissen onder belasting	Swappiness te laag of te weinig swap	Waarde verhogen, swapgrootte controleren
Trage zoekopdrachten ondanks de CPU-reserve	Databasebuffer uitgelagerd	Waarde tussen 0 en 10, DB-buffer analyseren
Pieken in belasting zonder CPU-bottleneck	Door swapping veroorzaakte I/O-pieken	Swappiness verlagen, cache-hits controleren

Fijnmazige statistieken begrijpen

Om de swappiness objectief te beoordelen, kijk ik dieper in de kernel-tellers. In /proc/vmstat geven pswpin en pswpout het aantal ingelezen respectievelijk uitgelaste pagina's aan. pgscan_kswapd_* en pgsteal_* laten zien hoe agressief de reclaimer werkt. Als pgmajfault (Major Page Faults) zich opstapelen, duidt dit op I/O-intensieve herlaadprocessen. Ik bekijk deze waarden herhaaldelijk of met `sar -B` en `sar -W` om trends te zien, niet alleen momentopnames. Met vmstat 1 herken ik si/so (swap in/out) en kan ik pieken aan echte gebeurtenissen koppelen. Daarnaast geeft /proc/pressure/memory een indicatie van de mate waarin taken onder druk staan door geheugendruk blok (PSI). Als die waarden daar enigszins of volledig stijgen, is dat voor mij een duidelijke aanwijzing dat de reclaim te agressief is of dat de swappiness niet goed is afgesteld.

Swappiness 0 versus 1: wat de kernel werkelijk doet

Vaak wordt aangenomen dat Swappiness=0 swap volledig uitschakelt. Dat klopt niet helemaal. 0 geeft de kernel het signaal om swap zoveel mogelijk te vermijden en alleen te gebruiken bij echte geheugendruk. In de praktijk volstaat een waarde van 1–10 om een zeer terughoudend gedrag te bereiken, terwijl 0 in sommige versies af en toe kan leiden tot late, maar des te heftigere reclaim-fasen. Voor diensten waarbij latentie cruciaal is, stel ik meestal een waarde van 1–5 in en kijk ik of pswpout/pswpin praktisch op nul blijven. Als er bij 0 OOM-gebeurtenissen optreden tijdens pieken, verhoog ik de waarde lichtjes, zodat de kernel eerder en soepeler de druk verlicht in plaats van abrupt binnen te dringen.

Zswap en ZRAM op een zinvolle manier gebruiken

Naast klassieke swap op schijf gebruik ik, afhankelijk van het profiel, Zswap of ZRAM. Zswap comprimeert uitgelagerde pagina’s en bewaart ze eerst in het RAM, voordat ze indien nodig naar de schijf worden verplaatst. Dat vermindert de I/O en vermindert vertragingen, maar kost wel CPU-vermogen. Op hosts met een ruime CPU-reserve is dat een winstgevender Afweging. ZRAM biedt gecomprimeerde swapruimte rechtstreeks in het RAM aan – ideaal voor pieken in de belasting of zeer kleine VM’s, waarin ik liever gecomprimeerd RAM gebruik dan trage I/O. Belangrijk: ik kies bewust voor één van de concepten en stel de prioriteiten zo in dat het snelste pad als eerste wordt bediend. Swappiness blijft daarbij een stuurmechanisme: ook met Zswap/ZRAM wil ik onnodige reclaim-golven vermijden.

Paginacache, vfs_cache_pressure en cache-hits

Swappiness werkt samen met de paginacache, die bestanden en inodes in het RAM-geheugen bewaart. Met vm.vfs_cache_pressure bepaal ik hoe agressief de kernel deze caches leegmaakt ten gunste van anonieme pagina’s. Te hoge waarden zorgen ervoor dat metadatacaches te snel verdwijnen, wat webservers vertraagt. Ik begin meestal met 50–100, meet de cache-hitpercentages en kijk hoe de latentie zich gedraagt bij statische assets en API-antwoorden. Het doel is om veelgebruikte inhoud in het RAM te houden, zonder dat zelden gebruikte pagina’s het werkgeheugen verstoppen. Als het cache-hitpercentage goed blijft en de I/O laag is, klopt de balans; anders pas ik de swappiness en vfs_cache_pressure aan in het Tandem.

Dirty-writeback en I/O-pieken vermijden

Schrijfpaden beïnvloeden de latentie net zo goed als swap. Met vm.dirty_background_ratio/bytes en vm.dirty_ratio/bytes bepaal ik hoeveel ‘vuile’ cache er wordt gevormd voordat de kernel deze wegschrijft. Ik geef de voorkeur aan *_bytes boven percentages om duidelijke bovengrenzen vast te stellen – vooral bij configuraties met veel RAM, waarbij percentages enorme writeback-pieken kunnen veroorzaken. Doel: continu, voorspelbaar wegschrijven in plaats van sporadische pieken die samen met swap I/O-locks veroorzaken. Ik controleer iostat en de writeback-wachtrijen en houd de waarden zo dat SSD/NVMe constant benut worden, maar niet overreden worden.

NUMA, Zone Reclaim en grote hosts

Op systemen met NUMA speelt geheugenlocaliteit een rol. Als vm.zone_reclaim_mode is ingeschakeld, kan de kernel op agressievere wijze geheugen op het lokale NUMA-knooppunt terugwinnen, wat ongewenste pieken in het terugwinnen van geheugen veroorzaakt. Voor veel hosting-workloads schakel ik Zone Reclaim uit en laat ik de plaatsing over aan de scheduler om een rustiger gedrag te bereiken. Daarnaast controleer ik Transparent Huge Pages (THP): Databases reageren vaak beter op THP=never of madvise, omdat ongeplande defragmentatie en THP-toewijzingen latentiepieken kunnen veroorzaken. Swappiness kan perfect zijn – als THP of NUMA-beleidsregels zich ermee bemoeien, blijven de Hakkende bewegingen.

Container- en cgroups-eenheden

Met Cgroups v2 beschik ik naast host-swappiness over nog meer instellingen: memory.high zorgt voor een geleidelijke terugwinning van geheugen, memory.max stelt strikte bovengrenzen in en memory.swap.max beperkt het gebruik van swap per workload. Zo voorkom ik dat afzonderlijke containers de host via swap vertragen. Ik stel op de node lage swappiness-waarden in en geef kritieke workloads prioriteit via memory.low, zodat hun hotsets langer in het RAM blijven. In Kubernetes let ik erop hoe de node met swap omgaat en test ik wijzigingen eerst in niet-productie-pools. Het totaalbeeld is belangrijk: hostparameters, cgroup-limieten en de orchestrator moeten op elkaar zijn afgestemd, anders verschuift de druk alleen maar van het ene niveau naar het anderen.

Implementatie, automatisering en terugval

Ik rol wijzigingen in de swappiness, net als elke andere prestatieoptimalisatie, op een gecontroleerde manier uit: eerst op een kleine groep vrijwel identieke nodes (Canary), daarna stapsgewijs op grotere schaal. Systemd-sysctl of configuratiebeheer zorgen ervoor dat de waarden op een reproduceerbare manier worden geïntegreerd. Ik documenteer begin- en eindwaarden, tijdstippen, betrokken hosts en Metriek. Voor het geval er een terugval optreedt, plan ik van tevoren de tegenmaatregel (bijv. sysctl vm.swappiness=60) en bewaar ik de eerdere sysctl-bestanden. Tijdens onderhoudsvensters meet ik bewust typische belasting scenario’s, zodat ik veranderingen niet verwar met schommelingen in het tijdstip van de dag of het verkeer. Alleen zo blijven beslissingen betrouwbaar en binnen het team begrijpelijk.

Veelvoorkomende misverstanden en anti-patronen

• „Swappiness=0 schakelt swap uit“: Nee, de kernel blijft swap gebruiken – maar wel heel spaarzaam.
• „Meer swap is altijd veiliger“: Te veel swap verlengt drukfasen en maskeert RAM-bottlenecks in plaats van ze op te lossen.
• „Met NVMe maakt swapping niet uit“: NVMe is snel, maar ordes van grootte langzamer dan RAM. De latentie blijft merkbaar.
• „Eén waarde voor alle servers“: Workloads lopen sterk uiteen. Zonder metingen blijft het optimaliseren een kwestie van toeval.
• „Swappiness lost elke vertraging op“: Problemen zijn vaak te wijten aan cache-hits, writeback, THP, queryplannen of netwerkpaden.

Samenvatting voor een snelle start

Ik stel vm.swappiness voor webservers doorgaans in op 10–20 en voor databases op 0–10, test het effect en houd de I/O, latenties en Wissel-aandeel. De definitieve waarde leg ik via sysctl vast in /etc/sysctl.d/ en zorg ervoor dat wijzigingen traceerbaar blijven. Tegelijkertijd zorg ik voor een coherente swap-indeling: de juiste grootte, een snel opslagmedium, zinvolle prioriteiten. Wat betreft geheugendruk let ik bovendien op de paginacache en het gedrag daarvan; dit overzicht biedt een goed startpunt: Verwijdering uit de paginacache, die me helpt bij het achterhalen van de oorzaak en Context . Met deze aanpak zorg ik voor betrouwbare responstijden, voorkom ik uitlaadpieken en maak ik effectief gebruik van het beschikbare RAM-geheugen.