Linux HugePages bij hosting: een boost voor MariaDB, Redis en PHP-FPM

Ik laat concreet zien hoe Linux-hugepages in de hostingstack MariaDB, Redis en PHP-FPM versnellen, waar ze juist vertragen en hoe ik ze doelgericht instel. Zo verlaag ik Latency, verminder TLB-misses en houd de Geheugenbeheer voorspelbaar.

Centrale punten

De volgende punten geven een overzicht van de belangrijkste handelingen en effecten.

• THP-modus bewust kiezen: „madvise“ voor algemene workloads, „never“ voor gevoelige diensten zoals Redis.
• Statische HugePages Houd rekening met grote MariaDB-bufferpools om de latentie en het aantal TLB-misses te verminderen.
• Redis Bescherming tegen latentiepieken: THP uitschakelen en fork-kosten beperken.
• PHP-FPM profiteert hier indirect van door een lagere kernel-overhead en snellere backends.
• Benchmarking en monitoring uitvoeren vóór de livegang, de effecten meetbaar maken.

HugePages en THP kort uitgelegd

Ik gebruik HugePages, om grotere geheugenpagina’s in te schakelen en zo het aantal te beheren pagina’s te verminderen. Standaardpagina’s zijn 4 KB, terwijl grote pagina’s meestal 2 MB groot zijn. Hierdoor neemt het aantal TLB-misses aanzienlijk af, besteedt de CPU minder tijd aan geheugenbeheer en reageren diensten die veel gebruikmaken van het RAM-geheugen sneller. Transparent Huge Pages (THP) probeert dit automatisch en kan werken zonder aanpassingen aan de app. Uit praktijkverslagen blijkt vaak dat bewerkingen 20–40 % sneller verlopen wanneer de workloads en instellingen op elkaar zijn afgestemd.

De juiste THP-modi kiezen en testen

Ik maak een duidelijk onderscheid tussen de modi „altijd“, „madvise“ en „never“, omdat ze verschillende invloed hebben op de werklast. „always“ kan verrassend veel RAM in beslag nemen en kopieerwerk veroorzaken wanneer diensten forken. „madvise“ biedt controle: alleen geheugen dat de app expliciet markeert, maakt gebruik van grote pagina’s. „never“ biedt maximale voorspelbaarheid, vooral bij diensten die intensief gebruikmaken van forking, zoals Redis. Wie zich hier verder in wil verdiepen, vindt hier achtergrondinformatie over de kansen en valkuilen: THP: stimulans of probleem. Ik test elke modus met een echte belasting, meet de latentie, de CPU-tijd en de RSS, en neem vervolgens een op feiten gebaseerde beslissing.

Praktische instellingen op de host

Voordat ik diensten omzet, zorg ik voor reproduceerbare standaardinstellingen voor de host en een veilige terugvaloptie.

THP doelgericht inzetten (opstartparameters of systemd)

• Via het opstarten van de kernel: voeg in GRUB „transparent_hugepage=madvise“ of „transparent_hugepage=never“ toe en start de systeem opnieuw op.
• Continu via sysfs – ideaal voor tests of in een systemd-unit:

#-status controleren
cat /sys/kernel/mm/transparent_hugepage/enabled
cat /sys/kernel/mm/transparent_hugepage/defrag

# Overschakelen naar madvise (voorbeeld)
echo madvise > /sys/kernel/mm/transparent_hugepage/enabled
echo never   > /sys/kernel/mm/transparent_hugepage/defrag

Ik sla deze commando’s op in een kleine systemd-unit, zodat de instellingen bij het opnieuw opstarten niet verloren gaan.

Statische HugePages reserveren

Voor de reservering aan de HugeTLB-zijde ga ik conservatief te werk en houd ik rekening met een reserve (zie de checklist hieronder):

# Grootte en aantal bekijken
grep -i huge /proc/meminfo

# 32 GB reserveren (2 MB-pagina’s -> 16384)
sysctl -w vm.nr_hugepages=16384
echo "vm.nr_hugepages=16384" > /etc/sysctl.d/90-hugepages.conf

# Optioneel: koppelpunt voor hugetlbfs (handig voor diagnose)
mkdir -p /dev/hugepages
echo "hugetlbfs /dev/hugepages hugetlbfs defaults,pagesize=2M 0 0" >> /etc/fstab
mount -a

Als diensten gebruikmaken van HugeTLB, hebben ze doorgaans MEMLOCK-rechten nodig. Ik stel hiervoor limieten en capabilities in de betreffende systemd-unit in:

[Service]
LimitMEMLOCK=infinity
CapabilityBoundingSet=CAP_IPC_LOCK
AmbientCapabilities=CAP_IPC_LOCK

Controle: maken processen gebruik van grote pagina’s?

Ik controleer per proces het daadwerkelijke gebruik:

# Totalen per proces voor AnonHugePages
grep -i 'AnonHugePages' /proc/$PID/smaps | awk '{s+=$2} END {print s " kB"}'

# Systeemwijde statistieken
grep -i huge /proc/meminfo

MariaDB: voordelen van statische HugePages

MariaDB draait op InnoDB-Bufferpool en een voorspelbaar RAM-gebruik. Ik zet THP voor productieve databases meestal op „nooit“ of stel het in op „madvise“ als ik gerichte tests uitvoer. Reden: bij het forken en bij schrijfbelasting veroorzaken pagina’s van 2 MB hoge „copy-on-write“-kosten, wat opvragingen vertraagt en de prestaties van MariaDB ondermijnt. Statische HugePages voor een grote, eerder leesgerichte bufferpool zorgen voor een gelijkmatigere latentie en verminderen de beheer-overhead. Daarnaast pas ik vm.swappiness en de I/O-scheduler aan, zodat de kernel de buffer niet onnodig vervangt.

Configuratie in MariaDB, NUMA en I/O

• Bufferpool afgestemd op de belasting: innodb_buffer_pool_grootte als hoofdhefboom, innodb_buffer_pool_instances voor parallellisatie.
• Grote pagina's inschakelen (indien ondersteund door deze versie): innodb_use_large_pages=ON ofwel uitsluitend „FORCE“ na een test.
• I/O-pad afvlakken: innodb_flush_method=O_DIRECT, een strakke Write-Amp-strategie, gecontroleerde checkpoints.
• NUMA-valkuilen vermijden: mysqld via numactl --interleave=all starten wanneer er een risico op onevenwichtigheid in de knooppunten dreigt.
• Systeemlimieten: MEMLOCK zoals hierboven; reserveer vooraf voldoende HugePages, zodat het opstarten niet mislukt.

In de praktijk verhoog ik de bufferpool in logische stappen (bijv. 8 → 16 → 32 GB), houd ik de page-fault-percentages in de gaten en vergelijk ik de 99p-latentie. Leesgerichte workloads profiteren hier het meest van; bij een hoge schrijfbelasting analyseer ik de CoW-kosten en fsync-cycli bijzonder zorgvuldig.

Redis: pieken in de latentie voorkomen

Redis is zeer gevoelig voor geheugengedrag en fork-kosten bij Snapshots en AOF-rewrites. Als THP is ingeschakeld, hoeft het systeem bij het kopiëren niet 4 KB, maar 2 MB te verplaatsen – dat is een eenheid die 512 keer zo groot is, wat pieken in de latentie veroorzaakt. Daarom stel ik THP meestal in op „nooit“, wat het geheugengebruik van Redis beter voorspelbaar maakt. Bij grote, voornamelijk leesgerichte key-value-sets kan ik „madvise“ testen, maar alleen met strenge benchmarks. Daarnaast stel ik vm.overcommit_memory=1 in en stem ik de Redis-defragmentatie af, zodat ik de fragmentatie onder controle houd.

Configuratiemodules voor lage fork-kosten

• THP uit: „never“ instellen voor de hele host, de fork-last egaliseren.
• AOF/Snapshot: no-appendfsync-on-rewrite yes, aof-rewrite-incremental-fsync yes, de tijdstippen afstemmen op de daluren.
• Defragmentatie: activedefrag ja, de dwarsbalken nauwkeurig afstellen (active-defrag-threshold-lower, cyclusbesturing).
• Overcommit: vm.overcommit_memory=1, zodat de vorken niet vastlopen.
• Allocator: Redis met jemalloc gebruiken om fragmentatie laag te houden.

Ik meet de effecten met de ingebouwde Redis-latentiebewaking en breng pieken in verband met BGSAVE- of AOF-gebeurtenissen. Als de 99,9p-latentie stabiel daalt, pas ik de instellingen toe in de productieomgeving.

PHP-FPM: een indirecte impuls in de webstack

PHP-FPM zelf verbruikt zelden enorme hoeveelheden RAM, maar heeft wel baat bij minder Kernel-overhead en snellere backends. Als MariaDB en Redis sneller reageren, dalen de TTFB en de responstijd per verzoek. Ik pas het aantal FPM-workers, max_children en de procesmanager (dynamic of static) aan op basis van de belastingcurve. Zo profiteer ik van de voordelen van HugePages in het totale systeem, zonder risico's te lopen. Hier geef ik een praktische inleiding tot dit onderwerp: Server-HugePages op de juiste manier gebruiken.

Praktijk: procesvariabelen, Opcache en dimensionering

• Ik bereken pm.max_children als volgt: (RAM voor PHP) / (gemiddelde RSS per worker) met een reserve van 10–20 %.
• De opcode-cache stabiel houden: voldoende opcache.geheugen_verbruik en opcache.interned_strings_buffer, om hercompilaties te vermijden.
• Consistentie van de allocator: het gebruik van dezelfde C-allocatorfamilies (glibc/jemalloc) voor alle componenten voorkomt onverwachte fragmentatie.
• THP „madvise“ op de host biedt een bescheiden oplossing voor gedeelde bibliotheken, zonder dat de kosten voor forks de pan uit rijzen.

Configuratie: stap voor stap en overzichtstabel

Ik begin elke omschakeling met een schone Inventaris: RAM, schrijf- en leessnelheden, fork-gedrag, piekbelasting. Vervolgens stel ik doelen vast, zoals een constante latentie bij N verzoeken per seconde of minder CPU-tijd in de kernel. Ik stel THP in, afhankelijk van de dienst, en test onder realistische omstandigheden. Vervolgens leg ik de resultaten vast en rol ik de wijzigingen op gecontroleerde wijze uit. De volgende tabel geeft een overzicht van in de praktijk beproefde uitgangspunten, die ik daarna nauwkeurig afstem:

Service	THP-modus	Statische HugePages	Tip
MariaDB	madvise of nooit	Ja, passend bij de bufferpool	Grote, op lezen gerichte groepen hebben hier baat bij; de schrijfbelasting moet zorgvuldig worden getest.
Redis	nooit	Eerder niet	Fork-kosten vermijden, defragmentatie actief houden.
PHP-FPM	madvise	Zelden nodig	De voordelen vloeien voornamelijk indirect voort uit snellere back-ends.

Hostingomgeving: de keuze bepaalt de prestaties

Ik bereik pas dan blijvend constant Situaties waarin de aanbieder de kernel en standaardinstellingen op een zinvolle manier configureert. Hieronder vallen actuele kernels, verstandige THP-standaardinstellingen, voldoende RAM-reserves en ondersteuning door medewerkers met ervaring op het gebied van tuning. Bij het vergelijken van hostingproducten let ik op duidelijke informatie over het afstemmen van MariaDB, Redis en PHP-FPM. Wie het verschil tussen HugeTLB en THP wil begrijpen, heeft baat bij deze beknopte inleiding: Vergelijking tussen HugeTLB en THP. Uit tests is gebleken dat webhoster.de, dankzij zijn betrouwbare configuratie, een sterke kandidaat is voor gegevensintensieve projecten.

Containers, Cgroups en Kubernetes

In containeromgevingen ga ik iets anders te werk, omdat veel instellingen voor de hele host gelden en niet per pod of Docker-container kunnen worden aangepast:

• THP is een keuze van de host. Ik installeer het op de node, niet in de container.
• HugeTLB vereist gereserveerde pagina's op de host. In orkestraties wijs ik expliciet resources toe (2Mi/1Gi-types per node) en plan ik pods daarop in.
• Cgroups: Ik let op geheugen.max/Swap-limieten, zodat onvoorziene OOM-kills de meetreeksen niet verstoren.
• Consistentie van de image: dezelfde versies van de allocator in alle relevante containers, zodat de fragmentatie niet willekeurig afwijkt.

Ik voer tests uit op knooppuntniveau met identieke kernelparameters en wissel de deployments stapsgewijs af om piek- en dalbelasting en koude caches te voorkomen.

Benchmarking, monitoring en capaciteitsplanning

Ik vertrouw niet op mijn gevoel, ik meet hard. Voor en na elke wijziging gebruik ik identieke belastingprofielen en meet ik de latentie, doorvoer, CPU-tijd in de gebruikers- en kernelruimte, en RSS. Ik controleer ook pieken, niet alleen gemiddelden, zodat ik uitschieters vroegtijdig kan herkennen. Bij de planning maak ik gebruik van buffers, zodat groei niet meteen tegen grenzen aanloopt. Zo houd ik de prestaties wekenlang constant en verdeel ik reserves op een verstandige manier.

Meetgrootheden en snelle testopdrachten

• THP-status: cat /sys/kernel/mm/transparent_hugepage/enabled, .../defrag.
• HugeTLB: grep -i huge /proc/meminfo, cat /proc/sys/vm/nr_hugepages.
• Wat het proces betreft: /proc/$PID/smaps naar AnonHugePages doorzoeken.
• Major/Minor-fouten en TLB-indicatoren: perf stat -p $PID -e cycles,task-clock,minor-faults,major-faults,dTLB-load-misses,iTLB-load-misses.
• Redis-latentie: ingebouwde latentietools, correlatie met BGSAVE/AOF.
• MariaDB: GLOBALE STATUS WEERGEVEN en prestatieschema voor buffer-hit-percentages en het gedrag van InnoDB-checkpoints.

Belangrijk is de consistentie van de meetcampagne: dezelfde datasets, dezelfde testperiodes, dezelfde achtergrondbelasting. Anders vergelijk ik appels met peren.

Foutpatronen en snelle oplossingen

Als de responstijden na een THP-switch toenemen, controleer ik dat meteen Vork-Gebeurtenissen en Copy-on-Write-gedrag. Als er zich in MariaDB steeds vaker „slow queries“ voordoen, verlaag ik de schrijfamplitudes, stel ik THP conservatiever in en evalueer ik het I/O-traject. Als Redis sporadische latentiepieken meldt, stel ik THP in op „never“ en controleer ik de tijdstippen van de snapshots. Als de CPU-belasting plotseling stijgt, houd ik TLB-misses indirect in de gaten via Perf-indicatoren en verlaag ik het aantal statische HugePages. Ik documenteer elke aanpassing, zodat ik bij herhaling sneller kan handelen.

Rollback-strategie

• THP-instelling terugzetten naar de vorige modus, alleen opnieuw opstarten indien nodig.
• Statische HugePages stapsgewijs verminderen (vm.nr_hugepages), niet abrupt uitschakelen.
• Dienstspecifieke vlaggen ongedaan maken (innodb_use_large_pages, instellingen voor defragmentatie), en meet vervolgens opnieuw.
• Leg de waarden van voor en na vast, zodat de volgende iteratie sneller verloopt.

Checklist en maatberekening

Voor de berekening van statische HugePages Dan maak ik een eenvoudige berekening: aantal = doelgrootte in bytes gedeeld door paginagrootte (2 MB). Als ik bijvoorbeeld een InnoDB-bufferpool van 32 GB plan, heb ik ongeveer 16384 pagina’s van elk 2 MB nodig. Ik tel daar 5–10 % reserve bij op, zodat kleine schommelingen geen knelpunten veroorzaken. Vervolgens controleer ik bij het opstarten of de instantie daadwerkelijk toegang heeft tot grote pagina’s. Als de meting aan de verwachtingen voldoet, pas ik de instelling toe op andere knooppunten.

Opmerking over HugePages van 1 GB

Bij zeer grote, stabiele bufferpools kunnen pagina’s van 1 GB (HugeTLB, afhankelijk van de CPU/kernel) de druk op de TLB verlichten. Ik pas deze instelling alleen toe als de geheugenbehoefte op lange termijn constant is en er voldoende grote, aaneengesloten reserves beschikbaar zijn. De configuratie volgt hetzelfde patroon als bij 2 MB, maar vereist nauwkeurigere planning en tests, omdat fragmentatie en opstartgedrag gevoeliger zijn.

Kort samengevat

Ik stel linux Ik zet hugepages doelgericht in: THP is doorgaans ingesteld op „madvise“ voor webstacks, „never“ voor Redis en statische pagina’s voor grote, leesgerichte MariaDB-pools. Zo verminder ik TLB-misses, houd ik de latentie constant en voorkom ik geheugenverrassingen. PHP-FPM profiteert hier indirect van, omdat de database en de cache sneller reageren. Met gedegen benchmarking en monitoring toon ik de effecten aan en leg ik de wijzigingen vast. In combinatie met een provider die moderne kernel-standaardinstellingen en passende ondersteuning biedt, blijft de stack ook onder belasting betrouwbaar snel.