Uitleg over geheugenbeheer in Linux: swap, OOM killer en cgroups

Linux gaat anders om met geheugen dan de meeste besturingssystemen. Een hoog RAM-gebruik is niet altijd een probleem — de kernel gebruikt actief vrij geheugen voor caching om het lezen van schijven te versnellen. Maar wanneer er echte geheugendruk ontstaat, treden drie mechanismen in werking: swap, de OOM-killer en cgroups. Inzicht in hoe elk van deze mechanismen werkt en hoe ze moeten worden geconfigureerd, maakt het verschil tussen een server die onder belasting op een gecontroleerde manier vertraagt en een server die zonder waarschuwing crasht.

Hoe Linux geheugenpagina's beheert

Elk proces draait in zijn eigen virtuele adresruimte, tot 128 TB op 64-bits systemen. De kernel koppelt deze virtuele adressen aan fysiek RAM via paginatabellen, waarbij de Translation Lookaside Buffer (TLB) recente zoekopdrachten in de cache opslaat. Een TLB-hit duurt ongeveer 1 nanoseconde; een miss kost 20–100 nanoseconden, wat bij geheugenintensieve workloads zoals databases aardig kan oplopen.

Het fysieke geheugen is verdeeld in pagina's van 4 KB, en de kernel splitst deze op in twee categorieën:

• Door bestanden ondersteunde pagina's — gekoppeld aan bestanden op schijf. De kernel kan schone pagina's verwijderen of vuile pagina's leegmaken zonder dat er swap nodig is.
• Anonieme pagina's — heap- en stackgeheugen zonder bijbehorend bestand. Deze moeten naar de swap worden geschreven voordat de kernel ze kan vrijmaken.

Op servers met een hoge geheugenbehoefte betekent een groot aandeel anonieme pagina's dat swap al vroeg in het spel komt. Let op de si (swap in) en so (swap out) kolommen in vmstat 1 — aanhoudende waarden die niet nul zijn, zijn uw eerste waarschuwing dat het systeem onder druk staat.

Gebruik voor monitoring de juiste tool voor de klus:

Een veelgemaakte fout: het bekijken van de free kolom in free -h en in paniek raken. De available kolom is wat telt. Deze omvat geheugen dat de kernel op verzoek uit de cache kan terugwinnen. Een server die slechts 512 MB vrij maar 5 GB beschikbaar aangeeft, verkeert niet in moeilijkheden.

Wanneer het geheugen onder een drempelwaarde daalt, begint de kswapd daemon van de kernel op de achtergrond pagina’s terug te winnen. Als dat niet genoeg is, gaat de kernel over op directe terugwinning, waarbij processen worden geblokkeerd totdat er pagina’s vrijkomen. Dit is de oorzaak van pieken in de latentie. Stel een waarschuwing in wanneer MemAvailable onder de 10–15% van het totale RAM-geheugen komt, zodat je tijd hebt om te reageren.

Swap configureren

Swap is een schijfgebied — een partitie of een bestand — waar de kernel inactieve anonieme pagina's naartoe verplaatst wanneer het RAM-geheugen vol raakt. Het verschil in snelheid is aanzienlijk: DDR4-RAM heeft een latentie van ongeveer 100 ns, terwijl NVMe-SSD's rond de 100.000 ns zitten en SATA-SSD's dichter bij 500.000 ns. Swap is een veiligheidsbuffer, geen extra RAM. Een server die constant op swap vertrouwt, heeft een geheugenprobleem dat niet met meer swap kan worden opgelost.

Gebruik een swapbestand in plaats van een partitie. Het is gemakkelijker om de grootte aan te passen en er is geen herpartitionering nodig.

sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile

Zorg ervoor dat het bestand /etc/fstab om het bestand na het opnieuw opstarten te behouden. De chmod 600 stap is vereist — alle gegevens die uit het RAM-geheugen worden gepagineerd, zijn leesbaar vanuit de swap, dus het bestand mag niet voor iedereen leesbaar zijn.

Nadat je swap hebt aangemaakt, stel je vm.swappiness. De standaardwaarde van 60 is agressief. Voor de meeste hosting-workloads wilt u dat de kernel de voorkeur geeft aan RAM en swap alleen als laatste redmiddel gebruikt:

Voor de grootte van de swap: 1–2 GB is voldoende voor een VPS van 2 GB die af en toe pieken in het verkeer verwerkt. Op systemen met 8 GB of meer is een vaste swap van 2–4 GB over het algemeen voldoende. Het doel is om de kernel een drukventiel te geven voor koude pagina's, niet om het totale adresseerbare geheugen uit te breiden.

Op servers met beperkt RAM-geheugen en voldoende CPU-capaciteit creëert zram een gecomprimeerd swapgebied in het geheugen, waardoor schijf-I/O volledig wordt vermeden. Dit is het overwegen waard op multi-tenant VPS-hosts waar NVMe door meerdere tenants wordt gedeeld. Let op I/O-conflicten als de swap zich op hetzelfde apparaat bevindt als databasebestanden — intensief swappen en schrijfbewerkingen met hoge doorvoer gaan niet goed samen.

De OOM-killer

Wanneer de kernel het RAM-geheugen en de swapruimte heeft uitgeput en niet via andere middelen voldoende geheugen kan vrijmaken, treedt de OOM-killer in werking. Deze beoordeelt processen met behulp van de oom_badness() :

points = (rss_anon + rss_file + rss_shmem + swapents + pgtables_pages) + (oom_score_adj × totalpages / 1000)

Het proces met de hoogste score wordt beëindigd. De formule geeft de voorkeur aan processen die veel geheugen verbruiken, en de kernel voorkomt dat meerdere processen snel achter elkaar worden beëindigd door te controleren of een proces in de afgelopen 5 seconden al is beëindigd.

Er verschijnen twee soorten OOM-gebeurtenissen in de logbestanden:

• Global OOM — het hele systeem heeft geen RAM en swap meer. Logbestanden beginnen met Out of memory:
• Cgroup OOM — een container of service heeft zijn memory.max limiet bereikt. Logs beginnen met Memory cgroup out of memory:

Om eerdere OOM-gebeurtenissen te bekijken:

dmesg -T | grep -i "out of memory"
journalctl -k --grep="oom"

Let op het order veld in OOM-logs. Een waarde boven de 0 duidt op geheugenfragmentatie in plaats van totale uitputting — de kernel kon onvoldoende aaneengesloten pagina's vinden, zelfs met beschikbaar vrij geheugen.

U kunt beïnvloeden op welke processen de OOM-killer zich richt door /proc/<pid>/oom_score_adj. Het bereik is -1000 (nooit beëindigen) tot +1000 (als eerste beëindigen). Voor door systemd beheerde services stelt u dit permanent in het unit-bestand in:

[Service]
OOMScoreAdjust=-1000

Extra sysctl-parameters voor het afstemmen van OOM-gedrag:

Controleer voor proactieve monitoring /proc/pressure/memory (Pressure Stall Information, beschikbaar sinds kernel 4.20). Let op de some avg10 waarde: onder de 5% is gezond, blijft het boven de 20%, dan is een OOM-gebeurtenis waarschijnlijk op komst. Een stijgende allocstall teller in /proc/vmstat is een ander vroeg signaal — deze telt directe terugwinningsstoringen, die vaak voorafgaan aan OOM-beëindigingen. Tools zoals systemd-oomd of earlyoom kunnen reageren op PSI-drempels voordat de OOM-killer van de kernel in werking treedt.

Cgroups en geheugenlimieten

Met control groups (cgroups) kunt u processen in groepen indelen en strikte limieten voor resources afdwingen. Ze zijn geïntroduceerd in Linux 2.6.24 en vormen de basis van container-runtimes, waaronder Docker, Podman, Kubernetes en LXC. De kernel houdt het geheugengebruik per cgroup bij, inclusief anoniem geheugen, door bestanden ondersteunde pagina's en kernelobjecten. Als een cgroup zijn limiet bereikt, vordert de kernel geheugen binnen die groep terug of activeert hij een OOM-kill binnen de cgroup.

Cgroup v1 en v2 verschillen voornamelijk in hun structuur. V1 koppelt elke controller (geheugen, CPU, I/O) afzonderlijk onder /sys/fs/cgroup/<controller>/, wat leidt tot inconsistente tracking van resources. V2 gebruikt een uniforme hiërarchie op /sys/fs/cgroup/. Kubernetes is in versie 1.25 standaard overgestapt op v2 en heeft de ondersteuning voor v1 in 1.31 stopgezet.

Om te controleren welke versie uw systeem gebruikt:

stat -fc %T /sys/fs/cgroup/

cgroup2fs betekent v2; tmpfs betekent meestal v1.

De belangrijkste geheugenregelaars in cgroup v2:

Een praktische regel: stel memory.high ongeveer 10–20% lager memory.max om de kernel ruimte te geven om geheugen vrij te maken voordat de harde limiet wordt bereikt. Bij het bepalen van de grootte memory.max, tel dan 20–30% boven het piekgebruik van de applicatie op om rekening te houden met de paginacache, die meetelt voor het totale cgroup-geheugen.

Beheer cgroups via systemd in plaats van rechtstreeks naar het cgroup-bestandssysteem te schrijven. Gebruik unit-bestandsrichtlijnen zoals MemoryMax=, MemoryHigh=, en MemoryMin= voor permanente limieten. Voor snelle tests:

systemd-run --scope -p MemoryMax=512M <command>

Voor werkpools van webservers zorgt het instellen van memory.oom.group=1 zorgt voor een schone beëindiging als een worker zijn limiet overschrijdt — er blijven geen verweesde processen achter. Voor database-engines memory.min beschermt de bufferpool tegen terugwinning onder systeembrede druk.

Geheugenconfiguratie per serverrol

De juiste geheugeninstellingen zijn afhankelijk van wat de server doet. Als je dezelfde configuratie toepast op een database en een PHP-webserver, zal dat voor een van beide nadelig zijn.

Wijs voor MySQL en PostgreSQL 50–70% van het beschikbare RAM-geheugen toe aan innodb_buffer_pool_size, schakel Transparent Huge Pages uit om pieken in de latentie te verminderen en beveilig het proces met OOMScoreAdjust=-900 in het systemd-unitbestand.

Voor PHP-FPM: stem de grootte van de workerpools af op het daadwerkelijke geheugengebruik. Elke worker gebruikt doorgaans 30–100 MB. Deel het toegewezen RAM door de gemiddelde grootte van een worker om een veilige pm.max_children waarde. Gebruik memory.max in cgroups om de pool te beperken.

Stel voor schrijfintensieve workloads vm.dirty_ratio in op ongeveer 10% en vm.dirty_background_ratio op 3%. Hierdoor worden vuile pagina’s vaker geleegd, waardoor grote I/O-stagnaties worden voorkomen.

Maak kernelafstemming persistent door parameters op te slaan in /etc/sysctl.d/90-memory.conf. Instellingen die tijdens de uitvoering worden toegepast, gaan bij het opnieuw opstarten verloren.

Voor een overzicht van aanbevolen waarden per rol:

Als u workloads met hoge dichtheid uitvoert en een server nodig hebt met voldoende ruimte om dit beleid correct toe te passen, zijn de dedicated servers van FDC zeker het overwegen waard.