{"id":21443,"date":"2026-09-16T08:36:31","date_gmt":"2026-09-16T06:36:31","guid":{"rendered":"https:\/\/webhosting.de\/linux-numa-statistiken-auswerten\/"},"modified":"2026-09-16T08:36:31","modified_gmt":"2026-09-16T06:36:31","slug":"linux-numa-statistieken-analyseren","status":"publish","type":"post","link":"https:\/\/webhosting.de\/nl\/linux-numa-statistiken-auswerten\/","title":{"rendered":"Linux NUMA-statistieken correct interpreteren"},"content":{"rendered":"<p><strong>Linux NUMA<\/strong> 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 <strong>Prestaties<\/strong> afleiden.<\/p>\n\n<h2>Centrale punten<\/h2>\n<ul>\n  <li><strong>Tellers begrijpen<\/strong>: numa_hit, numa_miss, numa_foreign, local_node, other_node, interleave_hit<\/li>\n  <li><strong>De context beoordelen<\/strong>: belastingsprofiel, topologie, type workload<\/li>\n  <li><strong>Trends meten<\/strong>: Voor\/na en over intervallen<\/li>\n  <li><strong>Processen controleren<\/strong>: Systeembreed versus per proces<\/li>\n  <li><strong>Tuning toepassen<\/strong>: Affiniteit, Beleid, Plaatsing<\/li>\n<\/ul>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/linux-numa-analyse-8293.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Wat NUMA-statistieken werkelijk laten zien<\/h2>\n\n<p>Ik beschouw NUMA-getallen als een kaart voor <strong>Opslaglocatie<\/strong> en datapaden. Een hoge <strong>numa_hit<\/strong> 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.<\/p>\n\n<p>Deze waarden mogen nooit afzonderlijk worden ge\u00efnterpreteerd, omdat <strong>Werklasten<\/strong> 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.<\/p>\n\n<p>Het kernidee is voor mij: <strong>Teller<\/strong> 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.<\/p>\n\n<h2>Kerncijfers in hun context interpreteren<\/h2>\n\n<p>Ik vergelijk altijd <strong>numa_hit<\/strong> 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\u00eble 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.<\/p>\n\n<p>Een enkele hoge <strong>other_node<\/strong> 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.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/linux_numa_meeting_8326.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Vergelijkingen in de tijd: een meetroutine die vruchten afwerpt<\/h2>\n\n<p>Ik noteer de meterstanden aan het begin en aan het einde van een <strong>Laatste fase<\/strong> 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.<\/p>\n\n<p>Dergelijke tijdreeksen bestrijken <strong>Plaatsingsfout<\/strong> 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.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/linux-numa-stat-analysis-4857.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Controleer het hele systeem en zoom vervolgens in op de processen<\/h2>\n\n<p>Ik begin met het totaaloverzicht van <strong>numastat<\/strong> 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 <strong>Plaatsing<\/strong> over CPU- en geheugenbelasting. Praktische tips hierover staan gebundeld in het artikel over <a href=\"https:\/\/webhosting.de\/nl\/server-numa-locality-cpu-geheugen-affiniteit-optimalisatie-core\/\">CPU- en geheugenaffiniteit<\/a>.<\/p>\n\n<p>Vooral bij Java-diensten, PHP-FPM of databases volstaat vaak een nette <strong>Affiniteit<\/strong>, 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.<\/p>\n\n<h2>Overzicht van NUMA-tellers (tabel)<\/h2>\n\n<p>De volgende tabel vul ik in wanneer ik een nieuw systeem beoordeel, zodat ik elke <strong>Sleutelfiguur<\/strong> 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.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th><strong>Teller<\/strong><\/th>\n      <th><strong>Dat betekent<\/strong><\/th>\n      <th><strong>Interpretatie<\/strong><\/th>\n      <th><strong>Benadering<\/strong><\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>numa_hit<\/td>\n      <td>Toewijzing op het gewenste knooppunt<\/td>\n      <td>Een hoge waarde is positief<\/td>\n      <td>Positie behouden<\/td>\n    <\/tr>\n    <tr>\n      <td>numa_miss<\/td>\n      <td>De toewijzing werd verplaatst naar andere knooppunten<\/td>\n      <td>Verhoogd risico op vertragingen<\/td>\n      <td>Affinity\/Policy controleren<\/td>\n    <\/tr>\n    <tr>\n      <td>numa_foreign<\/td>\n      <td>Vreemde toewijzing op dit knooppunt<\/td>\n      <td>Tegenhanger van numa_miss<\/td>\n      <td>Doelknooppunten analyseren<\/td>\n    <\/tr>\n    <tr>\n      <td>local_node<\/td>\n      <td>Toegang tot lokaal geheugen<\/td>\n      <td>Hoe hoger, hoe goedkoper<\/td>\n      <td>Proces dichter bij het RAM-geheugen<\/td>\n    <\/tr>\n    <tr>\n      <td>other_node<\/td>\n      <td>Toegang tot externe opslag<\/td>\n      <td>Alleen zorgwekkend zonder opzet<\/td>\n      <td>Topologie\/belasting controleren<\/td>\n    <\/tr>\n    <tr>\n      <td>interleave_hit<\/td>\n      <td>Treffers bij interleave-verdeling<\/td>\n      <td>Te verwachten bij Interleave-beleid<\/td>\n      <td>De uniformiteit beoordelen<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<p>Met deze <strong>Overzicht<\/strong> 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.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/NUMA_Statistik_Auswertung_1023.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>De NUMA-topologie begrijpen en toepassen<\/h2>\n\n<p>Voordat ik ga tunen, controleer ik de <strong>Topologie<\/strong> 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.<\/p>\n\n<p>Asymmetrische <strong>Aansluitingen<\/strong> 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.<\/p>\n\n<h2>Interleave en balancing op de juiste manier inperken<\/h2>\n\n<p>Interleave-beleidsregels verdelen het geheugen bewust over knooppunten, zodat <strong>Doorvoer<\/strong> 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.<\/p>\n\n<p>Ik beslis per situatie of automatisch <strong>Evenwicht<\/strong> 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\u2019s is te vinden in het artikel <a href=\"https:\/\/webhosting.de\/nl\/numa-balancing-uitschakelen-of-ingeschakeld-laten-voor-optimale-linux-prestaties\/\">NUMA-balancing<\/a>. Pas als het doel en het kader duidelijk zijn, kies ik de geschikte modus.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/NUMA_Statistik_Auswertung_1023.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Workloadpatronen: databases, VM\u2019s, webservices<\/h2>\n\n<p>Databases zijn gevoelig voor <strong>Latency<\/strong> 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 \u00e9\u00e9n knooppunt gebonden blijven. Voor de opslagstrategie gebruik ik, afhankelijk van het geval, gerichte <a href=\"https:\/\/webhosting.de\/nl\/numa-geheugenbeleid-databankserver-optimalisatie-server\/\">NUMA-geheugenbeleidsregels<\/a>.<\/p>\n\n<p>Analytische taken en grote scans voer ik daarentegen deels uit <strong>verdeeld<\/strong> . 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\u00eble. Ik kies het beleid dat bij het toegangs patroon past, niet het beleid dat in het leerboek goed klinkt.<\/p>\n\n<h2>Praktische meetprocedure en hulpmiddelen<\/h2>\n\n<p>Om te beginnen heb ik genoeg aan <strong>numastat<\/strong> 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.<\/p>\n\n<p>Bij opvallende <strong>Diensten<\/strong> 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.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/linux_numa_auswertung_7463.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Veelvoorkomende misvattingen voorkomen<\/h2>\n\n<p>Een hoge <strong>interleave_hit<\/strong> 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.<\/p>\n\n<p>Nog een misvatting: <strong>Algemeen overzicht<\/strong> Goed, dan is alles in orde. Vaak zitten uitschieters slechts in enkele PID\u2019s 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.<\/p>\n\n<h2>Tuningstappen die effect hebben<\/h2>\n\n<p>Ik begin met <strong>Plaatsing<\/strong>: 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.<\/p>\n\n<p>Daarna zorg ik ervoor dat <strong>Consistentie<\/strong> 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.<\/p>\n\n<h2>Praktijkvoorbeeld: van flop naar hit<\/h2>\n\n<p>Stel dat een <strong>Database<\/strong> vertoont onder belasting meer `numa_miss` en een stijgende `other_node`. De latentie van de query\u2019s 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.<\/p>\n\n<p>Tegelijkertijd controleer ik de <strong>Beleid<\/strong>. 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\u2019s de verbetering. Pas dan beschouw ik de afstemming als een succes. Zonder deze controlemeting zou een momentopname een verkeerd beeld hebben gegeven.<\/p>\n\n<h2>Stelcijfers en richtwaarden voor de praktijk<\/h2>\n\n<p>Voor beslissingen maak ik gebruik van betrouwbare <strong>Kansen<\/strong> in plaats van afzonderlijke ruwe waarden. Ik bereken per proces het toewijzingspercentage local_alloc = numa_hit \/ (numa_hit + numa_miss). Daarnaast evalueer ik de <strong>Toegangspercentage<\/strong> 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\u201310 %. Bij analytische bandbreedte-workloads tolereer ik 20\u201330 %, mits de doorvoer toeneemt. Doorslaggevend is de <strong>Stabiliteit<\/strong> 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.<\/p>\n\n<h2>Cgroups, containers en valkuilen bij de scheduler<\/h2>\n\n<p>In containeromgevingen controleer ik eerst de <strong>cpuset<\/strong>\u2011Toewijzing: CPU-sets en <em>cpuset.mems<\/em> 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 \u00e9\u00e9n knooppunt blijven. Ik documenteer de <strong>NUMA-domein<\/strong> per implementatie en eis consistente replicaten (\u00e9\u00e9n 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 <strong>Koude start<\/strong> niet toevallig een slechtere locatie krijgen.<\/p>\n\n<h2>Virtuele machines en vNUMA consistent uitlijnen<\/h2>\n\n<p>Bij VM's richt ik mijn aandacht op <strong>vNUMA<\/strong>: De virtuele topologie moet overeenkomen met de fysieke. Ik verdeel vCPU's zodanig dat elk vNUMA-knooppunt op precies \u00e9\u00e9n 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. <strong>Ballonvaren<\/strong> En overcommit accepteer ik met de nodige terughoudendheid voor VM\u2019s 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 \u2013 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.<\/p>\n\n<h2>THP, Hugepages en paginamigratie<\/h2>\n\n<p><strong>Transparante enorme pagina's<\/strong> (THP) kunnen zowel helpen als hinderen. Grotere pagina\u2019s verminderen TLB-misses en verbeteren de bandbreedte, maar als de kernel pas laat Hugepages <em>instort<\/em> of gemigreerd, kunnen ongeschikte <strong>Afstanden<\/strong> ontstaan. Ik houd me aan twee regels: ten eerste, de <strong>Beleid<\/strong> duidelijk defini\u00ebren (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 <em>other_node<\/em>\u2011aandeel stijgt, ga ik na of <strong>Paginamigratie<\/strong> 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 \u2013 ik neem per dienst een beslissing en meet het effect op de locatie en de latentie.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/linux-numa-analyse-4746.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Reclaim, Swap en Memory\u2011Pressure correct interpreteren<\/h2>\n\n<p>Als de Misses stijgen zonder dat er een duidelijke verandering in de rangschikking is, ga ik op zoek naar <strong>opslagdruk<\/strong> per knooppunt. Volle knooppunten dwingen de kernel tot reclaim en compactie, deels veroorzaakt door <em>kswapd<\/em> op een ander knooppunt \u2013 dat heeft neveneffecten op de tellers. Ik controleer per knooppunt het vrije geheugen en de bezettingsgraad van de paginacache. Geactiveerd <strong>Wissel<\/strong> 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, <strong>lokale<\/strong> 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.<\/p>\n\n<h2>Praktische opdrachten en evaluatie<\/h2>\n\n<p>Voor het procesoverzicht gebruik ik <code>numastat -p<\/code> en voeg toe: <code>cat \/proc\/\/numa_maps<\/code>, om de toewijzingen per gebied (anoniem, op basis van bestanden) en per knooppunt te bekijken. <code>numactl --hardware<\/code> geeft me latentiematrices en knooppuntgroottes, <code>lscpu --extended<\/code> toont de CPU-toewijzing aan knooppunten. Voor geheugentoegangen waarbij de nadruk ligt op lange paden, stel ik <code>perf mem<\/code> om belastingspatronen te verifi\u00ebren. Ik verzamel delta's op een reproduceerbare manier, bijvoorbeeld:<\/p>\n\n<p><em>Meetroutine<\/em><\/p>\n<ul>\n  <li>t0: numastat (totaal) en numastat -p voor het opslaan van de Top-PID\u2019s<\/li>\n  <li>30\u201360 s belasting, identieke trainingsfase<\/li>\n  <li>t1: numastat opnieuw lezen, delta's per teller berekenen<\/li>\n  <li>Parallelle CPU-, contextwissel- en knooppuntgeheugenwaarden registreren<\/li>\n<\/ul>\n\n<p>Vervolgens bereken ik de <strong>Kansen<\/strong> 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 \u2013 zo herken ik <strong>Regressiepunten<\/strong> onmiddellijk.<\/p>\n\n<h2>Checklist voor een gestructureerde NUMA-tuning<\/h2>\n\n<ul>\n  <li>Doelstelling vaststellen: latentie versus doorvoer, vaste belasting versus variabele belasting<\/li>\n  <li>Topologie in kaart brengen: knooppunten, latenties, vrije RAM-reserves per knooppunt<\/li>\n  <li>Baseline meten: totaal aantal numastat en per proces, verhoudingen afleiden<\/li>\n  <li>Plaatsing aanpassen: CPU-affiniteit, geheugenbinding, beleidsregels<\/li>\n  <li>Containers\/VM\u2019s configureren: cpuset.cpus = knooppunt, cpuset.mems dienovereenkomstig; vNUMA correct toewijzen<\/li>\n  <li>Kies bewust voor THP\/Hugepages, houd fragmentatie in de gaten<\/li>\n  <li>Geheugendruk verminderen: headroom per knooppunt, swap-strategie controleren<\/li>\n  <li>Nacontrole: delta\u2019s vergelijken, stabiliteit in de tijd waarborgen<\/li>\n  <li>Documenteren: koppelingen als code, release-opmerkingen met NUMA-context<\/li>\n<\/ul>\n\n<h2>Kort samengevat<\/h2>\n\n<p>Ik analyseer NUMA-cijfers door <strong>Signalen<\/strong> 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\u00ebn. 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 <strong>Prestaties<\/strong>, omdat de CPU en het RAM-geheugen geschikt zijn voor de toepassing en er zelden grote afstanden moeten worden afgelegd.<\/p>","protected":false},"excerpt":{"rendered":"<p>Linux NUMA-statistieken correct analyseren: NUMA-statistieken begrijpen, geheugenlokalisatie controleren en de serverprestaties doelgericht verbeteren.<\/p>","protected":false},"author":1,"featured_media":21436,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[676],"tags":[],"class_list":["post-21443","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-server_vm"],"acf":[],"_wp_attached_file":null,"_wp_attachment_metadata":null,"litespeed-optimize-size":null,"litespeed-optimize-set":null,"_elementor_source_image_hash":null,"_wp_attachment_image_alt":null,"stockpack_author_name":null,"stockpack_author_url":null,"stockpack_provider":null,"stockpack_image_url":null,"stockpack_license":null,"stockpack_license_url":null,"stockpack_modification":null,"color":null,"original_id":null,"original_url":null,"original_link":null,"unsplash_location":null,"unsplash_sponsor":null,"unsplash_exif":null,"unsplash_attachment_metadata":null,"_elementor_is_screenshot":null,"surfer_file_name":null,"surfer_file_original_url":null,"envato_tk_source_kit":null,"envato_tk_source_index":null,"envato_tk_manifest":null,"envato_tk_folder_name":null,"envato_tk_builder":null,"envato_elements_download_event":null,"_menu_item_type":null,"_menu_item_menu_item_parent":null,"_menu_item_object_id":null,"_menu_item_object":null,"_menu_item_target":null,"_menu_item_classes":null,"_menu_item_xfn":null,"_menu_item_url":null,"_trp_menu_languages":null,"rank_math_primary_category":null,"rank_math_title":null,"inline_featured_image":null,"_yoast_wpseo_primary_category":null,"rank_math_schema_blogposting":null,"rank_math_schema_videoobject":null,"_oembed_049c719bc4a9f89deaead66a7da9fddc":null,"_oembed_time_049c719bc4a9f89deaead66a7da9fddc":null,"_yoast_wpseo_focuskw":null,"_yoast_wpseo_linkdex":null,"_oembed_27e3473bf8bec795fbeb3a9d38489348":null,"_oembed_c3b0f6959478faf92a1f343d8f96b19e":null,"_trp_translated_slug_en_us":null,"_wp_desired_post_slug":null,"_yoast_wpseo_title":null,"tldname":null,"tldpreis":null,"tldrubrik":null,"tldpolicylink":null,"tldsize":null,"tldregistrierungsdauer":null,"tldtransfer":null,"tldwhoisprivacy":null,"tldregistrarchange":null,"tldregistrantchange":null,"tldwhoisupdate":null,"tldnameserverupdate":null,"tlddeletesofort":null,"tlddeleteexpire":null,"tldumlaute":null,"tldrestore":null,"tldsubcategory":null,"tldbildname":null,"tldbildurl":null,"tldclean":null,"tldcategory":null,"tldpolicy":null,"tldbesonderheiten":null,"tld_bedeutung":null,"_oembed_d167040d816d8f94c072940c8009f5f8":null,"_oembed_b0a0fa59ef14f8870da2c63f2027d064":null,"_oembed_4792fa4dfb2a8f09ab950a73b7f313ba":null,"_oembed_33ceb1fe54a8ab775d9410abf699878d":null,"_oembed_fd7014d14d919b45ec004937c0db9335":null,"_oembed_21a029d076783ec3e8042698c351bd7e":null,"_oembed_be5ea8a0c7b18e658f08cc571a909452":null,"_oembed_a9ca7a298b19f9b48ec5914e010294d2":null,"_oembed_f8db6b27d08a2bb1f920e7647808899a":null,"_oembed_168ebde5096e77d8a89326519af9e022":null,"_oembed_cdb76f1b345b42743edfe25481b6f98f":null,"_oembed_87b0613611ae54e86e8864265404b0a1":null,"_oembed_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_oembed_time_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_tldname":null,"_tldclean":null,"_tldpreis":null,"_tldcategory":null,"_tldsubcategory":null,"_tldpolicy":null,"_tldpolicylink":null,"_tldsize":null,"_tldregistrierungsdauer":null,"_tldtransfer":null,"_tldwhoisprivacy":null,"_tldregistrarchange":null,"_tldregistrantchange":null,"_tldwhoisupdate":null,"_tldnameserverupdate":null,"_tlddeletesofort":null,"_tlddeleteexpire":null,"_tldumlaute":null,"_tldrestore":null,"_tldbildname":null,"_tldbildurl":null,"_tld_bedeutung":null,"_tldbesonderheiten":null,"_oembed_ad96e4112edb9f8ffa35731d4098bc6b":null,"_oembed_8357e2b8a2575c74ed5978f262a10126":null,"_oembed_3d5fea5103dd0d22ec5d6a33eff7f863":null,"_eael_widget_elements":null,"_oembed_0d8a206f09633e3d62b95a15a4dd0487":null,"_oembed_time_0d8a206f09633e3d62b95a15a4dd0487":null,"_aioseo_description":null,"_eb_attr":null,"_eb_data_table":null,"_oembed_819a879e7da16dd629cfd15a97334c8a":null,"_oembed_time_819a879e7da16dd629cfd15a97334c8a":null,"_acf_changed":null,"_wpcode_auto_insert":null,"_edit_last":null,"_edit_lock":null,"_oembed_e7b913c6c84084ed9702cb4feb012ddd":null,"_oembed_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_time_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_03514b67990db061d7c4672de26dc514":null,"_oembed_time_03514b67990db061d7c4672de26dc514":null,"rank_math_news_sitemap_robots":null,"rank_math_robots":null,"_eael_post_view_count":"74","_trp_automatically_translated_slug_ru_ru":null,"_trp_automatically_translated_slug_et":null,"_trp_automatically_translated_slug_lv":null,"_trp_automatically_translated_slug_fr_fr":null,"_trp_automatically_translated_slug_en_us":null,"_wp_old_slug":null,"_trp_automatically_translated_slug_da_dk":null,"_trp_automatically_translated_slug_pl_pl":null,"_trp_automatically_translated_slug_es_es":null,"_trp_automatically_translated_slug_hu_hu":null,"_trp_automatically_translated_slug_fi":null,"_trp_automatically_translated_slug_ja":null,"_trp_automatically_translated_slug_lt_lt":null,"_elementor_edit_mode":null,"_elementor_template_type":null,"_elementor_version":null,"_elementor_pro_version":null,"_wp_page_template":null,"_elementor_page_settings":null,"_elementor_data":null,"_elementor_css":null,"_elementor_conditions":null,"_happyaddons_elements_cache":null,"_oembed_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_time_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_time_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_59808117857ddf57e478a31d79f76e4d":null,"_oembed_time_59808117857ddf57e478a31d79f76e4d":null,"_oembed_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_time_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_81002f7ee3604f645db4ebcfd1912acf":null,"_oembed_time_81002f7ee3604f645db4ebcfd1912acf":null,"_elementor_screenshot":null,"_oembed_7ea3429961cf98fa85da9747683af827":null,"_oembed_time_7ea3429961cf98fa85da9747683af827":null,"_elementor_controls_usage":null,"_elementor_page_assets":[],"_elementor_screenshot_failed":null,"theplus_transient_widgets":null,"_eael_custom_js":null,"_wp_old_date":null,"_trp_automatically_translated_slug_it_it":null,"_trp_automatically_translated_slug_pt_pt":null,"_trp_automatically_translated_slug_zh_cn":null,"_trp_automatically_translated_slug_nl_nl":null,"_trp_automatically_translated_slug_pt_br":null,"_trp_automatically_translated_slug_sv_se":null,"rank_math_analytic_object_id":null,"rank_math_internal_links_processed":"1","_trp_automatically_translated_slug_ro_ro":null,"_trp_automatically_translated_slug_sk_sk":null,"_trp_automatically_translated_slug_bg_bg":null,"_trp_automatically_translated_slug_sl_si":null,"litespeed_vpi_list":null,"litespeed_vpi_list_mobile":null,"rank_math_seo_score":null,"rank_math_contentai_score":null,"ilj_limitincominglinks":null,"ilj_maxincominglinks":null,"ilj_limitoutgoinglinks":null,"ilj_maxoutgoinglinks":null,"ilj_limitlinksperparagraph":null,"ilj_linksperparagraph":null,"ilj_blacklistdefinition":null,"ilj_linkdefinition":null,"_eb_reusable_block_ids":null,"rank_math_focus_keyword":"Linux NUMA","rank_math_og_content_image":null,"_yoast_wpseo_metadesc":null,"_yoast_wpseo_content_score":null,"_yoast_wpseo_focuskeywords":null,"_yoast_wpseo_keywordsynonyms":null,"_yoast_wpseo_estimated-reading-time-minutes":null,"rank_math_description":null,"surfer_last_post_update":null,"surfer_last_post_update_direction":null,"surfer_keywords":null,"surfer_location":null,"surfer_draft_id":null,"surfer_permalink_hash":null,"surfer_scrape_ready":null,"_thumbnail_id":"21436","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/posts\/21443","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/comments?post=21443"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/posts\/21443\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/media\/21436"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/media?parent=21443"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/categories?post=21443"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/tags?post=21443"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}