{"id":18945,"date":"2026-04-11T18:21:07","date_gmt":"2026-04-11T16:21:07","guid":{"rendered":"https:\/\/webhosting.de\/numa-balancing-server-memory-optimierung-hardware-numaflux\/"},"modified":"2026-04-11T18:21:07","modified_gmt":"2026-04-11T16:21:07","slug":"numa-balancing-server-geheugen-optimalisatie-hardware-numaflux","status":"publish","type":"post","link":"https:\/\/webhosting.de\/nl\/numa-balancing-server-memory-optimierung-hardware-numaflux\/","title":{"rendered":"NUMA-balanceringsserver: Optimalisatie van geheugentoegang voor hostinghardware"},"content":{"rendered":"<p>Ik laat zien hoe <strong>NUMA-balanceringsserver<\/strong> op hostinghardware stroomlijnt geheugentoegang en vermindert latenties door processen en gegevens aan het juiste NUMA-knooppunt te binden. De beslissende factor is de <strong>Geheugentoegang optimaliseren<\/strong> door lokale toegang, taakplaatsing en gerichte paginamigratie naar Linux-hosts met veel cores.<\/p>\n\n<h2>Centrale punten<\/h2>\n\n<ul>\n  <li><strong>NUMA<\/strong> verdeelt CPU's en geheugen in knooppunten; lokale toegang biedt <strong>laag<\/strong> Vertraging.<\/li>\n  <li><strong>Automatisch<\/strong> NUMA Balancing migreert pagina's en plaatst taken <strong>dicht bij het knooppunt<\/strong>.<\/li>\n  <li><strong>VM-grootte<\/strong> per knooppunt, anders is er een risico <strong>NUMA vernietigen<\/strong>.<\/li>\n  <li><strong>Gereedschap<\/strong> als numactl, lscpu, numad tonen <strong>Topologie<\/strong> en gebruik.<\/li>\n  <li><strong>Afstemmen<\/strong>C-states, Node Interleaving van, <strong>Enorme pagina's<\/strong>, affiniteiten.<\/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\/04\/serverraum-speicheroptimum-5582.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Wat NUMA is - en waarom het telt voor hosting<\/h2>\n\n<p>NUMA verdeelt een multiprocessorsysteem in <strong>Knooppunt<\/strong>, die elk hun eigen CPU's en lokale geheugen bevatten, waardoor toegang in de buurt sneller is dan toegang op afstand. Terwijl UMA alle cores naar een gemeenschappelijk pad stuurt, voorkomt NUMA knelpunten door <strong>lokale<\/strong> geheugenkanalen per node. In hostingomgevingen met veel parallelle VM's telt elke milliseconde latency op, dus elke aanvraag heeft meetbaar voordeel. Als u meer achtergrondinformatie wilt, kunt u meer te weten komen over <a href=\"https:\/\/webhosting.de\/nl\/blog-numa-architectuur-serverprestaties-hosting-hardware-optimalisatie-infrastructuur\/\">NUMA-architectuur<\/a>. Voor mij staat \u00e9\u00e9n ding vast: als je nodes begrijpt en gebruikt, haal je meer bandbreedte uit dezelfde hardware.<\/p>\n\n<h2>Automatisch NUMA balanceren in de Linux kernel - hoe het werkt<\/h2>\n\n<p>De kernel scant periodiek delen van de adresruimte en \u201eunmaps\u201c pagina's zodat een hintfout kan worden gemaakt. <strong>optimaal<\/strong> knooppunt zichtbaar. Als de fout optreedt, evalueert het algoritme of het de moeite waard is om de pagina te migreren of de taak te verplaatsen en vermijdt onnodige verplaatsingen. Migreren op fout brengt <strong>Gegevens<\/strong> dichter bij de uitvoerende CPU, terwijl de NUMA-plaatsing van taken processen dichter bij hun geheugen plaatst. De scanner verdeelt zijn werk stuk voor stuk zodat de overhead binnen de ruis van de normale belasting blijft. Dit resulteert in voortdurende fijnafstemming die de latentie verlaagt zonder dat er harde regels voor pinning nodig zijn.<\/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\/04\/memoryoptimization1234.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Geheugentoegang optimaliseren: lokaal verslaat extern<\/h2>\n\n<p>Lokale toegang gebruikt de <strong>Geheugencontroller<\/strong> van je eigen node en minimaliseert de wachttijden voor de interconnect. Toegang op afstand kost cycli via QPI\/UPI of Infinity Fabric en minimaliseert zo de effectieve toegangstijd. <strong>Bandbreedte<\/strong>. Hoge core aantallen verergeren dit effect omdat meer en meer cores concurreren om dezelfde verbindingen. Ik plan daarom zo dat actieve code en actieve data samenkomen op \u00e9\u00e9n node. Als je dit negeert, geef je procentpunten weg die de responstijd of time-out bepalen tijdens belastingspieken.<\/p>\n\n<h2>VM-groottes, NUMA trashing en host cropping<\/h2>\n\n<p>Ik dimensioneer VM's zo dat vCPU's en RAM in een NUMA-node passen om cross-node toegang te voorkomen. Vaak leveren 4-8 vCPU's per node goede prestaties. <strong>Slagingspercentages<\/strong>, afhankelijk van het platform en de cachehi\u00ebrarchie. Grote pagina's helpen ook omdat de TLB effici\u00ebnter werkt en paginamigraties minder vaak voorkomen. Indien nodig stel ik <strong>CPU-affiniteit<\/strong> voor latentiekritische processen om threads te binden aan geschikte cores - zie voor meer informatie <a href=\"https:\/\/webhosting.de\/nl\/server-cpu-affiniteit-hosting-optimalisatie-kernelaffiniteit\/\">CPU-affiniteit<\/a>. Als je VM's over nodes verdeelt, riskeer je NUMA trashing, d.w.z. een ping-pong van gegevens en threads.<\/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\/04\/numa-balancing-server-memory-2948.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Hulpmiddelen in de praktijk: numactl, lscpu, numad<\/h2>\n\n<p>Met \u201elscpu\u201c lees ik <strong>Topologie<\/strong> en NUMA-knooppunten, inclusief de toewijzing van de kernen. \u201enumactl -hardware\u201c toont me geheugen per node en beschikbare afstanden, wat het makkelijker maakt om de paden te evalueren. De daemon \u201enumad\u201c bewaakt het gebruik en past de affiniteiten dynamisch aan wanneer de belastingscentra bewegen. Voor vaste scenario's gebruik ik \u201enumactl -cpunodebind\/-membind\u201c om processen en geheugen expliciet vast te pinnen. Op deze manier combineer ik automatisch balanceren met gerichte specificaties en controleer ik het resultaat via \u201eperf\u201c, \u201enumastat\u201c en \u201e\/proc\u201c.<\/p>\n\n<h2>Hoe ik de impact meet: Kerncijfers en opdrachten<\/h2>\n\n<p>Ik beoordeel NUMA-Tuning altijd via <strong>Meetreeks<\/strong>, niet op gevoel. Drie indicatoren hebben hun waarde bewezen: Verhouding tussen lokale en externe paginaweergaven, migratiegraad en latentieverdeling (P95\/P99).<\/p>\n<ul>\n  <li><strong>Systeemwijd<\/strong>numastat\u201e toont lokale\/externe toegang en gemigreerde pagina's per knooppunt.<\/li>\n  <li><strong>Procesgerelateerd<\/strong>: \u201e\/proc\/\/numa_maps\u201c laat zien waar geheugen zich bevindt en hoe het is verdeeld.<\/li>\n  <li><strong>Planningweergave<\/strong>Cpus_allowed_list\u201e en real \u201cCpus_allowed\u201e controleren of bindingen van toepassing zijn.<\/li>\n<\/ul>\n<pre><code># Systeembrede weergave\nnumastat\nnumastat -m\n\n# Procesgerelateerde distributie en bindingen\npid=$(pidof )\nnumastat -p \"$pid\"\ncat \/proc\/\"$pid\"\/numa_maps | head\ncat \/proc\/\"$pid\"\/status | grep -E 'Cpus_allowed_list|Mems_allowed_list'.\ntaskset -cp \"$pid\"\n\n# Kernelteller voor NUMA-activiteit\ngrep -E 'numa|migrate' \/proc\/vmstat\n\n# Trace events voor diepe analyses (voor korte tijd activeren)\necho 1 &gt; \/sys\/kernel\/debug\/tracing\/events\/mm\/enable\nslaap 5; cat \/sys\/kernel\/debug\/tracing\/trace | grep -i numa; echo 0 &gt; \/sys\/kernel\/debug\/tracing\/events\/mm\/enable\n<\/code><\/pre>\n<p>Ik vergelijk in elk geval <strong>A\/B<\/strong>Ongebonden vs. gebonden, automatisch balanceren aan\/uit en verschillende VM slices. Het doel is een duidelijke vermindering in toegang op afstand en migratieruis, evenals strakkere P95\/P99 latencies. Pas als de gemeten waarden stabiel beter zijn, zal ik de tuning overnemen.<\/p>\n\n<h2>BIOS- en firmware-instellingen die echt werken<\/h2>\n\n<p>Ik schakel \u201eNode Interleaving\u201c uit in het BIOS zodat de NUMA-structuur zichtbaar blijft en de kernel <strong>lokale<\/strong> kan plannen. Verminderde C-states stabiliseren latency pieken omdat cores minder snel in diepe slaaptoestanden vallen, wat wake-up tijd bespaart. Ik wijs geheugenkanalen symmetrisch toe zodat elke node zijn maximale geheugencapaciteit kan benutten. <strong>Bandbreedte<\/strong> bereikt. Ik test prefetchers en RAS functies met werklastprofielen, omdat ze helpen of schaden afhankelijk van het toegangspatroon. Ik meet elke verandering ten opzichte van een basislijn en pas daarna neem ik de instelling permanent over.<\/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\/04\/NUMA_Balancing_Server_8345.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Kernel- en sysctl-parameters die het verschil maken<\/h2>\n\n<p>Het fijn afstellen van de kernel helpt me, <strong>Overhead<\/strong> en <strong>Reactietijd<\/strong> van de balancer aan te passen aan de werklast. Ik begin met conservatieve standaardinstellingen en werk stap voor stap naar voren.<\/p>\n<ul>\n  <li><strong>kernel.numa_balancing<\/strong>Aan\/uit van automatisch balanceren. Ik laat het aanstaan voor bewegende ladingen; ik schakel het uit voor speciale diensten met alleen pinnen als test.<\/li>\n  <li><strong>kernel.numa_balancing_scan_delay_ms<\/strong>Wachttijd voor de eerste scan na het aanmaken van het proces. Selecteer groter als er veel kortstondige taken draaien; kleiner voor langlopende diensten die een snelle nabijheid vereisen.<\/li>\n  <li><strong>kernel.numa_balancing_scan_period_min_ms \/ _max_ms<\/strong>Bandbreedte van de scanintervallen. Smalle intervallen verhogen de reactiesnelheid, maar ook de CPU-belasting.<\/li>\n  <li><strong>kernel.numa_balancing_scan_size_mb<\/strong>Verhouding van de adresruimte per scan. Te groot genereert hint-fout stormen, te klein reageert traag.<\/li>\n  <li><strong>vm.zone_terugwinnen_modus<\/strong>Als geheugen schaars is, geeft de kernel de voorkeur aan local reclaim in plaats van remote alloc. Voor algemene hosting werklasten laat ik meestal <em>0<\/em>; Voor strikt latency-gevoelige, lokale geheugenservices test ik voorzichtig hogere waarden.<\/li>\n  <li><strong>Transparante grote pagina's (THP)<\/strong>: Onder \u201e\/sys\/kernel\/mm\/transparent_hugepage\/{enabled,defrag}\u201c stel ik meestal in op <em>madvise<\/em> en conservatieve defragmentatie. Harde \u201ealtijd\u201c profielen brengen TLB-voordelen met zich mee, maar riskeren stalls door het compacten.<\/li>\n  <li><strong>sched_migratie_kosten_ns<\/strong>Kostenraming voor taakmigratie. Hogere waarden dempen de herverdeling van agressieve planners.<\/li>\n  <li><strong>cgroepen cpuset<\/strong>Met <em>cpuset.cpus<\/em> en <em>cpuset.mems<\/em> Ik scheid services netjes per knooppunt en zorg ervoor dat <strong>Eerste aanraking<\/strong> binnen de toegestane knooppunten blijft.<\/li>\n<\/ul>\n<pre><code># Voorbeeld: conservatief maar responsief balanceren\nsysctl -w kernel.numa_balancing=1\nsysctl -w kernel.numa_balancing_scan_delay_ms=30000\nsysctl -w kernel.numa_balancing_scan_period_min_ms=60000\nsysctl -w kernel.numa_balancing_scan_period_max_ms=300000\nsysctl -w kernel.numa_balancing_scan_size_mb=256\n\n# Gebruik THP voorzichtig\necho madvise &gt; \/sys\/kernel\/mm\/transparent_hugepage\/enabled\necho defer &gt; \/sys\/kernel\/mm\/transparent_hugepage\/defrag\n<\/code><\/pre>\n<p>Het blijft belangrijk: Verander slechts \u00e9\u00e9n stelschroef per testronde en test het effect tegen dezelfde belastingskromme. Zo ontwar ik oorzaak en gevolg.<\/p>\n\n<h2>Positioneer werklasten op de juiste manier: Databases, caches, containers<\/h2>\n\n<p>Databases profiteren wanneer bufferpools lokaal blijven per NUMA-knooppunt en threads dicht bij hun heaps worden gebonden. In in-memory caches stel ik sharding in op <strong>Knooppunt<\/strong> om fetches op afstand te vermijden. Containerplatforms ontvangen limieten en verzoeken zodat pods niet over nodes heen springen. Voor geheugenreserveringen gebruik ik Huge Pages, wat het makkelijker maakt om hotsets op te slaan in <strong>Caches<\/strong> passen. De volgende tabel vat de strategie\u00ebn en typische effecten in compacte vorm samen.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Strategie<\/th>\n      <th>Gebruik<\/th>\n      <th>Verwacht effect<\/th>\n      <th>Tip<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>Eerste aanraking<\/td>\n      <td>Databases, JVM-heaps<\/td>\n      <td>Toewijzing lokale zijde<\/td>\n      <td>Initialisatie uitvoeren op doelknooppunt<\/td>\n    <\/tr>\n    <tr>\n      <td>Interleave<\/td>\n      <td>Breed verdeelde belasting<\/td>\n      <td>Gelijkmatige verdeling<\/td>\n      <td>Niet optimaal voor hotspots<\/td>\n    <\/tr>\n    <tr>\n      <td>Taak vastzetten<\/td>\n      <td>Latency-kritieke services<\/td>\n      <td>Constante latentie<\/td>\n      <td>Minder flexibel bij veranderingen in belasting<\/td>\n    <\/tr>\n    <tr>\n      <td>Automatisch balanceren<\/td>\n      <td>Gemengde werklasten<\/td>\n      <td>Dynamische nabijheid<\/td>\n      <td>Overheadkosten afwegen tegen winst<\/td>\n    <\/tr>\n    <tr>\n      <td>Enorme pagina's<\/td>\n      <td>Grote hopen, caches<\/td>\n      <td>Minder TLB missers<\/td>\n      <td>Plan schone reserveringen<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Virtualisatie: virtuele NUMA, scheduler en gastaanpassing<\/h2>\n\n<p>Virtual NUMA geeft de host topologie in een vereenvoudigde vorm door aan het gast besturingssysteem zodat first-touch en <strong>Allocator<\/strong> verstandig werken. Hypervisor schedulers letten op de nabijheid van knooppunten bij het verdelen van vCPU's en het migreren van VM's. Ik lijn zelden grote VM's uit over meerdere nodes, tenzij de werklast breed stroomt en profiteert van interleave. In de gast pas ik de heaps van JVM's of databases aan zodat ze lokaal blijven op zichtbare NUMA nodes. Kijk voor geheugenbeheer in de gast eens naar <a href=\"https:\/\/webhosting.de\/nl\/virtueel-geheugen-serverbeheer-hosting-opslag\/\">Virtueel geheugen<\/a>, om de paginagrootte en het wisselen te beperken.<\/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\/04\/optimierung_hardware_1234.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>PCIe nabijheid: NVMe en NIC's op de juiste knooppunten<\/h2>\n\n<p>Indien mogelijk wijs ik NVMe SSD's en snelle NIC's toe aan het knooppunt waarop de <strong>Werkbelasting<\/strong> draait. Dit voorkomt dat I\/O verzoeken de interconnect oversteken en latency toevoegen. Ik bind multiqueue NIC's aan core sets van een node met RSS\/RPS zodat IRQ's lokaal blijven. Voor opslagstacks is het de moeite waard om de threadpools node voor node te splitsen. Als u hier aandacht aan besteedt, zult u P99-latenties merkbaar verminderen en ruimte cre\u00ebren voor belastingspieken.<\/p>\n\n<h2>IRQ en wachtrijaffiniteit in de praktijk<\/h2>\n\n<p>Ik controleer eerst welke <strong>NUMA-knooppunt<\/strong> apparaten en pin IRQ's en wachtrijen op de juiste manier. Dit zorgt ervoor dat de locatie van gegevenspaden behouden blijft.<\/p>\n<pre><code># Apparaat-naar-knooppunt mapping\ncat \/sys\/class\/net\/eth0\/device\/numa_node\ncat \/sys\/block\/nvme0n1\/device\/numa_node\n\n# Stel IRQ affiniteit specifiek in (voorbeeld: cores 0-7 van een node)\nirq=\necho 0-7 &gt; \/proc\/irq\/$irq\/smp_affinity_list\n\n# NIC-wachtrijen aan cores binden (RPS\/RFS)\nvoor q in \/sys\/class\/net\/eth0\/queues\/rx-*; do echo 0-7 &gt; \"$q\"\/rps_cpus; done\nsysctl -w net.core.rps_sock_flow_entries=32768\nvoor q in \/sys\/class\/net\/eth0\/queues\/rx-*; doe echo 4096 &gt; \"$q\"\/rps_flow_cnt; done\n\n# NVMe wachtrijaffiniteit verbeteren\necho 2 &gt; \/sys\/block\/nvme0n1\/queue\/rq_affinity\ncat \/sys\/block\/nvme0n1\/queue\/scheduler # \"none\" voorkeur\n<\/code><\/pre>\n<p>\u201eIk voer \u201cirqbalance\" uit met knooppuntbewustzijn of stel het in op <strong>Uitzonderingen<\/strong> voor hot-path interrupts. Het resultaat is stabielere latencies, minder cross-node IRQ hops en een meetbare toename in lokale I\/O hits.<\/p>\n\n<h2>Statisch binden vs. dynamisch balanceren - de middenweg<\/h2>\n\n<p>Ik gebruik \u201etaskset\u201c en cgroups om harde regels in te stellen wanneer deterministisch <strong>Latency<\/strong> telt. Ik laat automatische NUMA-balancering actief wanneer de belasting beweegt en ik adaptieve nabijheid nodig heb. Een mix werkt vaak het beste: harde pinnen voor hotpaths, meer open grenzen voor ondersteunend werk. Ik controleer regelmatig of migraties merkbaar toenemen, omdat dit duidt op slechte planning. Het doel blijft om data- en threadlocaties zo te kiezen dat migratie zeldzaam maar mogelijk blijft.<\/p>\n\n<h2>NUMA in containers en Kubernetes<\/h2>\n\n<p>Ik neem een container mee <strong>cpusets<\/strong> en <strong>Enorme pagina's<\/strong> op de lijn. Ik wijs pods\/containers toe aan een NUMA-knooppunt door consistente CPU- en geheugenhoeveelheden op te slaan. In orkestraties stel ik beleid in dat de voorkeur geeft aan toewijzingen aan enkele knooppunten en dus de eerste aanraking respecteert.<\/p>\n<ul>\n  <li><strong>Container runtime<\/strong>: \u201e-cpuset-cpus\u201c en \u201e-cpuset-mems\u201c houden taken en geheugen bij elkaar; wijs grote pagina's toe als bronnen.<\/li>\n  <li><strong>Topologie\/CPU-manager<\/strong>Strikte of voorkeurstoewijzingen zorgen ervoor dat gerelateerde kernen en geheugengebieden worden toegewezen.<\/li>\n  <li><strong>Gegarandeerde QoS<\/strong>Vaste aanvragen\/limieten minimaliseren herverdeling door de planner.<\/li>\n<\/ul>\n<p>Ik heb bewust sidecars en hulpprocessen naar andere kernen gesplitst <em>binnen<\/em> van hetzelfde knooppunt zodat het hotpath ongestoord blijft maar niet in de cross-node race terechtkomt.<\/p>\n\n<h2>CPU-topologie\u00ebn begrijpen: CCD\/CCX, SNC en Cluster-op-Die<\/h2>\n\n<p>Huidige server-CPU's splitsen sockets op in <strong>Subdomeinen<\/strong> met zijn eigen caches en paden. Ik houd hier rekening mee bij het snijden van kernen\/hopen:<\/p>\n<ul>\n  <li><strong>AMD EPYC<\/strong>CCD\/CCX en \u201eNUMA per socket\u201c (NPS=1\/2\/4) be\u00efnvloeden hoe fijn NUMA wordt gesneden. Meer nodes (NPS=4) verhogen de lokaliteit, maar vereisen schone pinning.<\/li>\n  <li><strong>Intel<\/strong>Sub-NUMA Clustering (SNC2\/4) verdeelt LLC in clusters. Goed voor geheugengebonden belastingen, op voorwaarde dat het OS en de werklast node-bewust zijn.<\/li>\n  <li><strong>L3 Nabijheid<\/strong>Ik bind threads die dezelfde heaps gebruiken aan hetzelfde L3-cluster om coherentieverkeer en cross-cluster hops te besparen.<\/li>\n<\/ul>\n<p>Deze opties werken als een vermenigvuldiger: als ze correct worden gebruikt, verhogen ze <strong>Locality<\/strong> Bovendien - verkeerd geconfigureerd, verhogen ze de fragmentatie en het verkeer op afstand.<\/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\/04\/hosting-serverraum-7584.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Stapsgewijze introductie en rollback plan<\/h2>\n\n<p>Ik introduceer nooit \u201ebig bang\u201c NUMA tuning. Een veerkrachtige <strong>Plan<\/strong> voorkomt verrassingen:<\/p>\n<ol>\n  <li><strong>Basislijn<\/strong>Hardwaretopologie, P50\/P95\/P99 latenties, doorvoer, numastat rate capture.<\/li>\n  <li><strong>Hypothese<\/strong>Formuleer een specifiek doel (bijv. toegang op afstand -30%, P99 -20%).<\/li>\n  <li><strong>Een stap<\/strong>Verander slechts \u00e9\u00e9n stelschroef (bijv. VM-cut, cpuset, THP-beleid, scanintervallen).<\/li>\n  <li><strong>Kanarie<\/strong>Test op 5-10% van de vloot onder echte belasting, houd rollback gereed.<\/li>\n  <li><strong>Waardering<\/strong>Meetwaarden vergelijken, regressievensters defini\u00ebren, neveneffecten loggen.<\/li>\n  <li><strong>Uitrol<\/strong>Rol as voor as uit en meet opnieuw na elke as.<\/li>\n  <li><strong>Onderhoud<\/strong>Meet elk kwartaal opnieuw (kernel-, firmware- en werklastupdates veranderen het optimum).<\/li>\n<\/ol>\n<p>Dit zorgt ervoor dat verbeteringen reproduceerbaar zijn en in geval van een fout binnen enkele minuten kunnen worden teruggedraaid.<\/p>\n\n<h2>Veelgemaakte fouten - en hoe ze te vermijden<\/h2>\n\n<p>Een typische misstap is het activeren van node interleaving in het BIOS, wat de NUMA topologie verbergt en <strong>Evenwicht<\/strong> moeilijker. Even ongunstig: VM's met meer vCPU's dan een node biedt, plus onzuiver gereserveerde enorme pagina's. Sommige beheerders pinnen alles vast en verliezen zo alle flexibiliteit wanneer werklasten verschuiven. Anderen vertrouwen volledig op de kernel, hoewel harde hotspots duidelijke regels vereisen. Ik neem meetreeksen op, herken uitschieters in een vroeg stadium en pas de instellingen en beleidsregels stap voor stap aan.<\/p>\n<ul>\n  <li><strong>THP \u201ealtijd\u201c<\/strong> zonder controle: Ongepland compacten verstoort de latentie. Ik gebruik liever \u201emadvise\u201c en reserveer grote pagina's specifiek.<\/li>\n  <li><strong>vm.zone_terugwinnen_modus<\/strong> te agressief: Local reclaim kan op het verkeerde moment meer kwaad dan goed doen. Eerst meten, dan slijpen.<\/li>\n  <li><strong>irqbalans blind<\/strong>Niet-kritieke IRQ's bewegen over nodes. Ik stel uitzonderingen of vaste maskers in voor hotpaths.<\/li>\n  <li><strong>Mengsel van interleave + hard pinning<\/strong>Tegenstrijdig beleid zorgt voor pingpong. Ik kies voor een duidelijke lijn voor elke dienst.<\/li>\n  <li><strong>Onzuivere cpusets<\/strong>Containers zien een knooppunt, maar wijzen geheugen toe aan andere knooppunten. Stel \u201ecpuset.mems\u201c altijd consistent in met de CPU-set.<\/li>\n  <li><strong>Sub-NUMA functies<\/strong> geactiveerd maar niet gebruikt: Meer nodes zonder planning verhogen de fragmentatie. Alleen inschakelen na testen.<\/li>\n<\/ul>\n\n<h2>Kort samengevat<\/h2>\n\n<p>NUMA Balancing Server brengt processen en gegevens op een gerichte manier samen, waardoor lokale toegang frequenter en effici\u00ebnter wordt. <strong>Latencies<\/strong> korter worden. Met een geschikte VM-grootte, een schone BIOS-configuratie en tools zoals numactl wordt een duidelijke topologie gecre\u00eberd die de kernel gebruikt. Virtuele NUMA, grote pagina's en affiniteiten vullen automatische balancering aan in plaats van het te vervangen. Door I\/O-apparaten dicht bij nodes aan te sluiten en hotpaths te gebruiken, wordt dure toegang op afstand ge\u00eblimineerd. Op deze manier schaalt hostinghardware betrouwbaar en levert elke CPU-seconde meer op. <strong>laadvermogen<\/strong>.<\/p>","protected":false},"excerpt":{"rendered":"<p>**NUMA balancing server** revolutioneert geheugentoegangsoptimalisatie op **hostinghardware**. Verminder latentie en maximaliseer serverprestaties.<\/p>","protected":false},"author":1,"featured_media":18938,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_crdt_document":"","inline_featured_image":false,"footnotes":""},"categories":[676],"tags":[],"class_list":["post-18945","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":"544","_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":"NUMA Balancing Server","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":"18938","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/posts\/18945","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=18945"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/posts\/18945\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/media\/18938"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/media?parent=18945"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/categories?post=18945"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/tags?post=18945"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}