{"id":15663,"date":"2025-11-29T18:21:50","date_gmt":"2025-11-29T17:21:50","guid":{"rendered":"https:\/\/webhosting.de\/blog-numa-architektur-server-performance-hosting-hardware-optimierung-infrastruktur\/"},"modified":"2025-11-29T18:21:50","modified_gmt":"2025-11-29T17:21:50","slug":"blog-numa-arkitektur-server-ydeevne-hosting-hardware-optimering-infrastruktur","status":"publish","type":"post","link":"https:\/\/webhosting.de\/da\/blog-numa-architektur-server-performance-hosting-hardware-optimierung-infrastruktur\/","title":{"rendered":"NUMA-arkitektur: Hvorfor den spiller en vigtig rolle i moderne servere"},"content":{"rendered":"<p>Die <strong>NUMA-arkitektur<\/strong> bestemmer, hvor hurtigt moderne servere forsyner tr\u00e5de med hukommelse, og hvor godt arbejdsbelastninger skaleres ved h\u00f8j belastning. Jeg viser, hvorfor lokal hukommelsesadgang dominerer latenstid og b\u00e5ndbredde, hvordan hypervisorer bruger NUMA, og hvilke indstillinger i VM'er der frigiver direkte ydelsesgevinster.<\/p>\n\n<h2>Centrale punkter<\/h2>\n\n<p>Jeg vil kort sammenfatte de vigtigste konklusioner og fremh\u00e6ve de faktorer, der har st\u00f8rst effekt i datacentre.<\/p>\n<ul>\n  <li><strong>Lokal hukommelse<\/strong> minimerer latenstid og \u00f8ger gennemstr\u00f8mningen<\/li>\n  <li><strong>NUMA-knudepunkt<\/strong> strukturerer CPU'er og RAM effektivt<\/li>\n  <li><strong>vCPU-st\u00f8rrelse<\/strong> Tilpas til knudest\u00f8rrelse pr. VM<\/li>\n  <li><strong>Virtuel NUMA<\/strong> videregives til g\u00e6st-OS<\/li>\n  <li><strong>Sp\u00e6ndingsregler<\/strong> til store RAM-behov<\/li>\n<\/ul>\n<p>Jeg fokuserer konsekvent p\u00e5 <strong>Forsinkelse<\/strong> og datan\u00e6rhed, fordi det er netop der, serverydelsen afg\u00f8res. Store sockets, mange kerner og meget RAM nytter ikke meget, hvis tr\u00e5de konstant venter p\u00e5 fjerne hukommelsesomr\u00e5der. Jeg dimensionerer VM'er, s\u00e5 de passer ind i en NUMA-node, og hukommelsesallokeringen forbliver lokal. Jeg underst\u00f8tter hypervisor-funktioner m\u00e5lrettet i stedet for at aktivere alt globalt. S\u00e5dan sikrer jeg <strong>Skalering<\/strong> uden overraskelser ved spidsbelastninger.<\/p>\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\/2025\/11\/numa-serverarchitektur-4831.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Hvad NUMA virkelig er<\/h2>\n\n<p>Jeg t\u00e6nker i <strong>Knudepunkt<\/strong>: Hver NUMA-node kombinerer CPU-kerner og et lokalt RAM-omr\u00e5de med meget korte adgangsveje. Hvis en tr\u00e5d finder dataene i L1-, L2- eller L3-cachen, k\u00f8rer alt ekstremt hurtigt; hvis datas\u00e6ttet ligger i det lokale RAM, forbliver ventetiden lav. Men hvis tr\u00e5den tilg\u00e5r en anden node, stiger ventetiden, og genneml\u00f8bshastigheden falder. Det er netop disse forskelle, der g\u00f8r <strong>Ikke-uniform<\/strong> Memory Access. Derfor tilpasser jeg arbejdsbelastningen, s\u00e5 st\u00f8rstedelen af adgangen forbliver lokal.<\/p>\n\n<h2>Hvorfor UMA st\u00f8der p\u00e5 gr\u00e6nser<\/h2>\n\n<p>UMA deler alle processorer en f\u00e6lles <strong>lagersti<\/strong> hvilket skaber overbelastning, n\u00e5r antallet af kerner stiger. Hver ekstra kerne skubber sig ind i de samme k\u00f8er og konkurrerer om b\u00e5ndbredde. I mange \u00e6ldre ops\u00e6tninger akkumulerede dette sig til en forsinkelse, indtil CPU-udnyttelsen var h\u00f8j, men applikationen reagerede langsomt. Det f\u00f8les som om \u201eCPU'en er ved sin gr\u00e6nse\u201c, selvom flaskehalsen faktisk ligger i hukommelsesadgangen. NUMA l\u00f8ser netop dette problem. <strong>Blokeringer<\/strong> gennem lokale stier og knudepunktstopologi.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2025\/11\/numa_servermeeting_4027.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>NUMA vs. UMA: Oversigt over forskelle<\/h2>\n\n<p>Jeg vil gerne sammenfatte de vigtigste forskelle i en kompakt oversigt. <strong>Bord<\/strong> fast, s\u00e5 beslutninger kan tr\u00e6ffes hurtigere. Denne oversigt viser, hvad der er vigtigt inden for arkitektur, latenstid og skalering. Den hj\u00e6lper mig med at dimensionere nye v\u00e6rter og med fejlfinding i produktive milj\u00f8er. Hvis man har et klart overblik over forskellen mellem lokal og fjernadgang, kan man tr\u00e6ffe bedre beslutninger om VM-tilpasning og RAM-allokering. Det er netop her, det afg\u00f8res. <strong>Ydelse<\/strong> under belastning.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Kriterium<\/th>\n      <th>NUMA<\/th>\n      <th>UMA<\/th>\n      <th>Praktisk effekt<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>hukommelsesadgang<\/td>\n      <td>Lokalt eller fjernt<\/td>\n      <td>Standardiseret<\/td>\n      <td>Lokale adgang er hurtigere; fjernadgang medf\u00f8rer forsinkelser<\/td>\n    <\/tr>\n    <tr>\n      <td>Skalering<\/td>\n      <td>Meget god med knuder<\/td>\n      <td>Tidligt begr\u00e6nset<\/td>\n      <td>Flere kerner skalerer mere p\u00e5lideligt med NUMA<\/td>\n    <\/tr>\n    <tr>\n      <td>Topologi<\/td>\n      <td>Flere knuder<\/td>\n      <td>Ensartet pulje<\/td>\n      <td>Topologibevidst planl\u00e6gning er n\u00f8dvendig<\/td>\n    <\/tr>\n    <tr>\n      <td>hypervisor<\/td>\n      <td>Virtual NUMA tilg\u00e6ngelig<\/td>\n      <td>Mindre relevant<\/td>\n      <td>G\u00e6st-OS kan planl\u00e6gge NUMA-bevidst<\/td>\n    <\/tr>\n    <tr>\n      <td>finjustering<\/td>\n      <td>vCPU\/RAM pr. node<\/td>\n      <td>Global tuning<\/td>\n      <td>Knudepunktsvenlige VM'er giver stabilitet<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>NUMA i virtuelle milj\u00f8er<\/h2>\n\n<p>Jeg lader hypervisoren <strong>Topologi<\/strong> videregive til g\u00e6st-OS, s\u00e5 scheduler og hukommelsesstyring planl\u00e6gger lokalt. Virtual NUMA viser g\u00e6sten sine knudegr\u00e6nser, hvilket g\u00f8r det muligt for databaser, JVM'er og .NET-arbejdere at placere deres heaps og tr\u00e5de mere gunstigt. P\u00e5 den m\u00e5de undg\u00e5r jeg dyre fjernadgange og holder latenstiden stabil. I f\u00f8lsomme ops\u00e6tninger kombinerer jeg dette med en konsekvent pinning-strategi og fast RAM-allokering. For ekstremt korte responstider tr\u00e6kker jeg desuden <a href=\"https:\/\/webhosting.de\/da\/mikrolatens-hosting-optimering-database-netvaerksblitz\/\">Mikrolatency-hosting<\/a> for at reducere jitter yderligere.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2025\/11\/numa-architektur-servertechnik-9381.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Bedste praksis for VM-st\u00f8rrelser og CPU-allokering<\/h2>\n\n<p>Jeg dimensionerer <strong>vCPU'er<\/strong> s\u00e5ledes, at en VM passer ind i en NUMA-node eller kun lige netop ber\u00f8rer denne. Eksempel: Hvis en host har to noder med 20 kerner hver, planl\u00e6gger jeg VM'er med 4 til 16 vCPU'er helst inden for en node. Hvis man overskrider dette, risikerer man fjernadgang og un\u00f8dvendige ventetider. Jeg fordeler RAM s\u00e5 statisk som muligt, s\u00e5 g\u00e6st-OS'et holder sine sider lokalt. For arbejdsbelastninger med en stor andel af single-threads inddrager jeg den rigtige kerne-strategi og bruger analyser som <a href=\"https:\/\/webhosting.de\/da\/single-thread-vs-multi-core-webhosting-cpu-sammenligning-2025-effektivitet\/\">Single-thread vs. multi-core<\/a>.<\/p>\n\n<h2>Konkrete fordele ved hosting-hardware<\/h2>\n\n<p>Med ren NUMA-planl\u00e6gning \u00f8ger jeg <strong>t\u00e6thed<\/strong> pr. host uden at g\u00e5 p\u00e5 kompromis med reaktionstiderne. I mange datacentre kan man dermed k\u00f8re markant flere VM'er pr. sokkel, samtidig med at applikationerne reagerer p\u00e5lideligt. Kortere latenstid har en direkte positiv indvirkning p\u00e5 brugeroplevelsen og batch-throughput. Omkostningerne pr. arbejdsbelastning falder, fordi CPU-tid og RAM udnyttes mere effektivt. Hvis man tr\u00e6ffer et velovervejet valg af hardware, kan man desuden drage fordel af moderne <a href=\"https:\/\/webhosting.de\/da\/high-performance-webhosting-hardware-cpu-nvme-memory-performance-turbo-server\/\">H\u00f8jtydende webhosting-hardware<\/a> med h\u00f8j hukommelsesb\u00e5ndbredde.<\/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\/2025\/11\/numa_techoffice_nacht9462.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Workload-tuning: Databaser, caches, containere<\/h2>\n\n<p>Jeg s\u00f8rger for, at <strong>Databaser<\/strong> holde deres heaps lokalt og beregne worker-threads p\u00e5 \u201ederes\u201c node. For SQL-motorer, in-memory-caches og JVM'er er det en fordel at tildele CPU'er og reservere hukommelse fast. Containerorkestrering drager fordel af nodeaffiniteter, s\u00e5 pods bruger de korteste hukommelsesveje. Ved kraftig I\/O satser jeg p\u00e5 NUMA-n\u00e6re NVMe-tildelinger for at holde data t\u00e6t p\u00e5 noderne. P\u00e5 den m\u00e5de forbliver hotpaths korte, og <strong>Svartid<\/strong> venlig.<\/p>\n\n<h2>Overv\u00e5gning og fejlfinding ved NUMA<\/h2>\n\n<p>Jeg m\u00e5ler <strong>Forsinkelse<\/strong> og fjernadgang m\u00e5lrettet, i stedet for kun at se p\u00e5 CPU-procenter. V\u00e6rkt\u00f8jer viser mig pr. node, hvor mange sider der er fjerntliggende, og hvilke tr\u00e5de der skaber hukommelsespres. Hvis fjernfejl stiger, justerer jeg vCPU-st\u00f8rrelse, affiniteter eller RAM-allokering. Hvis gennemstr\u00f8mningen forbliver svag p\u00e5 trods af h\u00f8je CPU-reserver, skyldes det ofte hukommelsesstier. Synlighed p\u00e5 knudepunktsniveau er for mig den hurtigste vej til <strong>\u00c5rsager<\/strong>, ikke kun symptomer.<\/p>\n\n<h2>NUMA-spanning: korrekt anvendelse<\/h2>\n\n<p>Jeg aktiverer <strong>Sp\u00e6nding<\/strong> specielt til VM'er med meget store RAM-behov eller ekstraordin\u00e6r b\u00e5ndbredde. VM'en kan derefter hente hukommelse fra flere noder, hvilket g\u00f8r det muligt at k\u00f8re enkeltinstanser med massiv footprint. Prisen er lejlighedsvis fjernadgang, som jeg afb\u00f8der med CPU-affinitet og st\u00f8rre page locality-andel. Ved blandede belastninger foretr\u00e6kker jeg flere mellemstore VM'er frem for en meget stor instans. S\u00e5 forbliver <strong>Planl\u00e6gbarhed<\/strong> i hverdagen.<\/p>\n\n<h2>Licenser, t\u00e6thed og reelle omkostninger<\/h2>\n\n<p>Jeg vurderer <strong>Omkostninger<\/strong> ikke p\u00e5 v\u00e6rtsniveau, men pr. arbejdsbelastning og m\u00e5ned i euro. N\u00e5r NUMA \u00f8ger VM-t\u00e6theden, falder de faste omkostninger pr. instans, og ydelsesreserverne stiger. Dette p\u00e5virker b\u00e5de licenser pr. kerne samt support- og energiomkostninger. Ved at reducere fjernadgangen forkortes beregningstiden og der spares energi ved samme opgave. I sidste ende er det <strong>Samlet balance<\/strong> fra euro pr. resultat, ikke kun euro pr. server.<\/p>\n\n<h2>L\u00e6s hardware-topologi og interconnects korrekt<\/h2>\n\n<p>Jeg henviser til den fysiske <strong>Topologi<\/strong> aktivt ind i min planl\u00e6gning. Moderne servere bruger flerdelte CPU-designs og forbinder chiplets eller dies via interconnects. Det betyder, at ikke alle kerner har samme vej til hvert RAM-modul, og selv inden for en socket er der foretrukne stier. Jo mere trafik der k\u00f8rer over de socket-overskridende links, jo st\u00e6rkere stiger <strong>Forsinkelse<\/strong> og Coherency-Overhead. Jeg kontrollerer derfor, hvor mange hukommelseskanaler der er aktive pr. node, om alle DIMM-slots er symmetrisk udstyret, og hvordan noderne er forbundet p\u00e5 hovedkortet. Sub-NUMA-funktioner, der opdeler noder i mindre dom\u00e6ner, kan udligne hotspots, hvis arbejdsbelastningen er klart segmenteret. Jeg observerer desuden <strong>L3-topologi<\/strong>: Hvis tr\u00e5de og deres data befinder sig i forskellige cache-dom\u00e6ner, koster cache-overf\u00f8rslen alene m\u00e6rkbart p\u00e5 ydeevnen. En simpel b\u00e5ndbreddetest og en topologioversigt viser hurtigt, om platformen leverer den forventede lokalitet, eller om interconnects bliver en flaskehals.<\/p>\n\n<h2>Firmware- og BIOS-indstillinger med virkning<\/h2>\n\n<p>Jeg sikrer mig i BIOS, at <strong>Node-interleaving<\/strong> er deaktiveret, s\u00e5 NUMA-strukturen forbliver synlig. Jeg bruger sub-NUMA-clustering eller lignende tilstande m\u00e5lrettet, n\u00e5r arbejdsbelastninger har mange mellemstore, klart adskilte arbejdsm\u00e6ngder. For at opn\u00e5 konsistente ventetider v\u00e6lger jeg pr\u00e6stationsorienterede energiprofiler og reducerer dybere <strong>C-tilstande<\/strong> og undg\u00e5 aggressiv core-parkering. Jeg optimerer hukommelseskonfigurationen for fuld <strong>Hukommelseskanalens b\u00e5ndbredde<\/strong>; asymmetriske DIMM-konfigurationer har direkte indflydelse p\u00e5 gennemstr\u00f8mning og ventetid. Jeg tester ogs\u00e5 prefetcher- og RAS-indstillinger: Nogle beskyttelsesmekanismer \u00f8ger latenstiden uden at gavne arbejdsbyrden. Vigtigt: Jeg tester alle BIOS-tilpasninger med reel belastning, da mikroeffekter fra caches og interconnects ofte f\u00f8rst viser sig under pres.<\/p>\n\n<h2>G\u00e6st-OS og runtime-tuning: fra f\u00f8rste ber\u00f8ring til enorme sider<\/h2>\n\n<p>I g\u00e6sten bruger jeg <strong>F\u00f8rste ber\u00f8ring<\/strong>-Allokering til min fordel: Tr\u00e5de initialiserer \u201ederes\u201c hukommelse, s\u00e5 sider oprettes lokalt. Under Linux aktiverer eller deaktiverer jeg automatisk NUMA-balancing afh\u00e6ngigt af arbejdsbyrden. Databasen\u00e6re systemer drager ofte fordel af stabil binding, mens distribuerede web-arbejdere kan klare mindre migrationer. Med numactl eller task-pinning binder jeg tjenester til noder og definerer <strong>membind<\/strong>-retningslinjer. <strong>Store sider<\/strong> Reducer TLB-tryk; ved latenstidskritiske databaser foretr\u00e6kker jeg statiske Huge Pages og varm hukommelse (Pre-Touch) for at undg\u00e5 Page-Fault-spidsbelastninger. Transparent Huge Pages k\u00f8rer jeg afh\u00e6ngigt af motoren p\u00e5 \u201emadvise\u201c eller deaktiveret, hvis de genererer defragmenteringslatenser. Jeg styrer <strong>IRQ-affiniteter<\/strong> og fordeler netv\u00e6rks- og NVMe-interrupts til de relevante noder; RPS\/XPS og multiple queues hj\u00e6lper med at holde datastier konsistente. Under Windows bruger jeg Processor Groups og Soft-NUMA i stakken, s\u00f8rger for \u201eLock Pages in Memory\u201c ved hukommelseskr\u00e6vende tjenester og aktiverer Server-GC ved .NET. Til JVM'er bruger jeg NUMA-bevidste heuristikker, pre-touche Heaps og styrer tr\u00e5daffiniteten, s\u00e5 GC og Worker bruger de samme noder.<\/p>\n\n<h2>Juster hypervisor-specifikke indstillinger korrekt<\/h2>\n\n<p>Jeg passer <strong>vNUMA-topologi<\/strong> til den fysiske struktur. Jeg v\u00e6lger parametrene \u201eSockets\u201c, \u201eCores per Socket\u201c og \u201eThreads per Core\u201c s\u00e5ledes, at hypervisoren ikke opdeler VM'en over noder. Til latenstf\u00f8lsomme instanser reserverer jeg RAM, s\u00e5 hverken balloning eller swapping sl\u00e5r til, og jeg sikrer pCPU-ressourcer via affinitet eller passende scheduler-indstillinger. V\u00e6r forsigtig med CPU- eller Memory-Hot-Add: Mange platforme deaktiverer vNUMA i g\u00e6sten \u2013 resultatet er skjulte fjernadgange. Jeg planl\u00e6gger live-migration, s\u00e5 m\u00e5lv\u00e6rter har en kompatibel NUMA-topologi, og jeg giver VM'er tid efter migration til at <strong>Sideplacering<\/strong> genopbygge (Pre-Touch, Warmlauf). I KVM-milj\u00f8er bruger jeg NUMA-tuning-indstillingerne og cpuset-Cgroups; i andre hypervisorer hj\u00e6lper exstop\/lignende v\u00e6rkt\u00f8jer med at se vCPU-fordeling og node-hits i realtid.<\/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\/2025\/11\/numa_server_workspace_8721.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Spild ikke PCIe- og I\/O-lokalitet<\/h2>\n\n<p>Jeg organiserer <strong>NVMe<\/strong>-drev, HBA'er og NIC'er til den node, hvor de beregnende tr\u00e5de k\u00f8rer. SR-IOV- eller vNIC-k\u00f8er binder jeg til kerner p\u00e5 samme node og styrer interrupts i overensstemmelse hermed. For h\u00f8je pakkehastigheder skalerer jeg modtage-\/transmissionsk\u00f8er og fordeler dem konsekvent over de lokale kerner. Ved storage-stacks s\u00f8rger jeg for, at arbejdstr\u00e5de til I\/O-indsendelser og -afslutninger k\u00f8rer p\u00e5 samme node, s\u00e5 datastien ikke l\u00f8ber p\u00e5 tv\u00e6rs af interconnecten. Jeg planl\u00e6gger ogs\u00e5 multipathing og software-RAID knudepunktsspecifikt; en \u201ekortere\u201c sti sl\u00e5r n\u00e6sten altid den \u201ebredere\u201c sti med eksterne adgange. P\u00e5 den m\u00e5de reducerer jeg jitter og bringer under I\/O-belastning <strong>CPU-tid<\/strong> der, hvor den har effekt.<\/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\/2025\/11\/numa-serverrack-7412.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Kapacitetsplanl\u00e6gning, overforpligtelse og hukommelsesfunktioner<\/h2>\n\n<p>Jeg foretr\u00e6kker at k\u00f8re latenstidsorienterede arbejdsbelastninger uden <strong>Overforpligtelse<\/strong> p\u00e5 RAM og moderat p\u00e5 vCPU. Ballooning, komprimering og hypervisor-swap genererer eksterne adgang eller page fault-spidser \u2013 og det er netop det, jeg \u00f8nsker at undg\u00e5. Transparent Page Sharing er ineffektivt i mange ops\u00e6tninger og kan sl\u00f8re synet af \u00e6gte lokalitet. Jeg kalibrerer blandingen af VM'er, s\u00e5 flere instanser, der kr\u00e6ver stor hukommelsesb\u00e5ndbredde, ikke kolliderer p\u00e5 samme node. For in-memory-motorer planl\u00e6gger jeg gener\u00f8se <strong>Reservationer<\/strong> og, hvor det er hensigtsm\u00e6ssigt, Huge Pages i g\u00e6sten, som hypervisoren kan videregive. P\u00e5 den m\u00e5de forbliver TLB-hitrate og adgangstider forudsigelige.<\/p>\n\n<h2>Live-migration og h\u00f8j tilg\u00e6ngelighed<\/h2>\n\n<p>Jeg tager h\u00f8jde for, at en <strong>Migration<\/strong> den midlertidige lokalitet af en VM \u00f8del\u00e6gges. Efter flytningen varmer jeg kritiske heaps op og lader baggrundsjob genopbygge hotsets. Jeg planl\u00e6gger m\u00e5lv\u00e6rter med lignende NUMA-topologi, s\u00e5 vNUMA ikke skal sk\u00e6res om. For HA-tilf\u00e6lde med heterogen hardware fastl\u00e6gger jeg politikker: Enten accepterer jeg kortvarigt h\u00f8jere latenstid, eller ogs\u00e5 prioriterer jeg v\u00e6rter med kompatibel knudest\u00f8rrelse. Det er vigtigt at observere efter migrationen: Hvis andelen af fjernside stiger, justerer jeg affiniteter eller udl\u00f8ser pre-faulting, indtil <strong>Lokalitet<\/strong> passer igen.<\/p>\n\n<h2>Praktiske diagnosem\u00f8nstre<\/h2>\n\n<p>Jeg genkender typiske NUMA-problemer p\u00e5 nogle f\u00e5 m\u00f8nstre: CPU'en bliver \u201evarm\u201c, men <strong>Instruktioner pr. cyklus<\/strong> forbliver lave; latenstiden svinger i b\u00f8lger; enkelte tr\u00e5de blokerer for hukommelsesadgang, selvom kerner er ledige. I s\u00e5danne tilf\u00e6lde ser jeg p\u00e5 fjernadgang, interconnect-udnyttelse, TLB-fejl og fordelingen af aktive tr\u00e5de pr. node. Jeg korrelerer interrupt-belastningen med de kerner, der b\u00e6rer applikationen, og kontrollerer, om caches mellem noder konstant bliver ugyldige. En enkel kontrol er at reducere VM'en til en node: Hvis latenstiderne falder med det samme, var spaning eller scheduling \u00e5rsagen. Ligeledes afsl\u00f8rer dedikerede tests RAM-b\u00e5ndbredden pr. node og viser, om DIMM-udrustning eller BIOS-indstillinger bremser.<\/p>\n\n<h2>Praksis-tjekliste<\/h2>\n\n<ul>\n  <li>Registrer topologi: knudepunkter, hukommelseskanaler, PCIe-tildeling, cache-dom\u00e6ner<\/li>\n  <li>Kontroller BIOS: Node Interleaving sl\u00e5et fra, energiprofil Performance, C-States flad<\/li>\n  <li>Klipning af VM'er: vCPU'er pr. VM \u2264 knudest\u00f8rrelse, vNUMA korrekt, bem\u00e6rk hot-add<\/li>\n  <li>Sikring af RAM: Reservationer til latenstidsarbejdsbelastninger, store sider, hvor det er relevant<\/li>\n  <li>Indstil affinitet: Bind tr\u00e5de, IRQ'er og I\/O-k\u00f8er til samme node<\/li>\n  <li>Containere\/pods: Brug knudepunktsaffinitet, CPU-manager og topologi-bevidsthed<\/li>\n  <li>Sp\u00e6nding kun m\u00e5lrettet: Store instanser med politikker og overv\u00e5gning som st\u00f8tte<\/li>\n  <li>Planl\u00e6gning af migration: Passende m\u00e5ltopologi, forh\u00e5ndsber\u00f8ring af heaps, overv\u00e5gning af lokalitet<\/li>\n  <li>Sk\u00e6rp overv\u00e5gningen: Fjernadgang, b\u00e5ndbredde pr. node, interconnect-udnyttelse<\/li>\n  <li>Test regelm\u00e6ssigt: B\u00e5ndbredde-\/latenskontrol efter firmware- eller v\u00e6rts\u00e6ndringer<\/li>\n<\/ul>","protected":false},"excerpt":{"rendered":"<p>Oplev, hvordan NUMA-arkitekturen revolutionerer serverens ydeevne, og hvorfor den er essentiel i moderne hosting-hardware. F\u00e5 tips til bedste praksis og optimering.<\/p>","protected":false},"author":1,"featured_media":15656,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_crdt_document":"","inline_featured_image":false,"footnotes":""},"categories":[922],"tags":[],"class_list":["post-15663","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-technologie"],"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":"2430","_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":null,"_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-Architektur","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":"15656","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/posts\/15663","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/comments?post=15663"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/posts\/15663\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/media\/15656"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/media?parent=15663"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/categories?post=15663"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/tags?post=15663"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}