NUMA-bewustzijn en CPU-pinning voor dedicated servers

Op elke server met meerdere sockets zijn de locatie waar een proces draait en de locatie waar het geheugen zich bevindt twee verschillende zaken, en als deze niet synchroon lopen, is dat een van de gemakkelijkste manieren om prestaties te verspillen. NUMA-bewustzijn en CPU-pinning zijn de twee knoppen die dit oplossen. Dit bericht behandelt hoe NUMA werkt, hoe je het op Linux kunt inspecteren en hoe je workloads correct kunt pinnen voor databases, AI-training en latentiegevoelige diensten.

Hoe NUMA werkt op servers met meerdere sockets

Een NUMA-node (Non-Uniform Memory Access) is een groep CPU-kernen die via een speciale geheugencontroller aan een lokaal RAM-blok zijn gekoppeld. Op een server met twee sockets heb je meestal twee nodes. Elke core kan elk adres lezen, maar lokale toegang duurt ongeveer 80 ns, terwijl een cross-socket-hop via Intel's UPI of AMD's Infinity Fabric ongeveer 130–150 ns duurt. Op grotere systemen met meer sockets kan de node in het slechtste geval de 250 ns overschrijden.

De bandbreedte volgt hetzelfde patroon. Een Sapphire Rapids-systeem met twee sockets kan ongeveer 600 GB/s aanhouden wanneer cores het lokale geheugen benaderen, maar de verbinding tussen de sockets is slechts een fractie daarvan, waardoor het verkeer dat deze verbinding passeert snel vastloopt. Processoren met veel cores maken dit gedetailleerder: Intel's Sub-NUMA Clustering (SNC) en AMD's Nodes Per Socket (NPS) splitsen elke socket op in meerdere NUMA-domeinen, zodat een "twee-socket" systeem gemakkelijk vier of acht nodes aan Linux kan presenteren.

Zonder NUMA-bewustzijn zal de Linux-scheduler een thread vrolijk tussen sockets migreren terwijl de werkset op de oorspronkelijke node blijft. Elke volgende toegang wordt een externe toegang. Het zichtbare symptoom is een hoog CPU-gebruik met een lage werkelijke doorvoer, omdat de cores hun tijd besteden aan het wachten op geheugen. I/O-apparaten maken dit nog erger. Een GPU of NIC is aangesloten op een specifieke PCIe-root, die bij één NUMA-knooppunt hoort. Als het proces dat het voedt op de andere socket draait, gaat elke DMA-overdracht via de interconnect.

NUMA-topologie inspecteren op Linux

Vier tools dekken bijna alles wat u nodig hebt:

• lscpu voor een snel overzicht van sockets en knooppunten.
• numactl --hardware voor het totale geheugen van de nodes en de matrix met de afstanden tussen de nodes.
• numastat voor hit/miss-tellers per proces.
• lstopo (van hwloc) voor cachehiërarchie en PCIe-apparaatlocatie.

Begin met numactl --hardware. Hierin staan alle nodes, de bijbehorende cores en geheugen, en de afstandsmatrix. Een waarde van 10 is lokaal, 20+ is op afstand. Als je één enkele node ziet op een multi-socket-systeem, heeft je BIOS Node Interleaving ingeschakeld en verbergt het de topologie; los dat eerst op (zie hieronder).

Voor een specifiek proces geeft numastat -p <PID> wordt uitgesplitst waar het geheugen daadwerkelijk is toegewezen. Vier tellers zijn van belang:

• numa_hit: geheugen toegewezen op de beoogde node. U wilt dat dit hoog is.
• numa_miss: het beoogde knooppunt was vol, de toewijzing is elders terechtgekomen.
• numa_foreign: een ander knooppunt probeerde lokaal toe te wijzen maar kon dat niet, duidt op geheugendruk.
• other_node: pagina's toegewezen op een andere node dan waar het proces draait. Hoge waarden hier zijn het klassieke teken van slechte pinning.

Voor GPU- of NIC-workloads voert u lstopo-no-graphics en kijk aan welke NUMA-node elk PCIe-apparaat is gekoppeld. Als de cores die het apparaat aansturen zich op de andere node bevinden, is dat het eerste wat je moet oplossen.

CPU-pinning en geheugenbeleid

CPU-pinning (of CPU-affiniteit) bindt een proces aan specifieke cores, zodat de scheduler het niet kan migreren. Op zichzelf is dat niet voldoende, omdat Linux standaard een first-touch-geheugenbeleid hanteert: pagina's worden toegewezen aan de node die er als eerste naar schrijft. Als een thread op de verkeerde node start voordat deze wordt vastgezet, blijft het geheugen daar. Je moet zowel de plaatsing als de toewijzing samen beheren.

Drie tools dekken de meest voorkomende gevallen:

numactl ondersteunt vier geheugenbeleidsregels:

• --membind=N: alleen toewijzen op knooppunt N, mislukken indien vol.
• --preferred=N: geef de voorkeur aan knooppunt N, val indien nodig terug op andere.
• --interleave=all: round-robin over knooppunten voor een gelijkmatige bandbreedteverdeling.
• --localalloc: toewijzen op de node waarop de actieve CPU zich bevindt.

Een workload aan één node koppelen

Bepaal eerst welke cores bij uw doelknooppunt horen:

numactl --hardware

Start vervolgens de applicatie die aan dat knooppunt is gekoppeld voor zowel cores als geheugen:

numactl --cpunodebind=0 --membind=0 ./your_application

Voor een reeds draaiend proces past u de CPU-affiniteit aan met taskset:

taskset -cp 0-7 <PID>

Om ervoor te zorgen dat het een herstart overleeft, stelt u dit in de systemd-unit in:

[Service]
CPUAffinity=0-7
NUMAPolicy=bind
NUMAMask=0

Laad opnieuw en start opnieuw op:

sudo systemctl daemon-reload && sudo systemctl restart <service>

Wanneer u handmatig toewijst, schakel dan de automatische balancer van de kernel uit, zodat deze uw toewijzing niet tegenwerkt:

sysctl -w kernel.numa_balancing=0

Voeg het toe aan /etc/sysctl.conf om het permanent te maken. Controleer vervolgens met numastat -p <PID> gedurende een paar minuten echte werklast. Als other_node dicht bij nul blijft, werkt de pinning.

Een strategie kiezen op basis van de werklast

Het juiste beleid hangt af van de vraag of uw workload meer baat heeft bij lage latentie of bij totale bandbreedte over alle knooppunten.

Specifiek voor GPU-workloads: voer lstopo om te bepalen op welke NUMA-node de GPU zich bevindt, en start vervolgens het trainings- of inferentieproces met numactl --cpunodebind=N --membind=N voor diezelfde N. Dit is een van de gemakkelijkste manieren om winst te boeken op een GPU-server met meerdere sockets, omdat de standaardplaatsing door de scheduler vaak verkeerd is.

Voor HPC- en MPI-workloads die beide sockets beslaan, koppel je elke rank aan een enkel knooppunt met localalloc in plaats van alles te interleaven. Elke rank krijgt lokaal geheugen en de parallelliteit vindt plaats op rankniveau.

Een praktische opmerking: als u aan één knooppunt koppelt, laat dan 2–4 GB ruimte over op dat knooppunt. Een knooppunt dat bijna vol is, activeert terugwinning, wat u de latentie kost die u juist probeerde te besparen.

Te controleren BIOS- en kernelinstellingen

De uitvoer van de tool is slechts zo nauwkeurig als de topologie die de firmware weergeeft. Enkele instellingen die moeten worden gecontroleerd:

• Node Interleaving: schakel dit uit. Wanneer dit is ingeschakeld, presenteert het BIOS al het geheugen als één enkele vlakke pool en verbergt het NUMA volledig voor het besturingssysteem. numactl --hardware In dat geval wordt één node weergegeven op een systeem met meerdere sockets.
• Sub-NUMA-clustering (Intel) of Nodes Per Socket (AMD): schakel dit in op processors met veel cores wanneer u een fijnere lokalisatie wilt. Bevestigt lscpu na het opnieuw opstarten.
• vm.zone_reclaim_mode: stel in op 0 voor de meeste productieservers. Een waarde anders dan nul vordert lokaal geheugen agressief terug in plaats van op afstand toe te wijzen, wat nuttige paginacache kan verdringen.
• kernel.numa_balancing: laat ingeschakeld voor algemene workloads, schakel uit wanneer u handmatig vastzet. De auto-balancer zal pagina's en threads migreren op manieren die in strijd zijn met uw beleid.

Als u NUMA-tuning uitvoert op bare metal waar u de BIOS, kernelparameters en IRQ-affiniteit beheert, kunt u al het bovenstaande toepassen zonder om de hypervisor-abstracties heen te werken. Dat is de belangrijkste reden waarom dit soort werk gemakkelijker is op dedicated hardware dan in cloud-VM's.

Voor dedicated servers met meerdere sockets en volledige root-toegang, zie de dedicated servers van FDC.