Ga naar de inhoud 
NUMA-geheugen bepaalt bij grote databaseservers hoe dicht threads bij het benodigde geheugen werken en in hoeverre latenties de responstijden en doorvoersnelheid beïnvloeden. Ik stem de CPU-toewijzing, de geheugenplaatsing en de omvang van de werklast doelgericht op elkaar af, verminder toegangen op afstand en bereik zo een betrouwbare, planbare Prestaties.
Centrale punten
- Topologie begrijpen: gericht rekening houden met knooppunten, kernen, RAM en interconnect.
- Beleid Kies de juiste instelling: Strict, Preferred, Interleave, afhankelijk van de beoogde workload.
- affiniteit Implementeren: threads, IRQ's en geheugen lokaal koppelen.
- VM's op knooppuntniveau: vCPU en RAM in één NUMA-knooppunt plaatsen.
- Controle Uitvoeren: Remote-Reads, P99-latentie en knooppuntbelasting meten.
Inzicht in de NUMA-topologie
Ik begin elke optimalisatie met de Topologie: Hoeveel NUMA-knooppunten zijn er, hoe zijn de kernen verdeeld, hoe is het RAM-geheugen aan de sockets gekoppeld en hoe duur zijn interconnect-toegangen? Toegang tot lokaal geheugen kost aanzienlijk minder tijd dan toegang over knooppuntgrenzen heen, daarom vermijd ik onnodige Op afstand-manieren. Grote databaseservers hebben er baat bij als ik de werklast zo inplan dat threads en gegevens op hetzelfde knooppunt blijven. Als de actieve gegevenshoeveelheid niet in één knooppunt past, plan ik de verdeling bewust in in plaats van dit aan het standaardgedrag over te laten. Zo houd ik de Latency laag en zorgt voor een gelijkmatige doorvoer, zelfs bij hoge belasting.
BIOS- en hardware-instellingen correct selecteren
Ik controleer in het BIOS of Node-interleaving is uitgeschakeld, zodat de NUMA-scheiding behouden blijft. Ik verdeel de geheugenkanalen symmetrisch over beide sockets en let op de configuratie (1DPC versus 2DPC), zodat de kloksnelheid en bandbreedte niet onnodig dalen. Functies zoals C-staten En bij agressieve energiebesparingsmodi stel ik de latentiedoelstellingen wat conservatiever in, zodat de kernen niet voortdurend uit de slaapstand hoeven te ontwaken. SMT/Hyper-Threading Ik beoordeel dit per workload: voor sterk geheugenafhankelijke OLTP-workloads beperk ik het aantal gelijktijdig actieve SMT-threads per kern om de druk op de cache en de variabiliteit te verminderen. Ik controleer bovendien of PCIe-apparaten (NIC's, NVMe) per socket lokaal zijn aangesloten, zodat hun IRQ's en DMA-paden niet dwars door de interconnect lopen. Wie hier grondig te werk gaat, legt de basis waarop beleidsregels en affiniteiten hun werking kunnen ontplooien.
Het juiste geheugenbeleid kiezen
De keuze van Beleid bepaalt vanaf welk knooppunt de kernel geheugen toewijst en hoe de fallbacks eruitzien. Strict stelt strikte limieten in en breekt toewijzingen af als het doelnode geen ruimte heeft; dit geeft voorrang aan Prestaties over flexibiliteit. Preferred geeft de voorkeur aan één knooppunt, maar schakelt bij schaarste over op andere knooppunten en biedt daarmee een middenweg. Interleave verdeelt pagina’s volgens het round-robin-principe over meerdere knooppunten, wat zinvol kan zijn bij zeer grote, gelijkmatig benutte datasets. Voor veel databases is een lokale strategie met Preferred of Strict meestal de betere keuze Keuze.
| Beleid | Gedrag | Typisch gebruik | Voordelen | Risico's |
|---|---|---|---|---|
| Strikt | Haal alleen gegevens op van het doelnode, anders treedt er een fout op | Latentzkritisch Databases met een duidelijke planning van de knooppunten | Zo lokaal mogelijk Toegang tot, voorspelbare vertragingen | De toewijzing kan mislukken als het knooppunt vol is |
| Voorkeur | Voorkeursknooppunt, terugval op andere mogelijk | Algemeen Werklasten met wisselende belasting | Een goede band met voldoende flexibiliteit | Meer thuiswerk bij schaarste |
| Interleave | Round-robin via meerdere knooppunten | Zeer groot, op grote schaal gebruikt Gegevens | Gespreide belasting van meerdere knooppunten | Minder goede locatie, mogelijk hogere latentie |
Threads, CPU-affiniteit en geheugenbinding
Ik pin threads aan kernen van het doelknooppunt, bind geheugen met numactl en stel IRQ’s zo in dat Gegevens lokaal blijven. Deze combinatie van CPU-affiniteit en memory binding vermindert kostbare remote-reads en zorgt voor een gelijkmatiger verdeling van de looptijd. Voor gedetailleerde controle maak ik gebruik van beleidsregels op proces- of threadniveau en houd ik de bufferpool zo dicht mogelijk bij de actieve worker-threads. Wie zich hier verder in wil verdiepen, vindt praktische stappen voor de CPU-affiniteit, die direct op productieve hosts kunnen worden toegepast. Zo zorg ik voor consistente Latencies zelfs als het systeem zwaar belast is.
Prioriteit geven aan lokale hotsets
Ik identificeer hotsets van de Werkbelasting en plaats ze strikt lokaal, terwijl ‘koude’ gegevens wat flexibeler mogen worden opgeslagen. Door deze prioritering blijf ik bij kernpaden dicht bij het RAM-geheugen van het knooppunt. Als de belasting toeneemt, schaalt de oplossing soepel, omdat de dure paden lokaal blijven draaien. Zonder deze ordening gaat de latentiecurve achteruit zodra threads steeds vaker toegang zoeken over verschillende knooppunten heen. Een duidelijke Binden voorkomt juist dit gedrag op betrouwbare wijze.
Storage- en netwerk-NUMA samenvoegen
Ik organiseer NIC's en NVMe-Ik wijs apparaten gericht toe aan de sockets en leid hun IRQ’s naar lokale kernen. Ik houd Receive-/Transmit-Steering (RSS/RPS/XPS) per knooppunt consistent, zodat pakketten worden verwerkt op dezelfde plek waar ook de databasethreads draaien. Bij NVMe gebruik ik meerdere wachtrijen per kern en pin ik IO-threads lokaal vast, zodat log- en datapaden niet via de interconnect heen en weer gaan. Voor replicatie scheid ik netwerkpaden per knooppunt, zodat inkomende WAL/Redo-streams lokaal terechtkomen. Zo blijven IO– en de CPU-paden zijn congruent, en de database verspilt geen cycli aan onnodige kopieën door het geheugennetwerk heen.
VM's op basis van knooppuntgrootte plannen
Ik stel de specificaties van VM’s zo in dat het aantal vCPU’s en het RAM-geheugen binnen één fysiek NUMA-knooppunt passen, want dat vermindert Latency en interconnect-verkeer. Brede VM’s die groter zijn dan één knooppunt, verspreiden onvermijdelijk geheugentoegangen en verliezen daardoor aan voorspelbaarheid. Als een VM groter moet zijn, plan ik vNUMA expliciet en let ik op een symmetrische verdeling over de knooppunten. Wat de host betreft, vermijd ik oversubscription bij workloads met hoge latentie en houd ik het lokale geheugen per VM gereserveerd. Een snel overzicht van de fysieke knooppuntstructuur wordt geboden door „NUMA-knooppunten plannen“, wat het nemen van beslissingen over de VM-grootte vergemakkelijkt en Fout voorkomt bij het plaatsen.
Houd rekening met de hypervisor-instellingen
Ik controleer hoe de hypervisor vNUMA weergeeft en houd de toewijzing van vCPU-groepen aan fysieke Kernen Consistent. Daarnaast zorg ik ervoor dat de NUMA-topologie van de VM overeenkomt met die van de host, zodat de scheduler lokaal kan blijven. Geheugenreserveringen en anti-affiniteitsregels houd ik zo beperkt mogelijk, maar zo strikt als nodig is. Een hoge VM-dichtheid op één socket vervang ik liever door een verdeling dicht bij de knooppunten. Zo zorg ik ervoor dat Op afstand-Beperk het aantal toegangen tot een minimum en houd de IO-paden stabiel.
Container- en orkestratiepraktijk
In containers plaats ik cpuset-Grenzen consistent: CPU's en bijbehorende geheugenmaskers (cpuset.cpus, cpuset.mems) horen bij elkaar. Systemd-slices en units krijgen vaste CPU-affiniteiten toegewezen, zodat de kernel de geheugenvoorkeur ook daadwerkelijk doorzet. In de orkestratielagen ben ik van plan pods/services dicht bij het knooppunt, maak ik gebruik van topologiebeoordelingen en statische CPU-toewijzing, zodat een workload niet tussen knooppunten heen en weer schommelt. Huge Pages declareer ik expliciet per pod/container en houd ik de grootte en het aantal ervan per knooppunt stabiel. Belangrijk: infrastructuur- en nevenprocessen (logging, sidecars, back-ups) bind ik aan andere kernen of zelfs aan de andere NUMA-knoop, om hotsets van de database niet te verstoren.
NUMA-balancing en optimalisatie van het besturingssysteem
Automatische NUMA-balancing kan lokale Toegang tot verbeteren wanneer workloads verschuiven of fasen sterk veranderen. Ik gebruik het doelgericht, maar houd in de gaten of het heen en weer verplaatsen van pagina’s meer kwaad dan goed doet. Vastgelegde processen met een duidelijke affiniteit hebben vaak meer baat bij handmatig ingestelde beleidsregels dan bij voortdurende herschikking. Kernelparameters, IRQ-regeling en transparante Huge Pages controleer ik telkens in de context van de database en het platform. Als uitgangspunt helpt mij dit NUMA-balancering-Handleiding om instellingen stap voor stap te testen en de verspreiding de latenties te verminderen.
Huge Pages doelgericht inzetten
Ik gebruik Huge Pages om TLB-misses te verminderen en grote Geheugengebieden efficiënter aan te pakken. Voor databaseservers reserveer ik de pagina’s van tevoren, wijs ze toe aan knooppunten en controleer of de instantie ze daadwerkelijk gebruikt. Ik schakel Transparent Huge Pages vaak uit bij latentiedoelstellingen en stel statische Huge Pages in, zodat de toewijzing deterministisch blijft. De nabijheid tot het NUMA-knooppunt blijft echter doorslaggevend; Huge Pages versterken een goede strategie, maar vervangen deze niet. Wie dat negeert, wint nauwelijks Prestaties en loopt het risico op neveneffecten bij het pagineren.
Databases dimensioneren: bufferpool en werklast
Ik plan de actieve werklast zo dat de bufferpool, de lock- en plan-caches en de meest intensief gebruikte Tabellen in één knooppunt passen. Bij zeer grote instanties verdeel ik services of shards over de knooppunten, in plaats van één enorme monolithische instantie over alle knooppunten te spreiden. Voor OLTP-toepassingen houd ik de bufferpool per knooppunt compact en geef ik prioriteit aan lokale hit-rates. Voor OLAP-scans kan interleave in speciale gevallen zinvol zijn, wanneer de gegevenshoeveelheid gigantisch en gelijkmatig is. Zonder deze discipline groeit de Interconnect-verkeer en put de reserves juist op op het moment dat er piekbelastingen optreden.
Databasespecifieke trucs
Ik houd rekening met het proces- en threadmodel van de engine: PostgreSQL maakt gebruik van processen, daarom stel ik de hoofdinstantie, Autovacuum en Checkpointer per knooppunt afzonderlijk in en houd ik shared_buffers lokaal per shard. Bij MySQL/InnoDB ik sorteer bufferpool-instanties op knooppunten en richt IO-threads en log-writers lokaal in. SQL Server profiteert van aangepaste Soft-NUMA en een toewijzing waarbij schedulers en geheugengroepen over de fysieke knooppunten worden verdeeld. Oracle-Ik zet instanties op met lokale Large Pages en verdeel worker- en IO-servers over de knooppunten. Over het algemeen verminder ik arena-contention van de allocator (bijv. jemalloc) door middel van NUMA-bewuste arena’s en zorg ik ervoor dat Lock Manager en ervoor zorgen dat latch-hotspots lokaal blijven door partitionering en sharding langs de knooppunten uit te voeren.
Monitoring: statistieken die ertoe doen
Ik meet Remote-Reads, het verkeer tussen knooppunten, het aantal page faults per knooppunt en de P99-Latency van de relevante query's. Daarnaast houd ik de CPU-belasting per knooppunt, NUMA-miss-verhoudingen en het aandeel van lokale geheugentoegangen in de gaten. Dit overzicht laat zien of het beleid werkt of dat threads ongecontroleerd toegang zoeken tot externe pagina's. Ik breng pieken in verband met beslissingen van de scheduler, migratiegebeurtenissen en toewijzingsfouten. Pas deze statistieken bevestigen dat de Beleid niet alleen in het laboratorium, maar ook op permanente basis in het productiesysteem.
Teststrategie en implementatie
Ik test in stappen: eerst microbenchmarks voor de Bandbreedte en latentie per knooppunt, gevolgd door realistische workloads met koude en warme caches. Ik verhoog de belasting stapsgewijs, meet P95/P99/P99,9 en houd de verdeling in de gaten, niet alleen de gemiddelden. Ik documenteer elke wijziging (beleid, affiniteiten, Huge Pages, IRQ-omleiding) en vergelijk A/B onder identieke omstandigheden. Vóór de uitrol definieer ik Annuleringscriteria en een back-outplan, zodat ik bij regressies snel kan terugkeren naar de vorige configuratie. Een korte soak-test onder continue belasting dekt Drift en migraties die op korte termijn onzichtbaar blijven.
Stapsgewijze werkwijze
Eerst voer ik de Topologie: Aantal knooppunten, kerntoewijzing, geheugenkanalen en interconnect. Vervolgens bepaal ik de beoogde workload per knooppunt en controleer ik of er hotsets in passen. In de volgende stap stel ik CPU-affiniteit, IRQ-routing en memory binding in op proces- of threadniveau. Vervolgens activeer of deactiveer ik NUMA-balancing, afhankelijk van de dynamiek van de workload, en reserveer ik indien nodig Huge Pages per knooppunt. Ten slotte verifieer ik het resultaat met herhaalbare belastingstests en houd ik toezicht op Belangrijke cijfers in continubedrijf.
Praktijkvoorbeelden en valkuilen
Een OLTP-instantie met veel korte transacties levert meetbare voordelen op als ik de werkthreads en de bufferpool instel op een Knooppunt instel en „Strict“ of ‘Preferred’ selecteer. Een datawarehouse met brede scans kan baat hebben bij ‘Interleave’ als de gegevens zeer gelijkmatig worden gebruikt en de knooppunten goed worden benut. VM’s worden merkbaar minder voorspelbaar zodra ze de knooppuntgrenzen overschrijden en de hypervisor geheugen verspringend toewijst. Ik zie vaak dat één enkele ‘brede’ VM de interconnect overbelast en daarmee ook naburige VM’s vertraagt. Deze effecten verdwijnen zodra ik overschakel naar lokale Toewijzing en terugkeer naar een schone vNUMA-configuratie.
Foutscenario's en anti-patronen
Met Strikt verhoog ik het risico dat toewijzingen mislukken en de OOM-killer in werking treedt. Daarom houd ik ruimte vrij op het doelknooppunt, houd ik mislukte pogingen in de gaten en definieer ik fallbacks (bijvoorbeeld gericht aanpassen van de grootte buiten de piekuren). Transparant Huge Pages in de altijd-modus veroorzaakt in latentiepaden Defragmentatie en stallen – ik gebruik statische reserveringen of schakel THP in madvise. Automatische NUMA-balancing kan pagina’s heen en weer verplaatsen bij een schommelende belasting; als ik ‘page bounce’-patronen waarneem, stel ik de beleidsregels weer handmatig in. In VM’s zijn Ballonvaren en geheugencompressie zijn funest voor de voorspelbaarheid; deze functies schakel ik uit voor kritieke databases. Live-migraties tussen knooppunten plan ik alleen tijdens downtime-vensters, of ik verplaats de gegevens eerst aan de databankzijde, zodat de interconnect niet secundair vastloopt.
Capaciteitsplanning en groei
Ik plan per knooppunt een Reserve Ik stel 10–20 % in voor piekbelastingen, Autovacuum/Compaction en periodieke onderhoudstaken. Als de hoeveelheid gegevens toeneemt, schaal ik eerst uit langs de knooppunten (shards/services), in plaats van blindelings de gehele bufferpool te vergroten. Ik voorkom stille „sluipgroei“ door strikte limieten per knooppunt en waarschuwingen zodra lokale hitpercentages dalen of het aandeel van externe verzoeken stijgt. Bij prognoses voor de komende kwartalen houd ik niet alleen rekening met het gegevensvolume, maar ook met Transactiepercentages en gewijzigde toegangsverdelingen, aangezien deze hotsets vaak sneller verschuiven dan de pure opslagbehoefte. Zo blijft het platform stabiel – en vinden uitbreidingen op een gecontroleerde manier plaats, zonder dat dit ten koste gaat van de NUMA-localiteit.
Korte balans
Ik optimaliseer grote databaseservers door NUMA-Topologie, beleidsregels en de omvang van de workload op een gestructureerde manier op elkaar afstemmen. Lokale geheugentoewijzing levert de doorslaggevende milliseconden op, terwijl ongeplande toegang op afstand de P99-latentie opdrijft. In de toekomst plan ik VM’s zo dat ze in knooppunten passen of duidelijk gebruikmaken van vNUMA. Ik pas besturingssysteeminstellingen, affiniteiten en Huge Pages doelgericht toe, controleer het effect ervan en rol wijzigingen alleen uit op basis van meetgegevens. Wie deze stappen ter harte neemt, haalt de verwachte Prestaties bestaat uit moderne hardware en zorgt ervoor dat de platforms ook bij hoge belasting betrouwbaar snel blijven werken.
