Linux NUMA-statistieken correct interpreteren

Linux NUMA Statistieken laten me zien hoe goed processen hun geheugen lokaal behouden en waar externe toegang de latentie verhoogt. Ik leg uit hoe ik deze cijfers doelgericht interpreteer, trends in de loop van de tijd evalueer en daaruit duidelijke optimalisatiestappen afleid voor Prestaties afleiden.

Centrale punten

• Tellers begrijpen: numa_hit, numa_miss, numa_foreign, local_node, other_node, interleave_hit
• De context beoordelen: belastingsprofiel, topologie, type workload
• Trends meten: Voor/na en over intervallen
• Processen controleren: Systeembreed versus per proces
• Tuning toepassen: Affiniteit, Beleid, Plaatsing

Wat NUMA-statistieken werkelijk laten zien

Ik beschouw NUMA-getallen als een kaart voor Opslaglocatie en datapaden. Een hoge numa_hit betekent dat de toewijzingen op het gewenste knooppunt zijn terechtgekomen. Numa_miss geeft daarentegen aan dat de kernel moest uitwijken naar een ander knooppunt. De teller numa_foreign geeft de tegenhanger op het doelknooppunt weer en maakt het beeld compleet. Met local_node en other_node kan ik zien of de toegangen lokaal bleven of dat er gebruik is gemaakt van extern geheugen.

Deze waarden mogen nooit afzonderlijk worden geïnterpreteerd, omdat Werklasten zeer verschillend reageren. Korte processen leiden hier en daar tot missers, zonder dat dit merkbare invloed heeft op de totale prestaties. Interleave-beleidsregels zorgen daarentegen voor opzettelijk gespreide toewijzingen, waardoor de interleave_hit toeneemt. Ik controleer daarom altijd het beoogde beleid en de huidige belasting. Pas dan beslis ik of een waarde aanleiding geeft tot actie of past bij het ontwerp.

Het kernidee is voor mij: Teller leveren signalen op, geen oordelen. Ik zoek patronen in de tijd, geen losse cijfers. Zo kan ik vaststellen of een wijziging in het systeem de lokaliteit verschuift. Pas aan de hand van dit trendbeeld beoordeel ik of ik processen verplaats, het beleid aanpas of CPU-bindingen instel. Elke NUMA-analyse begint daarom met een duidelijke vraagstelling en herhaalbare meetpunten.

Kerncijfers in hun context interpreteren

Ik vergelijk altijd numa_hit en numa_miss met elkaar, in plaats van absolute waarden te beoordelen. Als het aantal missen toeneemt, controleer ik tegelijkertijd de ontwikkeling van numa_foreign op de potentiële doelknooppunten. Als beide met elkaar overeenkomen, duidt dit op een daadwerkelijke verplaatsing en niet op een puur uitleesartefact. local_node en other_node vullen dit beeld aan met de daadwerkelijke toegangen. Zo kan ik vaststellen of een toewijzing weliswaar lokaal is begonnen, maar dat het proces later meer geheugen op afstand heeft gelezen.

Een enkele hoge other_node Ik vind het niet erg als de werklast bewust wordt verdeeld. Webservers met veel workers hebben daarentegen baat bij een consistente lokalisatie. Daarom kijk ik naar individuele processen, niet alleen naar het totaalbeeld. Zodra afzonderlijke diensten uit de pas lopen, pas ik hun plaatsing aan. Pas wanneer er systeemwijde fouten optreden, ga ik op zoek naar oorzaken die te maken hebben met de topologie of de belasting.

Vergelijkingen in de tijd: een meetroutine die vruchten afwerpt

Ik noteer de meterstanden aan het begin en aan het einde van een Laatste fase en bereken het verschil. Afzonderlijke waarden verhullen effecten, verschillen laten bewegingen zien. Herhaalde intervallen van bijvoorbeeld 30 tot 60 seconden volstaan vaak om trends te herkennen. Na implementaties, kernel-updates of hardwarewijzigingen vergelijk ik dezelfde intervallen opnieuw. Als er dan meer missers optreden of als local_node verschuift, is er sprake van een echte verandering.

Dergelijke tijdreeksen bestrijken Plaatsingsfout sneller dan momentopnames. Ik breng de lijnen in verband met het CPU-gebruik, contextwisselingen en het geheugengebruik per knooppunt. Zo kan ik zien of knelpunten in het RAM-geheugen van een knooppunt tot uitwijkbewegingen leiden. Of dat nieuwe processen de verhoudingen binnen het knooppunt verstoren. De pure verhouding tussen hits en misses geef ik altijd weer als een trend, niet als een enkel getal.

Controleer het hele systeem en zoom vervolgens in op de processen

Ik begin met het totaaloverzicht van numastat en controleer pas daarna afzonderlijke processen. Deze volgorde bespaart tijd, omdat veel effecten globaal zichtbaar worden. Voor het procesoverzicht gebruik ik de processpecifieke uitvoer om opvallende diensten te isoleren. Zodra de kandidaten vaststaan, pas ik de Plaatsing over CPU- en geheugenbelasting. Praktische tips hierover staan gebundeld in het artikel over CPU- en geheugenaffiniteit.

Vooral bij Java-diensten, PHP-FPM of databases volstaat vaak een nette Affiniteit, om fouten aanzienlijk te verminderen. Container-orkestratie maskeert deze problemen vaak, omdat schedulers zonder NUMA-bewustzijn taken verdelen. Daarom controleer ik de knooppunttoewijzing per pod of VM. Als de CPU-sets en de RAM-toewijzing overeenkomen, stijgt de local_node-waarde meetbaar. Sommige problemen lossen zich op zodra het proces dicht bij de benodigde dataset draait.

Overzicht van NUMA-tellers (tabel)

De volgende tabel vul ik in wanneer ik een nieuw systeem beoordeel, zodat ik elke Sleutelfiguur snel inordenen. Het geeft de betekenis, de typische interpretatie en mogelijke maatregelen weer. Ik beschouw het niet als een star schema, maar als een checklist. Cruciaal blijft de afstemming met het belastingsprofiel en de servertopologie. Pas met deze context kan ik een zinvolle beslissing nemen.

Teller	Dat betekent	Interpretatie	Benadering
numa_hit	Toewijzing op het gewenste knooppunt	Een hoge waarde is positief	Positie behouden
numa_miss	De toewijzing werd verplaatst naar andere knooppunten	Verhoogd risico op vertragingen	Affinity/Policy controleren
numa_foreign	Vreemde toewijzing op dit knooppunt	Tegenhanger van numa_miss	Doelknooppunten analyseren
local_node	Toegang tot lokaal geheugen	Hoe hoger, hoe goedkoper	Proces dichter bij het RAM-geheugen
other_node	Toegang tot externe opslag	Alleen zorgwekkend zonder opzet	Topologie/belasting controleren
interleave_hit	Treffers bij interleave-verdeling	Te verwachten bij Interleave-beleid	De uniformiteit beoordelen

Met deze Overzicht Dan beslis ik sneller wanneer ik ingrijp. Een stijging van `numa_miss` zonder verklaarbare verandering leidt tot een oorzaakanalyse. Als interleave_hit hoog blijft, controleer ik of het beleid bewust actief is. Als other_node een stijging vertoont zonder toename van de belasting, controleer ik op verdringende workloads. Zo wordt de tabel het uitgangspunt voor gerichte maatregelen.

De NUMA-topologie begrijpen en toepassen

Voordat ik ga tunen, controleer ik de Topologie van de server: sockets, kernen, geheugenkanalen, latentiepaden. Als een proces op socket 0 draait, maar de werk sets op socket 1 staan, neemt de toegangstijd toe. Dit drukt de doorvoer en zorgt ervoor dat de responstijden schommelen. Vooral diensten die veel geheugen verbruiken, merken elke onnodige afstand. Daarom plaats ik gegevensintensieve processen op knooppunten met voldoende vrij RAM-geheugen.

Asymmetrische Aansluitingen versterken effecten, bijvoorbeeld wanneer een knooppunt minder kanalen gebruikt. In dergelijke gevallen verplaats ik de cachegegevens doelgericht, in plaats van het proces te verdelen. Ik configureer VM- en containerhosts zo dat elke instantie een consistente knooppuntkoppeling krijgt. Zo verminder ik het dataverkeer op afstand zonder quota te beperken. De fysieke beperkingen van de machine bepalen de grenzen, en daar houd ik me aan.

Interleave en balancing op de juiste manier inperken

Interleave-beleidsregels verdelen het geheugen bewust over knooppunten, zodat Doorvoer per proces toeneemt of dat hotspots afnemen. In deze configuratie worden hoge interleave_hit-waarden als wenselijk beschouwd. Ik let dan vooral op gelijkmatigheid, niet op absolute lokaliteit. AutoNUMA of NUMA-balancing kan helpen, maar niet in elke situatie.

Ik beslis per situatie of automatisch Evenwicht actief blijft. Bij consistente, langlopende diensten geef ik de voorkeur aan vaste koppelingen. Bij wisselende belasting kan AutoNUMA op een zinvolle manier reageren. Een goed overzicht van de voordelen en risico’s is te vinden in het artikel NUMA-balancing. Pas als het doel en het kader duidelijk zijn, kies ik de geschikte modus.

Workloadpatronen: databases, VM’s, webservices

Databases zijn gevoelig voor Latency tussen de CPU en het RAM-geheugen. Daarom houd ik de instantie, de buffer-cache en de actieve shards op hetzelfde knooppunt. Virtuele machines profiteren van duidelijke CPU-sets plus knooppunt-RAM, zodat gastbesturingssystemen consistente paden zien. Webservices met veel workers presteren optimaal wanneer worker-groepen aan één knooppunt gebonden blijven. Voor de opslagstrategie gebruik ik, afhankelijk van het geval, gerichte NUMA-geheugenbeleidsregels.

Analytische taken en grote scans voer ik daarentegen deels uit verdeeld . Hier levert interleave vaak betere bandbreedtes op dan harde lokaliteit. Het blijft belangrijk om de I/O-patronen van de workload eerlijk te bekijken. Schrijven domineert anders dan lezen, willekeurige toegangen anders dan sequentiële. Ik kies het beleid dat bij het toegangs patroon past, niet het beleid dat in het leerboek goed klinkt.

Praktische meetprocedure en hulpmiddelen

Om te beginnen heb ik genoeg aan numastat en het procesoverzicht. Ik registreer de meterstanden met datum, PID en belastingindicatoren. Het is daarbij belangrijk om binnen identieke tijdsvensters te meten. Zo kunnen voor-en-na-verschillen duidelijk in kaart worden gebracht. In productieve vensters noteer ik de verschillen en breng ik ze in verband met releasetijdstippen.

Bij opvallende Diensten Daarnaast controleer ik de CPU-toewijzing en het knooppuntzicht met tools zoals lscpu, numactl en perf-zicht op de belasting op afstand. Per meetronde documenteer ik het gekozen beleid. Na een wijziging voer ik opnieuw metingen uit. Pas wanneer de trendlijnen zich stabiel verplaatsen, beschouw ik het effect als geslaagd. Blindelings overschakelen leidt gemakkelijk tot schijnverbeteringen.

Veelvoorkomende misvattingen voorkomen

Een hoge interleave_hit is geen fout als interleave bewust is ingeschakeld. Evenzo is een enkele miss bij een lange looptijd verwaarloosbaar. Ik controleer altijd de dichtheid en de verdeling over het interval, niet alleen de pieken. Sommigen interpreteren other_node als zonder meer negatief en zien het karakter van de workload over het hoofd. Daarom bekijk ik eerst het ontwerpdoel en beoordeel ik vervolgens de cijfers.

Nog een misvatting: Algemeen overzicht Goed, dan is alles in orde. Vaak zitten uitschieters slechts in enkele PID’s verborgen. Of verdelen containerschedulers pods over verschillende knooppunten, terwijl een lokale groep zinvoller zou zijn. Dergelijke effecten zie ik pas als ik per proces meet. Zonder die diepgang blijft de analyse onvolledig.

Tuningstappen die effect hebben

Ik begin met Plaatsing: Processen op de knooppunten waar gegevens zich bevinden of zouden moeten bevinden. Vervolgens stel ik CPU-affiniteit in, zodat threads niet van de ene socket naar de andere springen. Daarna volgt het geheugenbindingsbeleid, zodat de kernel op de gewenste locatie geheugen toewijst. Voor variabele belastingen controleer ik de beleidsregels en, indien van toepassing, AutoNUMA.

Daarna zorg ik ervoor dat Consistentie in de levenscyclus: bij herstarts, implementaties en schaalvergrotingen mogen knooppuntverwijzingen niet willekeurig veranderen. Ik documenteer koppelingen als code, zodat ze reproduceerbaar blijven. Daarna voer ik opnieuw metingen uit, evalueer ik de verschillen en beslis ik over fijnafstemming. Elke wijziging verdient duidelijk meetbewijs.

Praktijkvoorbeeld: van flop naar hit

Stel dat een Database vertoont onder belasting meer `numa_miss` en een stijgende `other_node`. De latentie van de query’s schommelt sterker. Ik controleer eerst de procesbinding en stel vast dat de dienst na een rollout op knooppunt A draait, maar dat de cache op knooppunt B is toegewezen. Na een vaste CPU- en geheugentoewijzing aan knooppunt B kantelt de verhouding: numa_hit stijgt, het aantal misses daalt. De responstijden worden constanter en de CPU-belasting daalt licht, omdat er geen externe toegang meer plaatsvindt.

Tegelijkertijd controleer ik de Beleid. Interleave stond onbedoeld aan en heeft toewijzingen verdeeld. Na de omschakeling naar de voorkeursknoop blijft de cache lokaal gesloten. Na een uur meten bevestigen de delta’s de verbetering. Pas dan beschouw ik de afstemming als een succes. Zonder deze controlemeting zou een momentopname een verkeerd beeld hebben gegeven.

Stelcijfers en richtwaarden voor de praktijk

Voor beslissingen maak ik gebruik van betrouwbare Kansen in plaats van afzonderlijke ruwe waarden. Ik bereken per proces het toewijzingspercentage local_alloc = numa_hit / (numa_hit + numa_miss). Daarnaast evalueer ik de Toegangspercentage local_access = local_node / (local_node + other_node). Deze twee samen geven aan of het geheugen ook na de toewijzing lokaal blijft worden gebruikt. Als ruwe richtwaarden hanteer ik het volgende: bij latentiegevoelige diensten streef ik naar remote-toegangen van minder dan 5–10 %. Bij analytische bandbreedte-workloads tolereer ik 20–30 %, mits de doorvoer toeneemt. Doorslaggevend is de Stabiliteit in de loop van de tijd. Ik geef de voorkeur aan een waarde die onder belasting stabiel blijft boven een korte piek met perfecte waarden. Ik leg deze streefwaarden per onderhoudsbeurt vast, zodat latere metingen duidelijk kunnen worden ingedeeld.

Cgroups, containers en valkuilen bij de scheduler

In containeromgevingen controleer ik eerst de cpuset‑Toewijzing: CPU-sets en cpuset.mems moeten dezelfde knoopruimte weergeven, anders ontstaan er onvermijdelijk fouten. Ik zorg ervoor dat pods met vaste CPU-verzoeken niet over meerdere NUMA-knooppunten worden verdeeld, en dat de scheduler geen workers van dezelfde applicatie over verschillende knooppunten verspreidt. Bij burst-types beperk ik het maximale aantal threads per pod zodanig dat deze binnen één knooppunt blijven. Ik documenteer de NUMA-domein per implementatie en eis consistente replicaten (één werkgroep per knooppunt, geen halve groepen verdeeld over twee knooppunten). Als ik de opslagruimte per pod te krap bereken, leg ik mezelf ongewenste druk op: een kleine marge per knooppunt voorkomt dat de kernel vroegtijdig moet uitwijken naar andere knooppunten. Als containers vaak opnieuw worden opgestart, let ik op deterministische binding, zodat Koude start niet toevallig een slechtere locatie krijgen.

Virtuele machines en vNUMA consistent uitlijnen

Bij VM's richt ik mijn aandacht op vNUMA: De virtuele topologie moet overeenkomen met de fysieke. Ik verdeel vCPU's zodanig dat elk vNUMA-knooppunt op precies één fysiek NUMA-knooppunt terechtkomt. Aan de hostzijde pin ik de QEMU/hypervisor-threads aan dit domein en zorg ik ervoor dat het toegewezen RAM volledig vanuit dit knooppunt wordt geleverd. Ballonvaren En overcommit accepteer ik met de nodige terughoudendheid voor VM’s waarbij latentie cruciaal is; agressief ballooning kan hotsets uit het knooppunt verdringen en het aantal externe toegangen doen stijgen. Bij live-migratie controleer ik na de verplaatsing de toewijzingen opnieuw – sommige omgevingen verliezen daarbij de nauwkeurig ingestelde CPU- en geheugentoewijzing. Pas als de vNUMA-uitlijning correct is, evalueer ik numastat systeemwijd: anders verhelp ik de symptomen, niet de oorzaak.

THP, Hugepages en paginamigratie

Transparante enorme pagina's (THP) kunnen zowel helpen als hinderen. Grotere pagina’s verminderen TLB-misses en verbeteren de bandbreedte, maar als de kernel pas laat Hugepages instort of gemigreerd, kunnen ongeschikte Afstanden ontstaan. Ik houd me aan twee regels: ten eerste, de Beleid duidelijk definiëren (bijv. voorkeursknooppunt) en toewijzingen indien mogelijk vanaf het begin lokaal op grote schaal instellen. Ten tweede: bij workloads met vaste, grote caches stel ik waar mogelijk statische hugepages (hugetlb) in, die ik expliciet op een knooppunt reserveer. Dit vermindert fragmentatie en compensatiegerelateerde verplaatsingen. Als ik in tijdreeksen zie dat na een langere looptijd de other_node‑aandeel stijgt, ga ik na of Paginamigratie of er compressie plaatsvindt en of de THP-instellingen bij het patroon passen. Voor mij is het belangrijk dat ik de functie niet globaal uitschakel of inschakel – ik neem per dienst een beslissing en meet het effect op de locatie en de latentie.

Reclaim, Swap en Memory‑Pressure correct interpreteren

Als de Misses stijgen zonder dat er een duidelijke verandering in de rangschikking is, ga ik op zoek naar opslagdruk per knooppunt. Volle knooppunten dwingen de kernel tot reclaim en compactie, deels veroorzaakt door kswapd op een ander knooppunt – dat heeft neveneffecten op de tellers. Ik controleer per knooppunt het vrije geheugen en de bezettingsgraad van de paginacache. Geactiveerd Wissel kan hotsets verdringen en de latentie enorm doen toenemen; voor bijzonder gevoelige diensten schakel ik swap uit of beperk ik deze strikt. In logbestanden en perf-overzichten zoek ik naar reclaim-pieken tijdens piekbelastingen. Het doel is om voldoende vrije, lokale RAM op het doelknooppunt behouden, zodat toewijzingen niet wegdrijven. Als daarvoor caches moeten worden verkleind, geef ik voorrang aan de werkset van de dienst boven de generieke paginacache.

Praktische opdrachten en evaluatie

Voor het procesoverzicht gebruik ik numastat -p en voeg toe: cat /proc//numa_maps, om de toewijzingen per gebied (anoniem, op basis van bestanden) en per knooppunt te bekijken. numactl --hardware geeft me latentiematrices en knooppuntgroottes, lscpu --extended toont de CPU-toewijzing aan knooppunten. Voor geheugentoegangen waarbij de nadruk ligt op lange paden, stel ik perf mem om belastingspatronen te verifiëren. Ik verzamel delta's op een reproduceerbare manier, bijvoorbeeld:

Meetroutine

• t0: numastat (totaal) en numastat -p voor het opslaan van de Top-PID’s
• 30–60 s belasting, identieke trainingsfase
• t1: numastat opnieuw lezen, delta's per teller berekenen
• Parallelle CPU-, contextwissel- en knooppuntgeheugenwaarden registreren

Vervolgens bereken ik de Kansen en markeer ik welke processen aanzienlijk afwijken van de systeembrede trends. Als er nog onzekerheid blijft bestaan, herhaal ik de meting minstens drie keer. Alleen consistente afwijkingen beschouw ik als betrouwbaar. Voor continue monitoring breng ik de tellers in kaart op tijdreeksen en koppel ik ze aan release-metadata – zo herken ik Regressiepunten onmiddellijk.

Checklist voor een gestructureerde NUMA-tuning

• Doelstelling vaststellen: latentie versus doorvoer, vaste belasting versus variabele belasting
• Topologie in kaart brengen: knooppunten, latenties, vrije RAM-reserves per knooppunt
• Baseline meten: totaal aantal numastat en per proces, verhoudingen afleiden
• Plaatsing aanpassen: CPU-affiniteit, geheugenbinding, beleidsregels
• Containers/VM’s configureren: cpuset.cpus = knooppunt, cpuset.mems dienovereenkomstig; vNUMA correct toewijzen
• Kies bewust voor THP/Hugepages, houd fragmentatie in de gaten
• Geheugendruk verminderen: headroom per knooppunt, swap-strategie controleren
• Nacontrole: delta’s vergelijken, stabiliteit in de tijd waarborgen
• Documenteren: koppelingen als code, release-opmerkingen met NUMA-context

Kort samengevat

Ik analyseer NUMA-cijfers door Signalen Lees in dit verband: tellerparen, tijdsverloop en procesoverzicht. De sleutelwaarden numa_hit, numa_miss, numa_foreign, local_node, other_node en interleave_hit geven mij inzicht in lokaliteit, uitwijkbewegingen en distributiestrategieën. Ik neem beslissingen op basis van de topologie en de workload, niet op basis van starre drempelwaarden. Tuning begint met plaatsing, affiniteit, een passend beleid en een nauwkeurige meetroutine. Zo lever ik constante Prestaties, omdat de CPU en het RAM-geheugen geschikt zijn voor de toepassing en er zelden grote afstanden moeten worden afgelegd.