{"id":21443,"date":"2026-09-16T08:36:31","date_gmt":"2026-09-16T06:36:31","guid":{"rendered":"https:\/\/webhosting.de\/linux-numa-statistiken-auswerten\/"},"modified":"2026-09-16T08:36:31","modified_gmt":"2026-09-16T06:36:31","slug":"analyse-af-linux-numa-statistikker","status":"publish","type":"post","link":"https:\/\/webhosting.de\/da\/linux-numa-statistiken-auswerten\/","title":{"rendered":"S\u00e5dan analyseres Linux NUMA-statistikker korrekt"},"content":{"rendered":"<p><strong>Linux NUMA<\/strong> Statistikkerne viser mig, hvor godt processerne opretholder deres lokale hukommelse, og hvor eksterne adgangsforesp\u00f8rgsler \u00f8ger latenstiden. Jeg forklarer, hvordan jeg fortolker disse tal m\u00e5lrettet, vurderer tendenser over tid og ud fra det udarbejder klare optimeringstiltag til <strong>Ydelse<\/strong> Derive.<\/p>\n\n<h2>Centrale punkter<\/h2>\n<ul>\n  <li><strong>At forst\u00e5 t\u00e6llere<\/strong>: numa_hit, numa_miss, numa_foreign, local_node, other_node, interleave_hit<\/li>\n  <li><strong>Vurdere konteksten<\/strong>: Belastningsprofil, topologi, arbejdsbelastningstype<\/li>\n  <li><strong>M\u00e5ling af tendenser<\/strong>: F\u00f8r\/efter og om intervaller<\/li>\n  <li><strong>Kontrollere processer<\/strong>: Systemomfattende vs. pr. proces<\/li>\n  <li><strong>Anvend tuning<\/strong>: Affinitet, retningslinjer, placering<\/li>\n<\/ul>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/linux-numa-analyse-8293.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Hvad NUMA-statistikkerne egentlig viser<\/h2>\n\n<p>Jeg opfatter NUMA-tal som et kort over <strong>Opbevaringssted<\/strong> og dataveje. En h\u00f8j <strong>numa_hit<\/strong> betyder, at allokeringerne er endt p\u00e5 den \u00f8nskede node. Derimod angiver numa_miss, at kernen har v\u00e6ret n\u00f8dt til at skifte til en anden node. T\u00e6lleren numa_foreign viser modstykket p\u00e5 m\u00e5lnoden og fuldender billedet. Med local_node og other_node kan jeg se, om adgangene forblev lokale eller benyttede fjernlager.<\/p>\n\n<p>Disse v\u00e6rdier skal aldrig fortolkes isoleret, fordi <strong>Arbejdsbyrder<\/strong> reagerer meget forskelligt. Korte processer medf\u00f8rer i enkelte tilf\u00e6lde fejl, uden at det m\u00e6rkbart \u00e6ndrer den samlede ydeevne. Interleave-politikker skaber derimod bevidst spredte allokeringer, hvilket f\u00e5r interleave_hit til at stige. Derfor tjekker jeg altid den tilsigtede politik og den aktuelle belastning. F\u00f8rst derefter beslutter jeg, om en v\u00e6rdi kr\u00e6ver handling, eller om den passer til designet.<\/p>\n\n<p>For mig er hovedtanken f\u00f8lgende: <strong>T\u00e6ller<\/strong> De leverer signaler, ikke vurderinger. Jeg leder efter m\u00f8nstre over tid, ikke enkeltv\u00e6rdier. P\u00e5 den m\u00e5de kan jeg se, om en \u00e6ndring i systemet flytter lokaliteten. F\u00f8rst p\u00e5 baggrund af dette tendensbillede vurderer jeg, om jeg skal flytte processer, tilpasse politikker eller indstille CPU-bindinger. Hver NUMA-analyse starter derfor med et klart sp\u00f8rgsm\u00e5l og gentagelige m\u00e5lepunkter.<\/p>\n\n<h2>Fortolke kernet\u00e6llere i sammenh\u00e6ng<\/h2>\n\n<p>Jeg sammenligner altid <strong>numa_hit<\/strong> og sammenligner numa_miss med hinanden i stedet for at vurdere absolutte v\u00e6rdier. Hvis antallet af fejl stiger, tjekker jeg samtidig udviklingen i numa_foreign p\u00e5 de potentielle m\u00e5lknudepunkter. Hvis begge dele stemmer overens, tyder det p\u00e5 en reel flytning og ikke blot en artefakt fra udl\u00e6sningen. local_node og other_node supplerer dette billede med oplysninger om de faktiske adgangsh\u00e6ndelser. P\u00e5 den m\u00e5de kan jeg se, om en allokering ganske vist startede lokalt, men om driften senere l\u00e6ste fra mere fjerntliggende hukommelse.<\/p>\n\n<p>En enkelt h\u00f8j <strong>other_node<\/strong> Det generer mig ikke, hvis arbejdsbyrden fordeles bevidst. Webservere med mange arbejdsprocesser drager derimod fordel af en ensartet placering. Derfor ser jeg p\u00e5 de enkelte processer og ikke kun det samlede billede. S\u00e5 snart enkelte tjenester afviger fra m\u00f8nstret, tager jeg fat p\u00e5 deres placering. F\u00f8rst n\u00e5r der opst\u00e5r fejl p\u00e5 systemniveau, leder jeg efter \u00e5rsager i topologien eller belastningen.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/linux_numa_meeting_8326.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Sammenligninger over tid: En m\u00e5lerutine, der giver resultater<\/h2>\n\n<p>Jeg afl\u00e6ser m\u00e5lerstandene ved begyndelsen og slutningen af en <strong>Sidste fase<\/strong> og beregner forskellen. Enkeltv\u00e6rdier sl\u00f8rer effekterne, mens forskelle viser udviklingen. Gentagne intervaller p\u00e5 for eksempel 30 til 60 sekunder er ofte nok til at genkende tendenser. Efter implementeringer, kerneopdateringer eller hardware\u00e6ndringer sammenligner jeg de samme intervaller igen. Hvis der s\u00e5 opst\u00e5r flere fejl, eller hvis local_node forskydes, er der tale om en reel \u00e6ndring.<\/p>\n\n<p>S\u00e5danne tidsserier d\u00e6kker <strong>Placeringsfejl<\/strong> hurtigere end \u00f8jebliksbilleder. Jeg sammenholder kurverne med CPU-udnyttelse, kontekstskift og hukommelsesforbrug pr. node. P\u00e5 den m\u00e5de kan jeg se, om flaskehalse i en nodes RAM f\u00f8rer til omdirigeringer. Eller om nye processer forrykker balancen i noderne. Selve andelen af hits og misses angiver jeg altid som en kurve, ikke som et enkelt tal.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/linux-numa-stat-analysis-4857.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Kontroller p\u00e5 systemniveau, og zoom derefter ind p\u00e5 processerne<\/h2>\n\n<p>Jeg starter med det overordnede overblik fra <strong>numastat<\/strong> og f\u00f8rst derefter gennemg\u00e5r jeg de enkelte processer. Denne r\u00e6kkef\u00f8lge sparer tid, fordi mange effekter bliver synlige p\u00e5 globalt plan. Til procesoversigten bruger jeg den processpecifikke udskrift til at isolere tjenester, der v\u00e6kker opm\u00e6rksomhed. S\u00e5 snart kandidaterne er udpeget, justerer jeg <strong>Placering<\/strong> om CPU- og hukommelsesbelastning. Artiklen om dette emne indeholder en r\u00e6kke praktiske tips til <a href=\"https:\/\/webhosting.de\/da\/server-numa-lokalitet-cpu-hukommelse-affinitet-optimering-kerne\/\">CPU- og hukommelsesaffinitet<\/a>.<\/p>\n\n<p>Is\u00e6r n\u00e5r det g\u00e6lder Java-tjenester, PHP-FPM eller databaser, er det ofte nok med en ordentlig <strong>Affinitet<\/strong>, for at reducere fejl markant. Container-orkestrering har en tendens til at skjule disse problemer, fordi schedulere fordeler ressourcerne uden at tage h\u00f8jde for NUMA. Derfor kontrollerer jeg nodetildelingen pr. pod eller VM. Hvis CPU-s\u00e6t og RAM-tildeling stemmer overens, stiger local_node m\u00e6rkbart. Nogle problemer l\u00f8ser sig, s\u00e5 snart processen k\u00f8rer t\u00e6t p\u00e5 det n\u00f8dvendige datas\u00e6t.<\/p>\n\n<h2>Oversigt over NUMA-t\u00e6llere (tabel)<\/h2>\n\n<p>N\u00e5r jeg vurderer et nyt system, udfylder jeg f\u00f8lgende tabel, s\u00e5 jeg kan se hver <strong>N\u00f8gletal<\/strong> hurtigt indordne. Den viser betydning, typisk fortolkning og mulige foranstaltninger. Jeg opfatter den ikke som et fast skema, men som en tjekliste. Det afg\u00f8rende er stadig afstemningen med belastningsprofilen og servertopologien. F\u00f8rst med denne kontekst kan jeg tr\u00e6ffe en fornuftig beslutning.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th><strong>T\u00e6ller<\/strong><\/th>\n      <th><strong>Betydning<\/strong><\/th>\n      <th><strong>fortolkning<\/strong><\/th>\n      <th><strong>Fremgangsm\u00e5de<\/strong><\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>numa_hit<\/td>\n      <td>Allokering ved det \u00f8nskede knudepunkt<\/td>\n      <td>En h\u00f8j v\u00e6rdi er positiv<\/td>\n      <td>Behold placeringen<\/td>\n    <\/tr>\n    <tr>\n      <td>numa_miss<\/td>\n      <td>Allokeringen blev flyttet til andre noder<\/td>\n      <td>\u00d8get risiko for forsinkelser<\/td>\n      <td>Kontroller Affinity\/Policy<\/td>\n    <\/tr>\n    <tr>\n      <td>numa_foreign<\/td>\n      <td>Ekstern allokering p\u00e5 denne node<\/td>\n      <td>Modstykke til numa_miss<\/td>\n      <td>Analysere m\u00e5lnoder<\/td>\n    <\/tr>\n    <tr>\n      <td>local_node<\/td>\n      <td>Adgang til lokal lagerplads<\/td>\n      <td>Jo h\u00f8jere, desto billigere<\/td>\n      <td>Processen t\u00e6ttere p\u00e5 RAM'en<\/td>\n    <\/tr>\n    <tr>\n      <td>other_node<\/td>\n      <td>Adgang til fjernlager<\/td>\n      <td>Kun bekymrende, men uden hensigt<\/td>\n      <td>Kontroller topologi\/belastning<\/td>\n    <\/tr>\n    <tr>\n      <td>interleave_hit<\/td>\n      <td>Treffere ved interleave-fordeling<\/td>\n      <td>Forventet ved Interleave-Policy<\/td>\n      <td>Vurdere ensartethed<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<p>Med denne <strong>Oversigt<\/strong> Jeg beslutter hurtigere, hvorn\u00e5r jeg skal gribe ind. En stigning i numa_miss uden nogen forklarlig \u00e6ndring udl\u00f8ser en \u00e5rsagsanalyse. Hvis interleave_hit forbliver h\u00f8jt, kontrollerer jeg, om politikken er aktiv som tilsigtet. Hvis other_node viser v\u00e6kst uden stigning i belastningen, unders\u00f8ger jeg fortr\u00e6ngende arbejdsbelastninger. P\u00e5 den m\u00e5de bliver tabellen udgangspunktet for m\u00e5lrettede tiltag.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/NUMA_Statistik_Auswertung_1023.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>At forst\u00e5 og anvende NUMA-topologi<\/h2>\n\n<p>Inden jeg begynder at tune, tjekker jeg <strong>Topologi<\/strong> p\u00e5 serveren: sockets, kerner, hukommelseskanaler, latenstier. Hvis en proces k\u00f8rer p\u00e5 socket 0, men datablokkene ligger p\u00e5 socket 1, stiger adgangstiden. Det neds\u00e6tter gennemstr\u00f8mningen og f\u00e5r svartiderne til at svinge. Is\u00e6r hukommelseskr\u00e6vende tjenester m\u00e6rker enhver un\u00f8dvendig afstand. Derfor placerer jeg dataintensive processer p\u00e5 noder med tilstr\u00e6kkelig ledig RAM.<\/p>\n\n<p>Asymmetrisk <strong>Forbindelser<\/strong> forst\u00e6rker effekterne, f.eks. n\u00e5r en node bruger f\u00e6rre kanaler. I s\u00e5danne tilf\u00e6lde flytter jeg m\u00e5lrettet den cachelagrede datam\u00e6ngde i stedet for at fordele processen. Jeg konfigurerer VM- og container-v\u00e6rter s\u00e5ledes, at hver instans f\u00e5r en konsistent node-tilknytning. P\u00e5 den m\u00e5de reducerer jeg fjerntrafikken uden at begr\u00e6nse kvoterne. Maskinens fysiske begr\u00e6nsninger s\u00e6tter rammerne, og dem holder jeg mig til.<\/p>\n\n<h2>At forst\u00e5 interleave og balancering korrekt<\/h2>\n\n<p>Interleave-politikker fordeler hukommelsen bevidst p\u00e5 tv\u00e6rs af noder, s\u00e5 <strong>Gennemstr\u00f8mning<\/strong> stiger pr. proces, eller hotspots falder. I denne konfiguration betragtes h\u00f8je interleave_hit-v\u00e6rdier som \u00f8nskelige. Jeg tjekker da is\u00e6r j\u00e6vnheden, ikke den absolutte lokalitet. AutoNUMA eller NUMA-balancering kan hj\u00e6lpe, men ikke i alle situationer.<\/p>\n\n<p>Jeg beslutter fra situation til situation, om automatisk <strong>Afbalancering<\/strong> forbliver aktiv. Ved konsistente, langvarige tjenester foretr\u00e6kker jeg faste tilknytninger. Ved skiftende belastninger kan AutoNUMA reagere hensigtsm\u00e6ssigt. Et godt overblik over fordele og risici findes i artiklen <a href=\"https:\/\/webhosting.de\/da\/deaktiver-numa-balancing-eller-lad-den-vaere-aktiveret-for-optimal-ydeevne-i-linux\/\">NUMA-balancering<\/a>. F\u00f8rst n\u00e5r m\u00e5let og rammerne er klare, v\u00e6lger jeg den passende indstilling.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/NUMA_Statistik_Auswertung_1023.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Arbejdsbelastningsm\u00f8nstre: Databaser, virtuelle maskiner, webtjenester<\/h2>\n\n<p>Databaser er f\u00f8lsomme over for <strong>Forsinkelse<\/strong> mellem CPU og RAM. Derfor holder jeg instansen, buffer-cachen og de aktive shards p\u00e5 samme node. Virtuelle maskiner drager fordel af veldefinerede CPU-s\u00e6t plus node-RAM, s\u00e5 g\u00e6stoperativsystemer ser konsistente stier. Webtjenester med mange arbejdere fungerer bedst, n\u00e5r arbejdergrupper forbliver bundet til en enkelt node. Til lagringsstrategien bruger jeg, afh\u00e6ngigt af situationen, m\u00e5lrettede <a href=\"https:\/\/webhosting.de\/da\/numa-hukommelsespolitikker-databasesserver-optimering-server\/\">NUMA-hukommelsespolitikker<\/a>.<\/p>\n\n<p>Analytiske opgaver og store scanninger udf\u00f8rer jeg derimod delvist <strong>fordelt<\/strong> . Her giver interleave ofte bedre b\u00e5ndbredde end h\u00e5rd lokalitet. Det er vigtigt at se \u00e6rligt p\u00e5 arbejdsbelastningens I\/O-m\u00f8nstre. Skrivning dominerer p\u00e5 en anden m\u00e5de end l\u00e6sning, og tilf\u00e6ldige adgangsforesp\u00f8rgsler p\u00e5 en anden m\u00e5de end sekventielle. Jeg v\u00e6lger den politik, der passer til adgangsmodellen, ikke den, der lyder godt i l\u00e6rebogen.<\/p>\n\n<h2>Praktisk m\u00e5lerutine og v\u00e6rkt\u00f8jer<\/h2>\n\n<p>Til at begynde med er det nok for mig <strong>numastat<\/strong> og procesvisningen. Jeg registrerer t\u00e6llerstande med dato, PID og belastningsindikatorer. Det er vigtigt at foretage m\u00e5lingerne inden for identiske tidsvinduer. P\u00e5 den m\u00e5de kan man tydeligt afspejle forskelle f\u00f8r og efter. I produktive vinduer noterer jeg forskellene ned og korrelerer dem med release-tidspunkter.<\/p>\n\n<p>Ved p\u00e5faldende <strong>Serviceydelser<\/strong> Derudover kontrollerer jeg CPU-tilknytningen og knudevisningen med v\u00e6rkt\u00f8jer som lscpu, numactl og perf-visning for fjernbelastning. Jeg dokumenterer den valgte politik for hver m\u00e5lerunde. Efter en \u00e6ndring foretager jeg en ny m\u00e5ling. F\u00f8rst n\u00e5r trendlinjerne stabiliserer sig, vurderer jeg effekten som vellykket. Blind skift f\u00f8rer let til tilsyneladende forbedringer.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/linux_numa_auswertung_7463.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Undg\u00e5 almindelige fejltolkninger<\/h2>\n\n<p>En h\u00f8j <strong>interleave_hit<\/strong> er ikke en fejl, hvis interleave er bevidst aktiveret. P\u00e5 samme m\u00e5de er en enkelt fejl ubetydelig ved lang k\u00f8rselstid. Jeg tjekker altid t\u00e6thed og fordeling over hele intervallet, ikke kun spidsbelastninger. Nogle tolker \u00bbother_node\u00ab som generelt negativt og overser arbejdsbelastningens karakter. Derfor ser jeg f\u00f8rst p\u00e5 designm\u00e5let og vurderer derefter tallene.<\/p>\n\n<p>En anden misforst\u00e5else: <strong>Samlet overblik<\/strong> Godt, s\u00e5 er alt i orden. Ofte gemmer afvigelser sig kun i nogle f\u00e5 PID\u2019er. Eller s\u00e5 fordeler container-scheduleren pods p\u00e5 tv\u00e6rs af noder, selvom en lokal gruppe ville v\u00e6re mere hensigtsm\u00e6ssig. S\u00e5danne effekter ser jeg f\u00f8rst, n\u00e5r jeg m\u00e5ler pr. proces. Uden denne dybde forbliver analysen ufuldst\u00e6ndig.<\/p>\n\n<h2>Effektive tuning-trin<\/h2>\n\n<p>Jeg begynder med <strong>Placering<\/strong>: Processer p\u00e5 de noder, hvor dataene befinder sig eller skal befinde sig. Derefter indstiller jeg CPU-affinitet, s\u00e5 tr\u00e5de ikke springer p\u00e5 tv\u00e6rs af sokler. Herefter f\u00f8lger hukommelsesbinding, s\u00e5 kernen allokerer p\u00e5 det \u00f8nskede sted. Ved variable belastninger tjekker jeg politikkerne og, hvis det er relevant, AutoNUMA.<\/p>\n\n<p>Derefter s\u00f8rger jeg for <strong>Konsistens<\/strong> I livscyklussen: Genstarter, implementeringer og skaleringer m\u00e5 ikke \u00e6ndre nodehenvisninger tilf\u00e6ldigt. Jeg dokumenterer tilknytninger som kode, s\u00e5 de forbliver reproducerbare. Derefter m\u00e5ler jeg igen, vurderer forskellene og tr\u00e6ffer beslutning om finjustering. Enhver \u00e6ndring fortjener et klart m\u00e5lebevis.<\/p>\n\n<h2>Praksisexempel: Fra fiasko til succes<\/h2>\n\n<p>Lad os antage, at en <strong>Database<\/strong> viser flere \u00bbnuma_miss\u00ab og stigende \u00bbother_node\u00ab under belastning. Foresp\u00f8rgslernes ventetid svinger mere. Jeg tjekker f\u00f8rst procesallokeringen og konstaterer, at tjenesten efter en udrulning k\u00f8rer p\u00e5 node A, mens cachen er allokeret til node B. Efter fast CPU- og hukommelsestilknytning til node B vender forholdet: numa_hit stiger, mens missene falder. Svarstiderne bliver mere konstante, og CPU-belastningen falder let, fordi fjernadgangen bortfalder.<\/p>\n\n<p>Samtidig tjekker jeg <strong>Politik<\/strong>. Interleave var utilsigtet aktiveret og havde fordelt allokeringerne. Efter skiftet til den foretrukne node forbliver cachen lukket lokalt. Efter en times m\u00e5ling bekr\u00e6fter deltaerne forbedringen. F\u00f8rst da betragter jeg optimeringen som en succes. Uden denne kontrolm\u00e5ling ville et \u00f8jebliksbillede have v\u00e6ret vildledende.<\/p>\n\n<h2>M\u00e5linger og retningslinjer til brug i praksis<\/h2>\n\n<p>N\u00e5r jeg skal tr\u00e6ffe beslutninger, bruger jeg p\u00e5lidelige <strong>Odds<\/strong> i stedet for individuelle r\u00e5v\u00e6rdier. For hver proces beregner jeg allokeringsprocenten local_alloc = numa_hit \/ (numa_hit + numa_miss). Derudover vurderer jeg <strong>Adgangsprocent<\/strong> local_access = local_node \/ (local_node + other_node). Disse to v\u00e6rdier tilsammen viser, om hukommelsen forbliver lokal, selv efter allokeringen. Som grove retningslinjer bruger jeg f\u00f8lgende: Ved latenstidsf\u00f8lsomme tjenester sigter jeg mod fjernadgang p\u00e5 under 5\u201310 %. Ved analytiske b\u00e5ndbredde-workloads tolererer jeg 20\u201330 %, forudsat at gennemstr\u00f8mningen stiger. Det afg\u00f8rende er <strong>Stabilitet<\/strong> over tid. Jeg foretr\u00e6kker en v\u00e6rdi, der forbliver stabil under belastning, frem for en kortvarig top med perfekte tal. Jeg dokumenterer disse m\u00e5leintervaller for hver service, s\u00e5 senere m\u00e5linger let kan indplaceres.<\/p>\n\n<h2>Cgroups, containere og faldgruber ved planl\u00e6gning<\/h2>\n\n<p>I container-milj\u00f8er tjekker jeg f\u00f8rst <strong>cpuset<\/strong>\u2011Tildeling: CPU-s\u00e6t og <em>cpuset.mems<\/em> skal d\u00e6kke det samme knudepunktsomr\u00e5de, ellers opst\u00e5r der uundg\u00e5eligt fejl. Jeg sikrer, at pods med faste CPU-anmodninger ikke str\u00e6kker sig over flere NUMA-knudepunkter, og at scheduleren ikke fordeler arbejdsprocesser fra samme applikation p\u00e5 tv\u00e6rs af knudepunkterne. For burst-typer begr\u00e6nser jeg det maksimale antal tr\u00e5de pr. pod, s\u00e5 de forbliver inden for \u00e9n node. Jeg dokumenterer <strong>NUMA-dom\u00e6ne<\/strong> pr. deployment og kr\u00e6ver konsistente replikaer (\u00e9n worker-gruppe pr. node, ikke halve grupper fordelt p\u00e5 to noder). Hvis jeg beregner lagerpladsen pr. pod for stramt, skaber jeg u\u00f8nsket pres: Et lille overskud pr. node forhindrer, at kernen for tidligt m\u00e5 udl\u00e6gge opgaver til andre noder. Hvis containere genstartes ofte, s\u00f8rger jeg for deterministisk binding, s\u00e5 <strong>Kolde starter<\/strong> ikke tilf\u00e6ldigt f\u00e5 en d\u00e5rligere placering.<\/p>\n\n<h2>Justere virtuelle maskiner og vNUMA, s\u00e5 de er konsistente<\/h2>\n\n<p>N\u00e5r det g\u00e6lder VM\u2019er, retter jeg min opm\u00e6rksomhed mod <strong>vNUMA<\/strong>: Den virtuelle topologi skal stemme overens med den fysiske. Jeg fordeler vCPU'er s\u00e5ledes, at hver vNUMA-node ender p\u00e5 n\u00f8jagtigt \u00e9n fysisk NUMA-node. P\u00e5 v\u00e6rtsiden binder jeg QEMU\/hypervisor-tr\u00e5dene til dette dom\u00e6ne og sikrer, at den tildelte RAM udelukkende leveres fra denne node. <strong>Ballonflyvning<\/strong> og jeg accepterer kun overcommit med forsigtighed for VM\u2019er, hvor latenstiden er kritisk; aggressivt ballooning kan skubbe hotsets ud af knuden og \u00f8ge antallet af fjernadgange. Ved live-migration verificerer jeg tilknytningerne igen efter flytningen \u2013 nogle milj\u00f8er mister nemlig de pr\u00e6cist indstillede CPU- og hukommelsestilknytninger i den forbindelse. F\u00f8rst n\u00e5r vNUMA-tilpasningen er i orden, vurderer jeg numastat p\u00e5 systemniveau: Ellers reparerer jeg symptomerne, ikke \u00e5rsagen.<\/p>\n\n<h2>THP, Hugepages og sidemigrering<\/h2>\n\n<p><strong>Gennemsigtige store sider<\/strong> (THP) kan b\u00e5de v\u00e6re til hj\u00e6lp og til hinder. St\u00f8rre sider reducerer TLB-fejl og forbedrer b\u00e5ndbredden, men hvis kernen f\u00f8rst indf\u00f8rer Hugepages sent <em>kollapset<\/em> eller migreres, kan uegnede <strong>Afstande<\/strong> opst\u00e5r. Jeg f\u00f8lger to regler: For det f\u00f8rste, at <strong>Politik<\/strong> Definere klart (f.eks. foretrukken node) og tildele s\u00e5 store lokale ressourcer som muligt lige fra starten. For det andet: Ved arbejdsbelastninger med faste, store cacher indstiller jeg, hvis muligt, statiske hugepages (hugetlb), som jeg eksplicit reserverer p\u00e5 en node. Dette mindsker fragmentering og kompensationsbetingede omdirigeringer. Hvis jeg i tidsserier ser, at efter l\u00e6ngere k\u00f8rselstid <em>other_node<\/em>\u2011Andelen stiger, s\u00e5 unders\u00f8ger jeg, om <strong>Sidemigrering<\/strong> eller om der sker komprimering, og om THP-indstillingerne passer til m\u00f8nsteret. Det er vigtigt for mig, at jeg ikke sl\u00e5r det fra eller til generelt \u2013 jeg tr\u00e6ffer beslutningen for hver enkelt tjeneste og m\u00e5ler effekten p\u00e5 lokalitet og latenstid.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/linux-numa-analyse-4746.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>S\u00e5dan l\u00e6ser du \u00bbReclaim\u00ab, \u00bbSwap\u00ab og \u00bbMemory\u2011Pressure\u00ab korrekt<\/h2>\n\n<p>Hvis der er stigninger uden nogen \u00e5benbar \u00e6ndring i placeringen, leder jeg efter <strong>hukommelsestryk<\/strong> pr. knude. Fyldte knuder tvinger kernen til at genvinde plads og komprimere, delvist udl\u00f8st af <em>kswapd<\/em> p\u00e5 en anden node \u2013 det medf\u00f8rer sideeffekter p\u00e5 t\u00e6llerne. Jeg tjekker den ledige hukommelse og udnyttelsen af side-cachen for hver node. Aktiveret <strong>Bytte<\/strong> kan fortr\u00e6nge hotsets og f\u00e5 ventetiderne til at skyde i vejret; for s\u00e6rligt f\u00f8lsomme tjenester deaktiverer jeg swap eller begr\u00e6nser den strengt. I logfiler og perf-oversigter leder jeg efter Reclaim-toppe under belastningstoppe. M\u00e5let er at have nok ledig, <strong>lokale<\/strong> At opretholde RAM p\u00e5 m\u00e5lknudepunktet, s\u00e5 allokeringerne ikke glider v\u00e6k. Hvis det kr\u00e6ver, at cacherne reduceres, prioriterer jeg tjenestens arbejdss\u00e6t frem for den generiske side-cache.<\/p>\n\n<h2>Praktiske kommandoer og analyse<\/h2>\n\n<p>Til procesoversigten bruger jeg <code>numastat -p<\/code> og tilf\u00f8jer <code>cat \/proc\/\/numa_maps<\/code>, for at se tildelinger pr. omr\u00e5de (anonymt, filbaseret) og pr. node. <code>numactl --hardware<\/code> giver mig latensmatricer og knudest\u00f8rrelser, <code>lscpu --extended<\/code> viser CPU-tildelingen til noder. Ved hukommelsesadgange med fokus p\u00e5 fjerne stier indstiller jeg <code>perf mem<\/code> for at verificere belastningsm\u00f8nstre. Jeg indsamler deltaer p\u00e5 en reproducerbar m\u00e5de, f.eks.:<\/p>\n\n<p><em>M\u00e5lerutine<\/em><\/p>\n<ul>\n  <li>t0: Sikkerhedskopiere numastat (alt) og numastat -p for de \u00f8verste PID\u2019er<\/li>\n  <li>30\u201360 sekunder med belastning, identisk tr\u00e6ningsfase<\/li>\n  <li>t1: L\u00e6s numastat igen, beregn deltaer pr. t\u00e6ller<\/li>\n  <li>Logning af parallelle CPU-, kontekstskifte- og knudepunktshukommelsesv\u00e6rdier<\/li>\n<\/ul>\n\n<p>Derefter beregner jeg <strong>Odds<\/strong> og markerer, hvilke processer der afviger markant fra de systemomfattende tendenser. Hvis der stadig er usikkerhed, gentager jeg m\u00e5lingen mindst tre gange. F\u00f8rst n\u00e5r der er tale om konsistente afvigelser, betragter jeg dem som p\u00e5lidelige. Til l\u00f8bende overv\u00e5gning kortl\u00e6gger jeg t\u00e6llerne i tidsserier og knytter dem til release-metadata \u2013 p\u00e5 den m\u00e5de kan jeg identificere <strong>Regressionspunkter<\/strong> med det samme.<\/p>\n\n<h2>Tjekliste til struktureret NUMA-optimering<\/h2>\n\n<ul>\n  <li>Definere m\u00e5let: Latens vs. gennemstr\u00f8mning, fast belastning vs. variabel<\/li>\n  <li>Registrering af topologi: knudepunkter, latenstider, ledige RAM-reserver pr. knudepunkt<\/li>\n  <li>M\u00e5ling af udgangsv\u00e6rdier: samlet numastat og pr. proces, udledning af andele<\/li>\n  <li>Korrektion af placering: CPU-affinitet, hukommelsesbinding, politikker<\/li>\n  <li>Konfigurer containere\/VM\u2019er: cpuset.cpus = knudepunkter, cpuset.mems tilpasset; kortl\u00e6g vNUMA korrekt<\/li>\n  <li>V\u00e6lg THP\/Hugepages med omhu, hold \u00f8je med fragmentering<\/li>\n  <li>Reducer hukommelsesbelastningen: Headroom pr. node, kontroller swap-strategi<\/li>\n  <li>Efterm\u00e5ling: Sammenligning af deltaer, sikring af stabilitet over tid<\/li>\n  <li>Dokumentation: Bindinger som kode, udgivelsesnoter med NUMA-kontekst<\/li>\n<\/ul>\n\n<h2>Kort opsummeret<\/h2>\n\n<p>Jeg analyserer NUMA-tal ved at <strong>Signaler<\/strong> I denne sammenh\u00e6ng skal man l\u00e6se: t\u00e6llerpar, tidsforl\u00f8b og procesvisning. N\u00f8glev\u00e6rdierne numa_hit, numa_miss, numa_foreign, local_node, other_node og interleave_hit viser mig lokalitet, omdirigeringer og fordelingsstrategier. Jeg tr\u00e6ffer beslutninger p\u00e5 baggrund af topologien og arbejdsbelastningen, ikke ud fra faste gr\u00e6nsev\u00e6rdier. Tuning begynder med placering, affinitet, passende politik og en velfungerende m\u00e5lerutine. P\u00e5 den m\u00e5de leverer jeg konstante <strong>Ydelse<\/strong>, fordi CPU og RAM passer til applikationen, og der sj\u00e6ldent er lange overf\u00f8rsler.<\/p>","protected":false},"excerpt":{"rendered":"<p>S\u00e5dan analyseres Linux NUMA-statistikker korrekt: Forst\u00e5 NUMA-statistikker, kontroller hukommelseslokalitet og forbedr serverens ydeevne m\u00e5lrettet.<\/p>","protected":false},"author":1,"featured_media":21436,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[676],"tags":[],"class_list":["post-21443","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-server_vm"],"acf":[],"_wp_attached_file":null,"_wp_attachment_metadata":null,"litespeed-optimize-size":null,"litespeed-optimize-set":null,"_elementor_source_image_hash":null,"_wp_attachment_image_alt":null,"stockpack_author_name":null,"stockpack_author_url":null,"stockpack_provider":null,"stockpack_image_url":null,"stockpack_license":null,"stockpack_license_url":null,"stockpack_modification":null,"color":null,"original_id":null,"original_url":null,"original_link":null,"unsplash_location":null,"unsplash_sponsor":null,"unsplash_exif":null,"unsplash_attachment_metadata":null,"_elementor_is_screenshot":null,"surfer_file_name":null,"surfer_file_original_url":null,"envato_tk_source_kit":null,"envato_tk_source_index":null,"envato_tk_manifest":null,"envato_tk_folder_name":null,"envato_tk_builder":null,"envato_elements_download_event":null,"_menu_item_type":null,"_menu_item_menu_item_parent":null,"_menu_item_object_id":null,"_menu_item_object":null,"_menu_item_target":null,"_menu_item_classes":null,"_menu_item_xfn":null,"_menu_item_url":null,"_trp_menu_languages":null,"rank_math_primary_category":null,"rank_math_title":null,"inline_featured_image":null,"_yoast_wpseo_primary_category":null,"rank_math_schema_blogposting":null,"rank_math_schema_videoobject":null,"_oembed_049c719bc4a9f89deaead66a7da9fddc":null,"_oembed_time_049c719bc4a9f89deaead66a7da9fddc":null,"_yoast_wpseo_focuskw":null,"_yoast_wpseo_linkdex":null,"_oembed_27e3473bf8bec795fbeb3a9d38489348":null,"_oembed_c3b0f6959478faf92a1f343d8f96b19e":null,"_trp_translated_slug_en_us":null,"_wp_desired_post_slug":null,"_yoast_wpseo_title":null,"tldname":null,"tldpreis":null,"tldrubrik":null,"tldpolicylink":null,"tldsize":null,"tldregistrierungsdauer":null,"tldtransfer":null,"tldwhoisprivacy":null,"tldregistrarchange":null,"tldregistrantchange":null,"tldwhoisupdate":null,"tldnameserverupdate":null,"tlddeletesofort":null,"tlddeleteexpire":null,"tldumlaute":null,"tldrestore":null,"tldsubcategory":null,"tldbildname":null,"tldbildurl":null,"tldclean":null,"tldcategory":null,"tldpolicy":null,"tldbesonderheiten":null,"tld_bedeutung":null,"_oembed_d167040d816d8f94c072940c8009f5f8":null,"_oembed_b0a0fa59ef14f8870da2c63f2027d064":null,"_oembed_4792fa4dfb2a8f09ab950a73b7f313ba":null,"_oembed_33ceb1fe54a8ab775d9410abf699878d":null,"_oembed_fd7014d14d919b45ec004937c0db9335":null,"_oembed_21a029d076783ec3e8042698c351bd7e":null,"_oembed_be5ea8a0c7b18e658f08cc571a909452":null,"_oembed_a9ca7a298b19f9b48ec5914e010294d2":null,"_oembed_f8db6b27d08a2bb1f920e7647808899a":null,"_oembed_168ebde5096e77d8a89326519af9e022":null,"_oembed_cdb76f1b345b42743edfe25481b6f98f":null,"_oembed_87b0613611ae54e86e8864265404b0a1":null,"_oembed_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_oembed_time_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_tldname":null,"_tldclean":null,"_tldpreis":null,"_tldcategory":null,"_tldsubcategory":null,"_tldpolicy":null,"_tldpolicylink":null,"_tldsize":null,"_tldregistrierungsdauer":null,"_tldtransfer":null,"_tldwhoisprivacy":null,"_tldregistrarchange":null,"_tldregistrantchange":null,"_tldwhoisupdate":null,"_tldnameserverupdate":null,"_tlddeletesofort":null,"_tlddeleteexpire":null,"_tldumlaute":null,"_tldrestore":null,"_tldbildname":null,"_tldbildurl":null,"_tld_bedeutung":null,"_tldbesonderheiten":null,"_oembed_ad96e4112edb9f8ffa35731d4098bc6b":null,"_oembed_8357e2b8a2575c74ed5978f262a10126":null,"_oembed_3d5fea5103dd0d22ec5d6a33eff7f863":null,"_eael_widget_elements":null,"_oembed_0d8a206f09633e3d62b95a15a4dd0487":null,"_oembed_time_0d8a206f09633e3d62b95a15a4dd0487":null,"_aioseo_description":null,"_eb_attr":null,"_eb_data_table":null,"_oembed_819a879e7da16dd629cfd15a97334c8a":null,"_oembed_time_819a879e7da16dd629cfd15a97334c8a":null,"_acf_changed":null,"_wpcode_auto_insert":null,"_edit_last":null,"_edit_lock":null,"_oembed_e7b913c6c84084ed9702cb4feb012ddd":null,"_oembed_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_time_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_03514b67990db061d7c4672de26dc514":null,"_oembed_time_03514b67990db061d7c4672de26dc514":null,"rank_math_news_sitemap_robots":null,"rank_math_robots":null,"_eael_post_view_count":"72","_trp_automatically_translated_slug_ru_ru":null,"_trp_automatically_translated_slug_et":null,"_trp_automatically_translated_slug_lv":null,"_trp_automatically_translated_slug_fr_fr":null,"_trp_automatically_translated_slug_en_us":null,"_wp_old_slug":null,"_trp_automatically_translated_slug_da_dk":null,"_trp_automatically_translated_slug_pl_pl":null,"_trp_automatically_translated_slug_es_es":null,"_trp_automatically_translated_slug_hu_hu":null,"_trp_automatically_translated_slug_fi":null,"_trp_automatically_translated_slug_ja":null,"_trp_automatically_translated_slug_lt_lt":null,"_elementor_edit_mode":null,"_elementor_template_type":null,"_elementor_version":null,"_elementor_pro_version":null,"_wp_page_template":null,"_elementor_page_settings":null,"_elementor_data":null,"_elementor_css":null,"_elementor_conditions":null,"_happyaddons_elements_cache":null,"_oembed_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_time_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_time_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_59808117857ddf57e478a31d79f76e4d":null,"_oembed_time_59808117857ddf57e478a31d79f76e4d":null,"_oembed_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_time_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_81002f7ee3604f645db4ebcfd1912acf":null,"_oembed_time_81002f7ee3604f645db4ebcfd1912acf":null,"_elementor_screenshot":null,"_oembed_7ea3429961cf98fa85da9747683af827":null,"_oembed_time_7ea3429961cf98fa85da9747683af827":null,"_elementor_controls_usage":null,"_elementor_page_assets":[],"_elementor_screenshot_failed":null,"theplus_transient_widgets":null,"_eael_custom_js":null,"_wp_old_date":null,"_trp_automatically_translated_slug_it_it":null,"_trp_automatically_translated_slug_pt_pt":null,"_trp_automatically_translated_slug_zh_cn":null,"_trp_automatically_translated_slug_nl_nl":null,"_trp_automatically_translated_slug_pt_br":null,"_trp_automatically_translated_slug_sv_se":null,"rank_math_analytic_object_id":null,"rank_math_internal_links_processed":"1","_trp_automatically_translated_slug_ro_ro":null,"_trp_automatically_translated_slug_sk_sk":null,"_trp_automatically_translated_slug_bg_bg":null,"_trp_automatically_translated_slug_sl_si":null,"litespeed_vpi_list":null,"litespeed_vpi_list_mobile":null,"rank_math_seo_score":null,"rank_math_contentai_score":null,"ilj_limitincominglinks":null,"ilj_maxincominglinks":null,"ilj_limitoutgoinglinks":null,"ilj_maxoutgoinglinks":null,"ilj_limitlinksperparagraph":null,"ilj_linksperparagraph":null,"ilj_blacklistdefinition":null,"ilj_linkdefinition":null,"_eb_reusable_block_ids":null,"rank_math_focus_keyword":"Linux NUMA","rank_math_og_content_image":null,"_yoast_wpseo_metadesc":null,"_yoast_wpseo_content_score":null,"_yoast_wpseo_focuskeywords":null,"_yoast_wpseo_keywordsynonyms":null,"_yoast_wpseo_estimated-reading-time-minutes":null,"rank_math_description":null,"surfer_last_post_update":null,"surfer_last_post_update_direction":null,"surfer_keywords":null,"surfer_location":null,"surfer_draft_id":null,"surfer_permalink_hash":null,"surfer_scrape_ready":null,"_thumbnail_id":"21436","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/posts\/21443","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=21443"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/posts\/21443\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/media\/21436"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/media?parent=21443"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/categories?post=21443"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/tags?post=21443"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}