{"id":19865,"date":"2026-06-10T11:53:56","date_gmt":"2026-06-10T09:53:56","guid":{"rendered":"https:\/\/webhosting.de\/server-numa-locality-cpu-memory-affinity-optimierung-core\/"},"modified":"2026-06-10T11:53:56","modified_gmt":"2026-06-10T09:53:56","slug":"server-numa-lokalitet-cpu-hukommelse-affinitet-optimering-kerne","status":"publish","type":"post","link":"https:\/\/webhosting.de\/da\/server-numa-locality-cpu-memory-affinity-optimierung-core\/","title":{"rendered":"Server NUMA Locality og CPU-Memory Affinity for maksimal hosting-ydelse"},"content":{"rendered":"<p><strong>Server NUMA<\/strong> Lokalitet og CPU-hukommelsesaffinitet bestemmer, hvor t\u00e6t tr\u00e5de arbejder p\u00e5 deres RAM, og hvor konstante latenstider der er i hosting-stacks. Jeg vil vise dig p\u00e5 en praktisk m\u00e5de, hvordan du kan opn\u00e5 m\u00e5lbart mere throughput med topologigenkendelse, affinitetsstrategier og I\/O-stier t\u00e6t p\u00e5 noden og <strong>Forsinkelse<\/strong> m\u00e6rkbart lavere.<\/p>\n\n<h2>Centrale punkter<\/h2>\n\n<p>For hurtig orientering opsummerer jeg de vigtigste budskaber, f\u00f8r jeg forklarer trinnene i detaljer og bakker dem op med eksempler, s\u00e5 du straks kan se, hvor du skal starte for at <strong>Lokalitet<\/strong> og Affinity p\u00e5 en rentabel m\u00e5de. Jeg l\u00e6gger v\u00e6gt p\u00e5 klare relationer mellem tr\u00e5de, hukommelse og I\/O, s\u00e5 du kan udlede prioriteter p\u00e5 en ren m\u00e5de og <strong>Beslutninger<\/strong> m\u00f8des. Jeg identificerer ogs\u00e5 scenarier, hvor Interleave giver mening uden at udvande dine kritiske stier, og viser, hvordan du kan demonstrere reelle fremskridt via overv\u00e5gning og <strong>Fejl<\/strong> undg\u00e5s. For virtualiserede milj\u00f8er giver jeg tips til placering af vCPU'er og vRAM, s\u00e5 g\u00e6stesystemer ikke glider over flere noder og <strong>Fjernbetjening<\/strong>-tilgangene eksploderer. Til sidst vil jeg oms\u00e6tte resultaterne til en kort k\u00f8replan, s\u00e5 du kan g\u00e5 struktureret frem og tage hvert skridt i den rigtige retning. <strong>m\u00e5lbar<\/strong> sikker.<\/p>\n<ul>\n  <li><strong>Lokalitet<\/strong> For det f\u00f8rste: Hold tr\u00e5dene t\u00e6t p\u00e5 din egen RAM, undg\u00e5 fjernbetjening.<\/li>\n  <li><strong>Affinitet<\/strong> L\u00f8s problemet: Bind kerner og hukommelse sammen via politik.<\/li>\n  <li><strong>Topologi<\/strong> l\u00e6se: Noder, kerner, PCIe-enheder pr. sokkel.<\/li>\n  <li><strong>I\/O-stier<\/strong> bundt: Par NIC, NVMe og app i samme node.<\/li>\n  <li><strong>messer<\/strong> i stedet for at g\u00e6tte: P95\/P99, fjernadgang og genneml\u00f8bssporing.<\/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\/06\/serverraum-performance-1573.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Forst\u00e5else af NUMA-topologien<\/h2>\n\n<p>F\u00f8r jeg flytter workloads, l\u00e6ser jeg <strong>Topologi<\/strong> af serveren: Hvor mange NUMA-noder der findes, hvor mange kerner og hvor meget RAM, der er forbundet til hver node. Jeg er ogs\u00e5 opm\u00e6rksom p\u00e5, hvilke PCIe-enheder - s\u00e5som NIC'er eller NVMe SSD'er - der er forbundet til hvilken sokkel, da dette bestemmer interrupt-stier og hukommelsesadgange, og hvor meget RAM der er forbundet til hver node. <strong>Forsinkelse<\/strong> karakteriseret. En node giver lokal hukommelsesadgang med kort afstand; alt derudover koster tid og b\u00e5ndbredde. Jo st\u00f8rre maskinen er med flere sockets, jo mere p\u00e5virker fjernadgang svartiderne og \u00e6der b\u00e5ndbredden. <strong>Gennemstr\u00f8mning<\/strong>. For en forst\u00e5elig introduktion til hardwarelogik finder jeg en kompakt <a href=\"https:\/\/webhosting.de\/da\/numa-nodes-server-hosting-store-systemer-serverboost\/\">Et overblik over NUMA-noder<\/a>, til bevidst at overveje nodegr\u00e6nser og undg\u00e5 forkerte fordelinger.<\/p>\n\n<p>I praksis starter jeg med en kort topologiopg\u00f8relse og dokumenterer den, s\u00e5 jeg senere kan udlede affinitetsbeslutninger p\u00e5 en forst\u00e5elig m\u00e5de. Nyttige kommandoer:<\/p>\n<pre><code>#-kerner og NUMA-tildeling\nlscpu -e=CPU,Core,Socket,Node\n\nOversigt over # NUMA-hardware\nnumactl --hardware\n\n# Tildel PCIe-enheder til deres NUMA-node\nlspci -nn | grep -E \"Ethernet|Non-Volatile\"\nfor d in \/sys\/bus\/pci\/devices\/*; do echo -n \"$d: \"; cat $d\/numa_node; done\n<\/code><\/pre>\n<p>Det vigtige er, at du <strong>PCIe-rodkompleks<\/strong> og enhedsslots til stikkene. To porte p\u00e5 samme NIC kan tildeles forskellige noder; det p\u00e5virker, hvor RX\/TX-k\u00f8er og IRQ'er lander bedst. Det samme g\u00e6lder for NVMe: Moderne controllere har flere k\u00f8er, som du b\u00f8r binde til kerner t\u00e6t p\u00e5 noden, s\u00e5 DMA ikke udl\u00f8ser node-hops.<\/p>\n\n<h2>Brug af CPU-hukommelsesaffinitet korrekt<\/h2>\n\n<p>Med CPU-Memory Affinity knytter jeg processer fast til kerneomr\u00e5der og gennemtvinger lokal hukommelsesallokering s\u00e5 vidt muligt, s\u00e5 <strong>Tr\u00e5de<\/strong> ikke konstant n\u00e5r ud over kanten af noden. I Linux definerer jeg CPU'er via systemd eller cgroups og kombinerer dette med hukommelsespolitikker, s\u00e5 RAM fortrinsvis oprettes p\u00e5 samme node og <strong>Fjernbetjening<\/strong> forbliver minimeret. Kritiske tjenester - API-frontends, in-memory caches, databaser - nyder godt af det med det samme, fordi hukommelsescontrollerens ventetid reduceres, og cache-hits er hyppigere. Men pinning-gr\u00e6nser, der er for h\u00e5rde, kan begr\u00e6nse planl\u00e6gningen, s\u00e5 jeg bakker hver justering op med benchmarks og observerer P95\/P99-v\u00e6rdier for m\u00e6rkbare effekter p\u00e5 <strong>Bruger<\/strong>-oplevelse. En kompakt introduktion til Affinity in hosting hj\u00e6lper dig med at komme i gang: <a href=\"https:\/\/webhosting.de\/da\/server-process-affinity-numa-awareness-hosting-ressourcentuning\/\">Affinitet og NUMA-bevidsthed<\/a> leverer de n\u00f8dvendige v\u00e6rkt\u00f8jer til ren placering.<\/p>\n\n<p>Den afg\u00f8rende faktor er <strong>Princippet om f\u00f8rste ber\u00f8ring<\/strong>Hukommelsen oprettes p\u00e5 den node, der f\u00f8rst skriver til siden. Derfor skal du initialisere store heaps eller buffere p\u00e5 m\u00e5lkernerne i den node, hvor tjenesten senere skal k\u00f8re - ideelt set med CPU- og hukommelsespolitikken allerede indstillet (f.eks. via systemd unit eller numactl). Hvis du starter cold p\u00e5 node 0 og derefter flytter tr\u00e5dene til node 1, forbliver st\u00f8rstedelen af siderne remote. For heaps med store runtimes er det v\u00e6rd at bruge \u201epre-touch\u201c under bootstrap, s\u00e5 siderne roterer lokalt og derefter forbliver varme.<\/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\/06\/server_numa_affinity_2763.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>NUMA-bevidsthed i hosting-stakken<\/h2>\n\n<p>Et NUMA-bevidst styresystem, en passende hypervisor og applikationer med thread pinning udfolder deres fulde potentiale sammen. <strong>Potentiale<\/strong>. Styresystemet foretr\u00e6kker lokal placering, hvis der er ledige ressourcer i noden, mens hypervisoren tildeler VM'er p\u00e5 en s\u00e5dan m\u00e5de, at vCPU'er og vRAM ikke glider fra hinanden, og <strong>Lokalitet<\/strong> vedligeholdes. I applikationen adskiller jeg worker pools pr. node og holder k\u00f8erne lokale i stedet for at drive globale pools p\u00e5 kryds og tv\u00e6rs. Jeg organiserer databaseprocesser, cache-daemoner og webserverinstanser node for node, s\u00e5 hotpaths forbliver korte og <strong>Jitter<\/strong> falder. Dette \u00f8ger konsistensen og forudsigeligheden under belastning, hvilket direkte p\u00e5virker forudsigeligheden af SLA'er i euro og sparer dyr overprovisionering.<\/p>\n\n<p>P\u00e5 Ingress-niveau tager jeg mig af <strong>Knudepunkts-affinitet<\/strong> af sessionerne, f.eks. gennem sticky routing eller konsekvent hashing (f.eks. p\u00e5 klient-IP eller sessionstoken), s\u00e5 anmodninger ender tilbage ved \u201ederes\u201c node-lokale worker og cache. For statslige tjenester planl\u00e6gger jeg replikaer pr. node og afbalancerer l\u00e6seadgang lokalt; jeg udligner skrivestier via asynkron replikering eller batching for at undg\u00e5 ping-pong mellem noderne.<\/p>\n\n<h2>Planl\u00e6g tjenester node for node<\/h2>\n\n<p>Jeg grupperer lagene i en stak p\u00e5 en s\u00e5dan m\u00e5de, at hvert lag har en klar knudepunktsreference og <strong>Stier<\/strong> Bliv ved med at v\u00e6re kort. En klassisk adskillelse: web\/API pr. node, app worker ved siden af, plus den lokale cache; databasen sidder ogs\u00e5 t\u00e6t p\u00e5 noden, hvis RAM-fodaftrykket passer ind og <strong>IO<\/strong>-stien bliver ikke afbrudt. Jeg flytter rapporteringsjobs, backups eller batchworkers til mindre kritiske noder, s\u00e5 interaktive foresp\u00f8rgsler ikke p\u00e5virkes. Jeg undg\u00e5r store monolit-instanser, fordi de ofte krydser nodegr\u00e6nser og derfor genererer fjernbelastning, som <strong>Ydelse<\/strong> sl\u00f8ret. Mindre, replikerede instanser pr. node giver ofte bedre gennemstr\u00f8mning i dagligdagen, da de respekterer NUMA-reglerne og udj\u00e6vner spidsbelastninger.<\/p>\n\n<p>Til kapacitetsplanl\u00e6gning beregner jeg <strong>Headroom<\/strong> separat for hver node: CPU-buffer til bursts, RAM-buffer mod OOM og separate marginer til sidecache. P\u00e5 den m\u00e5de forhindrer jeg, at kernen utilsigtet fejler eksternt. Jeg definerer klare skiftestier for failover: Hvis en node fejler, kan erstatningsinstanser k\u00f8re p\u00e5 tv\u00e6rs af noder, men jeg begr\u00e6nser deres samtidighed, indtil den oprindelige node er genoprettet - det holder den samlede latenstid stabil.<\/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\/06\/server-performance-numa-locality-4759.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Indstilling af CPU-affinitet: Metoder og faldgruber<\/h2>\n\n<p>Til kerneallokering bruger jeg systemd med CPUAffinity eller cgroups med cpuset.cpus, s\u00e5 tjenesterne har faste <strong>Kerneomr\u00e5der<\/strong> f\u00e5. Ved pinning er jeg opm\u00e6rksom p\u00e5 hyper-threading-par, fordi to logiske tr\u00e5de i en fysisk enhed deler ressourcer og kan g\u00f8re hinanden langsommere, hvis jeg kombinerer dem p\u00e5 en uheldig m\u00e5de, og <strong>Tips<\/strong> skabe. Latente stier - TLS-terminering, API-indgang, cachel\u00e6sere - f\u00e5r eksklusive kerner, mens logfiler, komprimering eller sikkerhedskopiering flyttes til andre pools. Puljer, der er for smalle uden buffere, skaber k\u00f8er, s\u00e5 jeg tager h\u00f8jde for headroom og tjekker context switches, runqueue-l\u00e6ngde og <strong>IRQ<\/strong>-fordeling. Ud fra observationen udleder jeg, om jeg skal \u00e5bne kernerne bredere eller koncentrere dem yderligere, indtil latenstidsfordelingen falder rent, og P99-toppene bliver mere stille.<\/p>\n\n<p>For yderligere jitter-reduktion indstiller jeg selektivt kernel-switches som f.eks. <strong>nohz_full<\/strong> og <strong>rcu_nocbs<\/strong> For kerner med eksklusiv latenstid skal du isolere dem fra systemtjenester og bevidst kun placere IRQ'er p\u00e5 CPU'er, der er beregnet til dette form\u00e5l. Jeg bruger \u201eirqbalance\u201c-tjenesten med forsigtighed: Konfigurer den enten specifikt eller deaktiver den, hvis den modarbejder din manuelle IRQ-affinitet. Jeg bruger SCHED_FIFO\/SCHED_RR sparsomt og kun med Be-gr\u00e6nser for at undg\u00e5 prioritetsinversion eller udsultning.<\/p>\n\n<h2>Hukommelsespolitikker og NUMA-masker<\/h2>\n\n<p>For hukommelsespolitikken skelner jeg mellem foretrukken lokal allokering, interleave p\u00e5 tv\u00e6rs af flere noder og faste NUMA-masker via cpuset.mems, s\u00e5ledes at <strong>RAM<\/strong> flyder til det sted, hvor tr\u00e5dene faktisk k\u00f8rer. For interaktive tjenester indstiller jeg normalt \u201epreferred\u201c, hvilket betyder, at systemet allokerer lokalt og kun afviger, n\u00e5r der er mangel p\u00e5 plads, hvilket er <strong>Fjernbetjening<\/strong>-adgang er begr\u00e6nset. Analyse- eller streamingjobs har nogle gange gavn af interleave, fordi b\u00e5ndbredden fordeles p\u00e5 tv\u00e6rs af noder, og presset p\u00e5 en controller reduceres. Faste masker giver kontrol, men kr\u00e6ver disciplin i kapacitetsplanl\u00e6gningen, s\u00e5 ingen u\u00f8nskede OOM-begivenheder i en node g\u00e5r op og ned. <strong>Tjenester<\/strong> blande sig. F\u00f8lgende tabel kategoriserer almindelige politikker i typiske scenarier og hj\u00e6lper dig med at tr\u00e6ffe en hurtig beslutning.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th><strong>Politik<\/strong><\/th>\n      <th><strong>Effekt<\/strong><\/th>\n      <th><strong>Typiske arbejdsbelastninger<\/strong><\/th>\n      <th><strong>Risiko<\/strong><\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>Foretrukket (lokal)<\/td>\n      <td>RAM prim\u00e6rt i den lokale node, reservemulighed i tilf\u00e6lde af knaphed<\/td>\n      <td>Web\/ API, caches, OLTP-databaser<\/td>\n      <td>Let afvigelse ved fuld belastning p\u00e5 andre noder<\/td>\n    <\/tr>\n    <tr>\n      <td>Interleave<\/td>\n      <td>J\u00e6vn fordeling p\u00e5 tv\u00e6rs af udvalgte noder<\/td>\n      <td>Streaming, analyse, store scanninger<\/td>\n      <td>H\u00f8jere latenstid for individuelle adgange<\/td>\n    <\/tr>\n    <tr>\n      <td>Fast NUMA-maske<\/td>\n      <td>Streng binding til definerede hukommelsesnoder<\/td>\n      <td>Strengt indkapslede tjenester, deterministiske tests<\/td>\n      <td>Risiko for OOM, hvis budgettet ikke er planlagt korrekt<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<p>Hold \u00f8je med systemd\u00e6kkende switches: <strong>zone_reclaim_mode<\/strong> p\u00e5virker, om en node aggressivt rydder op i sin egen hukommelse, f\u00f8r den allokerer eksternt - ofte u\u00f8nsket for latency paths. <strong>Gennemsigtige store sider<\/strong> (THP) kan udl\u00f8se sidemigration eller generere stall; for latensf\u00f8lsomme tjenester v\u00e6lger jeg normalt \u201emadvise\u201c og bruger statiske hugepages, hvor det giver mening, s\u00e5 TLB-hits \u00f8ges, og sidefejlspidser mindskes.<\/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\/06\/server_performance_optimization_2314.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Bind netv\u00e6rks- og I\/O-stier t\u00e6t p\u00e5 noden<\/h2>\n\n<p>Jeg tilpasser NIC-k\u00f8er (RX\/TX), s\u00e5 deres IRQ'er peger p\u00e5 kerner i den relevante node, og pakkebehandling finder sted, hvor <strong>App<\/strong> beregner. Det samme g\u00e6lder for NVMe SSD'er eller RAID-controllere: I\/O-tr\u00e5de b\u00f8r k\u00f8re p\u00e5 den node, som enheden er forbundet til via PCIe, s\u00e5 DMA-stierne forbliver korte, og enheden kan bruges mere effektivt. <strong>Flaskehalse<\/strong> ikke bliver til noget. Under Linux justerer jeg IRQ-affinitetsmasker og knytter dem til CPU-puljer i mine tjenester for at skabe en kontinuerlig sti. Ved mikroudbrud fra netv\u00e6rket, som f.eks. mange TLS-h\u00e5ndtryk, betaler denne n\u00e6rhed sig direkte, fordi kopistierne er kortere, og CPU-cacherne forbliver varme. <strong>Sammenh\u00e6ng<\/strong> mindre hyppigt. Dette resulterer i et ensartet dataflow fra pakken til applikationen til hukommelsen uden un\u00f8dvendige nodehops.<\/p>\n\n<p>Konkrete h\u00e5ndtag i netv\u00e6rksstakken: <strong>RSS<\/strong> til hardwaredistribution til k\u00f8er, <strong>RPS\/RFS<\/strong> til softwarebaseret CPU-kontrol og <strong>XPS<\/strong> til valg af TX. Jeg bruger ethtool til at tildele RX-k\u00f8er til kernegrupper, der k\u00f8rer i samme node som dine arbejdere. Til opbevaring bruger jeg <strong>blk-mq<\/strong>-tuning og kortl\u00e6gning af k\u00f8er pr. node; NVMe-controllere tilbyder flere submission\/completion-k\u00f8er, som jeg skalerer og affinerer \u2264 antal kerner pr. node. Tjek regelm\u00e6ssigt, om afbrydelser (cat \/proc\/interrupts) udl\u00f8ses, hvor dine app-kerner er placeret - du kan genkende drift ved at \u00f8ge antallet af fjernbytes p\u00e5 trods af en stabil belastning.<\/p>\n\n<h2>Strukturer applikationsarkitekturen i overensstemmelse med NUMA<\/h2>\n\n<p>P\u00e5 app-niveau opretter jeg mine egne worker pools for hver NUMA-node, holder k\u00f8erne lokale og undg\u00e5r globale lock-hotspots, s\u00e5 <strong>Tr\u00e5de<\/strong> ikke hoppe frem og tilbage. Jeg ops\u00e6tter session og data sharding, s\u00e5 varme partitioner forbliver der, hvor de anmodende medarbejdere k\u00f8rer, og <strong>Tid<\/strong> ikke g\u00e5r tabt i trafikken mellem noderne. Til cacher bruger jeg ofte replikaer i stedet for en central instans, s\u00e5 l\u00e6serne rammer node-lokale kopier. I Netty-, Tokio-, libuv- eller DB-klienter knytter jeg event-loops til faste kerner og er opm\u00e6rksom p\u00e5 IRQ-n\u00e6rhed, s\u00e5 opgave\u00e6ndringer forbliver begr\u00e6nsede og <strong>Cacher<\/strong> rammer bedre. Dette layout reducerer ping-pong-effekter og g\u00f8r svartiderne mere ensartede i l\u00f8bet af dagen.<\/p>\n\n<p>En undervurderet l\u00f8ftestang er <strong>Allocator<\/strong> og indstillinger for k\u00f8rselstid: NUMA-aktiverede allokatorer (jemalloc\/tcmalloc) reducerer stridigheder p\u00e5 tv\u00e6rs af tr\u00e5de og holder sider t\u00e6ttere p\u00e5 tr\u00e5dens hjemmekerne. I JVM-stakke hj\u00e6lper indstillinger som NUMA-bevidsthed og pre-touch til deterministiske fejlfaser; i .NET justerer jeg GC-tr\u00e5de t\u00e6t p\u00e5 noder og er opm\u00e6rksom p\u00e5 server-GC for at udj\u00e6vne stoptider. I Go dimensionerer jeg GOMAXPROCS pr. node-pool og holder goroutine-planl\u00e6ggere v\u00e6k fra latency-kerner, der arbejder t\u00e6t p\u00e5 IRQ.<\/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\/06\/server_performance_desk_7452.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Fornuftig kontrol af NUMA-autobalancering<\/h2>\n\n<p>Automatiske NUMA-balanceringsmekanismer i kernen kan hj\u00e6lpe med at udj\u00e6vne distribueret belastning, men jeg tjekker altid, om de kan underst\u00f8tte min <strong>Affinitet<\/strong> bliver undermineret. I latency-kritiske tjenester deaktiverer eller begr\u00e6nser jeg automatisk flytning, hvis det tr\u00e6kker tr\u00e5de ud af deres lokale hukommelse og <strong>Tips<\/strong> genereret. Til analysejobs eller bred batchbehandling plejer jeg at lade balancering v\u00e6re sl\u00e5et til, fordi det kan \u00f8ge b\u00e5ndbredden uden at forringe interaktionen. En praktisk introduktion til balanceringsstrategier giver mig flere udgangspunkter: <a href=\"https:\/\/webhosting.de\/da\/numa-balancering-server-hukommelse-optimering-hardware-numaflux\/\">Forst\u00e5else af NUMA-balancering<\/a> viser, hvorn\u00e5r det automatiske system skal b\u00e6re, og hvorn\u00e5r det skal tildeles manuelt. I sidste ende tr\u00e6ffer jeg en databaseret beslutning for hver serviceklasse i stedet for blindt at vedtage en global standardindstilling og <strong>M\u00e5l<\/strong> at g\u00e5 glip af.<\/p>\n\n<p>N\u00e5r balancering er aktiveret, overv\u00e5ger jeg migrationshastigheder, mindre\/st\u00f8rre fejltoppe og CPU-stj\u00e6leri pr. node. Hvis sider flyttes frem og tilbage cyklisk, modvirker jeg dette med strammere pinning, pre-touch og smallere hukommelsesmasker. I arbejdsbelastninger med lange, sekventielle scanninger kan balancering p\u00e5 den anden side harmonisere belastningen, forudsat at ingen interaktive latency-stier p\u00e5virkes.<\/p>\n\n<h2>Overv\u00e5gning: m\u00e5le, sammenligne, beslutte<\/h2>\n\n<p>Uden m\u00e5ling forbliver tuning en g\u00e6tteleg, s\u00e5 jeg sporer CPU-belastning pr. kerne og pr. node, hukommelsesudnyttelse pr. node og andelen af <strong>Fjernbetjening<\/strong>-adgang. For brugeroplevelsen t\u00e6ller P95\/P99-forsinkelser meget mere end gennemsnitsv\u00e6rdier, fordi afvigelser karakteriserer SLA-indtrykket, og <strong>Omkostninger<\/strong> opad. Jeg k\u00f8rer realistiske belastningsprofiler med kolde og varme cacher, fordi begge verdener viser forskellige flaskehalse. Efter hver \u00e6ndring dokumenterer jeg indstillingerne, testdatoen og resultaterne, s\u00e5 jeg med sikkerhed kan g\u00f8re \u00e6ndringerne om senere og <strong>Viden<\/strong> ikke g\u00e5r tabt. Hvis du ogs\u00e5 korrelerer app-metrikker - k\u00f8-l\u00e6ngder, fors\u00f8g, garbage collection - med systemv\u00e6rdier, kan du hurtigere genkende \u00e5rsag og virkning.<\/p>\n\n<p>Praktisk hj\u00e6lp til analysen:<\/p>\n<ul>\n  <li>numastat (system- og procesrelateret) for lokal vs. <strong>Fjernbetjening<\/strong>-Hit<\/li>\n  <li>\/proc\/interrupts og SoftIRQ-tid efter CPU for IRQ-drift<\/li>\n  <li>perf events og scheduler-statistikker for runqueue depth, context switches, LLC misses osv.<\/li>\n  <li>fio\/iperf\/wrk med nodespecifikke arbejdspuljer for reproducerbare sammenligninger<\/li>\n<\/ul>\n<p>Evalueringen foretages pr. node: Jeg forventer, at latency-histogrammerne ligger t\u00e6t p\u00e5 hinanden. Hvis en node bev\u00e6ger sig opad, leder jeg f\u00f8rst efter forkert fordelt IRQ-belastning, drift i sidecachen eller heaps, der blev allokeret til den forkerte node under opvarmningen.<\/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\/06\/hosting-serverraum-8372.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>NUMA i VM'er og containere<\/h2>\n\n<p>I virtualisering er placeringen af vCPU'er og vRAM p\u00e5 en delt node vigtig, s\u00e5 g\u00e6stearbejdsm\u00e6ngderne ikke flosser ud, og <strong>Forsinkelse<\/strong> tr\u00e6kker op. Jeg dimensionerer RAM, s\u00e5 det passer ind i den lokale node og undg\u00e5r store VM'er, der str\u00e6kker sig over flere noder og <strong>Drift<\/strong> udl\u00f8ser. Til containere bruger jeg cpuset-controllere, s\u00e5 pod-grupper arbejder konsekvent p\u00e5 \u00e9n node, og storage oprettes lokalt. Jeg foretr\u00e6kker at placere I\/O-tunge g\u00e6ster p\u00e5 noden med en direkte lagerforbindelse for at holde DMA-stierne korte og <strong>IRQ<\/strong>-reducere st\u00f8j. Det betyder, at selv t\u00e6tte virtualiseringsv\u00e6rter forbliver forudsigelige og kan gennemf\u00f8re flere projekter p\u00e5 den samme hardware.<\/p>\n\n<p>Jeg er opm\u00e6rksom p\u00e5 <strong>vNUMA<\/strong>Eksponering: G\u00e6sten skal se den samme nodestruktur, som hypervisoren fysisk giver. vCPU-pinning og vRAM-binding h\u00f8rer sammen; jeg flytter hot-adds under vedligeholdelsesvinduer, hvis det er muligt, fordi nye sider ellers ender eksternt. I Kubernetes s\u00e6tter jeg QoS til \u201eguaranteed\u201c, CPU manager til \u201estatic\u201c og topology-aware placement, s\u00e5 pods ikke bev\u00e6ger sig p\u00e5 tv\u00e6rs af noder. For SR-IOV\/VF'er tildeler jeg VF'er til den relevante fysiske node og binder IRQ-k\u00f8erne til CPU-s\u00e6ttene i de pods eller VM'er, de betjener.<\/p>\n\n<h2>M\u00e5lrettet forberedelse af f\u00f8rste ber\u00f8ring, opvarmning og masser af arbejde<\/h2>\n\n<p>Mange pr\u00e6stationsfejl opst\u00e5r under <strong>Start<\/strong>Heaps vokser i opvarmningsfasen, hvor de f\u00f8rste foresp\u00f8rgsler lander - ofte centralt p\u00e5 en node. Jeg k\u00f8rer derfor kontrollerede opvarmninger for hver node: Jeg starter instanser med en bestemt CPU\/hukommelsesmaske, udf\u00f8rer m\u00e5lrettede pre-load-foresp\u00f8rgsler og initialiserer cacher parallelt for hver node. For JVM-tjenester aktiverer jeg pre-touch af heapen; for databaser segmenterer jeg bufferpuljer node for node. Det reducerer efterf\u00f8lgende sidemigrationer og sikrer, at de f\u00f8rste foresp\u00f8rgsler ikke tilf\u00e6ldigt pr\u00e6ger hukommelsesfordelingen.<\/p>\n\n<h2>Kernel\/BIOS-tuning for konstante ventetider<\/h2>\n\n<p>Under motorhjelmen justerer jeg str\u00f8mmen og afbryder politikken:<\/p>\n<ul>\n  <li>S\u00e6t CPU-guvern\u00f8ren til \u201eperformance\u201c, begr\u00e6ns dybe C-states, brug pakke-C-states omhyggeligt for at <strong>Jitter<\/strong> for at reducere.<\/li>\n  <li>Begr\u00e6ns ikke hukommelsesfrekvensen; afbalancerede energiprofiler minimerer ofte <strong>Gennemstr\u00f8mning<\/strong> under belastning.<\/li>\n  <li>Undg\u00e5 spread spectrum\/klokkemodulation, hvis konsistens er vigtigere end minimale energibesparelser.<\/li>\n<\/ul>\n<p>P\u00e5 kerneniveau holder jeg husholdnings-CPU'er adskilt fra latency-kerner, minimerer timerafbrydelser p\u00e5 varme kerner (nohz_full) og parkerer baggrundsarbejde (compaction, Kswapd) fortrinsvis p\u00e5 systemkerner i en node, der ikke k\u00f8rer latency-stier.<\/p>\n\n<h2>Fejlfinding og typiske anti-m\u00f8nstre<\/h2>\n\n<ul>\n  <li><strong>Symptom<\/strong>P99-latency hopper efter udrulning. <strong>\u00c5rsag<\/strong>Heaps\/Caches first-touch p\u00e5 forkert node. <strong>L\u00f8sning<\/strong>Opvarmning\/pre-touch under m\u00e5laffinitet, og \u00e5bn derefter belastningsfordeleren.<\/li>\n  <li><strong>Symptom<\/strong>H\u00f8j SoftIRQ-tid p\u00e5 \u201eforkerte\u201c CPU'er. <strong>\u00c5rsag<\/strong>irqbalance fordelt p\u00e5 noder. <strong>L\u00f8sning<\/strong>Fix IRQ-affinitet, s\u00e6t RPS\/RFS\/XPS node-kompatibel.<\/li>\n  <li><strong>Symptom<\/strong>OOM i en node, selv om systemets RAM er ledig. <strong>\u00c5rsag<\/strong>Streng NUMA-maske uden buffer. <strong>L\u00f8sning<\/strong>Korrekt kapacitet eller brug \u201eforetrukket\u201c, opret alarmer pr. node.<\/li>\n  <li><strong>Symptom<\/strong>Uregelm\u00e6ssig gennemstr\u00f8mning med NVMe. <strong>\u00c5rsag<\/strong>Forkert k\u00f8-kortl\u00e6gning, delte k\u00f8er p\u00e5 tv\u00e6rs af noder. <strong>L\u00f8sning<\/strong>: blk-mq\/NVMe-k\u00f8er pr. node, I\/O-tr\u00e5de fastgjort.<\/li>\n<\/ul>\n\n<h2>Tjekliste til praksis<\/h2>\n\n<ul>\n  <li>Registrer topologi: Noder, kerner, RAM, PCIe-enheder pr. sokkel.<\/li>\n  <li>Tegn serviceafsnit: Hvilke stier er <strong>Forsinkelse<\/strong>-kritisk, hvilket parti?<\/li>\n  <li>Indstil CPU\/hukommelsesaffinitet for hver klasse; bem\u00e6rk f\u00f8rste ber\u00f8ring ved start.<\/li>\n  <li>Bind IRQ\/k\u00f8er t\u00e6t p\u00e5 noden; tjek RSS\/RPS\/XPS og NVMe-k\u00f8er.<\/li>\n  <li>Overv\u00e5gning p\u00e5 P95\/P99, fjernadgang, k\u00f8rek\u00f8, IRQ-fordeling.<\/li>\n  <li>Kontroller autobalanceringen specifikt; v\u00e6lg THP\/zone_reclaim_mode p\u00e5 passende vis.<\/li>\n  <li>Hold vNUMA, vCPU-pinning og vRAM-binding konsekvent i VM'er\/containere.<\/li>\n  <li>Test iterativt, dokumenter, rul tilbage i tilf\u00e6lde af afvigelser, og finjuster.<\/li>\n<\/ul>\n\n<h2>Kort resum\u00e9 og tidsplan for tuning<\/h2>\n\n<p>Det giver det st\u00f8rste afkast, <strong>Tr\u00e5de<\/strong> og hukommelse sammen, forkorte I\/O-stier og kun distribuere dem omhyggeligt. Jeg starter med en topologianalyse, planl\u00e6gger tjenester node for node, indstiller CPU- og hukommelsesaffinitet, forbinder netv\u00e6rk\/lager p\u00e5 passende vis og overv\u00e5ger P95\/P99-v\u00e6rdier med fokus p\u00e5 <strong>Fjernbetjening<\/strong>-adgange. Derefter justerer jeg puljest\u00f8rrelserne, IRQ-maskerne og politikkerne, indtil latency-toppene aftager, og gennemstr\u00f8mningen stiger. For VM'er og containere tjekker jeg placeringen separat, fordi hypervisoren har stor indflydelse, og <strong>Gr\u00e6nser<\/strong> fungerer forskelligt. Hvis du gentager og dokumenterer denne proces, vil du f\u00e5 m\u00e5lbart mere ydelse ud af Server NUMA Locality og CPU-Memory Affinity - ofte billigere end at opgradere ekstra hardware i euro.<\/p>","protected":false},"excerpt":{"rendered":"<p>L\u00e6r, hvordan Server NUMA Locality og CPU-Memory Affinity optimerer din hosting-ydelse. Guiden viser praktisk performance-tuning til moderne servere.<\/p>","protected":false},"author":1,"featured_media":19858,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[676],"tags":[],"class_list":["post-19865","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":"58","_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":"Server 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":"19858","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/posts\/19865","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=19865"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/posts\/19865\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/media\/19858"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/media?parent=19865"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/categories?post=19865"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/tags?post=19865"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}