Server og virtuelle maskiner

NUMA-balanceringsserver: Optimering af hukommelsesadgang til hosting-hardware

Jeg viser, hvordan NUMA-balanceringsserver på hosting-hardware strømliner hukommelsesadgangen og reducerer ventetiden ved at binde processer og data til den relevante NUMA-node. Den afgørende faktor er Optimering af hukommelsesadgang gennem lokal adgang, opgaveplacering og målrettet sidemigration til Linux-værter med mange kerner.

Centrale punkter

NUMA adskiller CPU'er og hukommelse i noder; lokale adgange giver lav Latenstid.
Automatisk NUMA-balancering migrerer sider og placerer opgaver tæt på knudepunktet.
VM-størrelse pr. node, ellers er der risiko for NUMA-nedbrydning.
Værktøjer som numactl, lscpu, numad show Topologi og anvendelse.
IndstillingC-states, node-interleaving fra, Store sider, affiniteter.

Hvad NUMA er - og hvorfor det er vigtigt for hosting

NUMA opdeler et multiprocessorsystem i Knudepunkt, som hver især indeholder deres egne CPU'er og lokal hukommelse, hvilket gør adgang i nærheden hurtigere end fjernadgang. Mens UMA sender alle kerner til en fælles sti, forhindrer NUMA flaskehalse på grund af lokal hukommelseskanaler pr. node. I hostingmiljøer med mange parallelle VM'er løber hvert millisekund af latenstid op, så hver eneste anmodning giver målbare fordele. Hvis du gerne vil have mere baggrundsinformation, kan du læse mere om NUMA-arkitektur. For mig er én ting sikker: Hvis du forstår og bruger noder, får du mere båndbredde ud af den samme hardware.

Automatisk NUMA-balancering i Linux-kernen - sådan fungerer det

Kernen scanner med jævne mellemrum dele af adresserummet og „unmaps“ sider, så en hinting-fejl kan opstå. optimal node synlig. Hvis fejlen opstår, vurderer algoritmen, om det er værd at migrere siden eller flytte opgaven og undgår unødvendige bevægelser. Migrering ved fejl bringer Data tættere på den udførende CPU, flytter NUMA-placering af opgaver processer tættere på deres hukommelse. Scanneren fordeler sit arbejde stykke for stykke, så overhead forbliver inden for den normale belastnings støj. Dette resulterer i løbende finjustering, der reducerer latenstiden uden at kræve hårde pinning-regler.

Optimering af hukommelsesadgang: lokal beats remote

Lokale adgange bruger Hukommelsescontroller af din egen node og minimere ventetiden på interconnect. Fjernadgang koster cyklusser via QPI/UPI eller Infinity Fabric og minimerer dermed den effektive adgangstid. Båndbredde. Et højt antal kerner forværrer denne effekt, fordi flere og flere kerner konkurrerer om de samme forbindelser. Jeg planlægger derfor, at varm kode og aktive data samles på én node. Hvis man ser bort fra dette, giver man procentpoint væk, som bestemmer svartid eller timeout under spidsbelastninger.

VM-størrelser, NUMA trashing og host cropping

Jeg dimensionerer VM'er, så vCPU'er og RAM passer ind i en NUMA-node for at undgå adgang på tværs af noder. Ofte giver 4-8 vCPU'er pr. node god performance. Antal hits, afhængigt af platformen og cache-hierarkiet. Store sider hjælper også, fordi TLB'en arbejder mere effektivt, og sideflytninger sker mindre hyppigt. Hvis det er nødvendigt, sætter jeg CPU-affinitet til latency-kritiske processer for at binde tråde til passende kerner - for mere information se CPU-affinitet. Hvis du spreder VM'er på tværs af noder, risikerer du NUMA trashing, dvs. en ping-pong af data og tråde.

Værktøjer i praksis: numactl, lscpu, numad

Med „lscpu“ læser jeg Topologi og NUMA-noder, herunder tildeling af kerner. „numactl -hardware“ viser mig hukommelse pr. node og tilgængelige afstande, hvilket gør det nemmere at evaluere stierne. Dæmonen „numad“ overvåger udnyttelsen og justerer dynamisk affiniteterne, når belastningscentrene flytter sig. Til faste scenarier bruger jeg „numactl -cpunodebind/-membind“ til eksplicit at fastgøre processer og hukommelse. På den måde kombinerer jeg automatisk afbalancering med målrettede specifikationer og kontrollerer resultatet via „perf“, „numastat“ og „/proc“.

Hvordan jeg måler effekt: Nøgletal og kommandoer

Jeg vurderer altid NUMA-Tuning via Måleserier, ikke efter mavefornemmelse. Tre indikatorer har vist deres værd: Forholdet mellem lokale og eksterne sidevisninger, migrationsrate og latenstidsfordeling (P95/P99).

Systemomfattendenumastat„ viser lokale/fjerne adgange og migrerede sider pr. node.
Procesrelateret: „/proc//numa_maps“ afslører, hvor hukommelsen er placeret, og hvordan den blev fordelt.
PlanlægningsvisningCpus_allowed_list„ og real “Cpus_allowed„ tjekker, om bindingerne gælder.

# System-wide view
numastat
numastat -m

# Procesrelateret distribution og bindinger
pid=$(pidof )
numastat -p "$pid"
cat /proc/"$pid"/numa_maps | head
cat /proc/"$pid"/status | grep -E 'Cpus_allowed_list|Mems_allowed_list'
taskset -cp "$pid"

# Kernel-tæller for NUMA-aktivitet
grep -E 'numa|migrate' /proc/vmstat

# Sporingshændelser til dybe analyser (aktiveres i kort tid)
echo 1 > /sys/kernel/debug/tracing/events/mm/enable
sleep 5; cat /sys/kernel/debug/tracing/trace | grep -i numa; echo 0 > /sys/kernel/debug/tracing/events/mm/enable

Jeg sammenligner i hvert tilfælde A/B: unbound vs. bound, automatisk balancering on/off og forskellige VM slices. Målet er en klar reduktion i fjernadgang og migrationsstøj samt strammere P95/P99-latenstider. Først når de målte værdier er stabilt bedre, vil jeg overtage tuningen.

BIOS- og firmwareindstillinger, der virkelig virker

Jeg slår „Node Interleaving“ fra i BIOS, så NUMA-strukturen forbliver synlig, og kernen lokal kan planlægge. Reducerede C-states stabiliserer latenstidstoppe, fordi kernerne er mindre tilbøjelige til at falde i dyb søvn, hvilket sparer opvågningstid. Jeg tildeler hukommelseskanaler symmetrisk, så hver node kan udnytte sin maksimale hukommelseskapacitet. Båndbredde opnået. Jeg tester prefetchers og RAS-funktioner med arbejdsbelastningsprofiler, da de hjælper eller skader afhængigt af adgangsmønsteret. Jeg måler hver ændring i forhold til en baseline, og først derefter indfører jeg indstillingen permanent.

Kernel- og sysctl-parametre, der gør forskellen

Finjustering af kernen hjælper mig, Overhead og Svartid af balanceren, så den matcher arbejdsbyrden. Jeg starter med konservative standardindstillinger og arbejder mig fremad trin for trin.

kernel.numa_balancingTil/fra for automatisk afbalancering. Jeg lader den være slået til ved bevægelige laster; jeg slår den fra ved strengt fastgjorte specialtjenester som en test.
kernel.numa_balancing_scan_delay_msVentetid før den første scanning efter procesoprettelse. Vælg større, hvis der kører mange kortvarige opgaver; mindre for langvarige tjenester, der kræver hurtig nærhed.
kernel.numa_balancing_scan_period_min_ms / _max_msBåndbredden på scanningsintervallerne. Smalle intervaller øger reaktionsevnen, men også CPU-belastningen.
kernel.numa_balancing_scan_size_mbAndel af adresserummet pr. scanning. For stor genererer hint-fejlstorme, for lille reagerer trægt.
vm.zone_reclaim_mode: Når der er knaphed på hukommelse, foretrækker kernen lokal reclaim frem for fjernallokering. Til generelle hosting-arbejdsbelastninger lader jeg normalt 0; Til meget forsinkelsesfølsomme, lokale hukommelsestjenester tester jeg omhyggeligt højere værdier.
Gennemsigtige store sider (THP): Under „/sys/kernel/mm/transparent_hugepage/{enabled,defrag}“ sætter jeg normalt til madvise og konservativ defragmentering. Hårde „altid“-profiler giver TLB-fordele, men risikerer at gå i stå på grund af komprimering.
sched_migration_cost_ns: Omkostningsestimat for opgavemigration. Højere værdier dæmper omfordelingen af aggressive planlæggere.
cgroups cpusetMed cpuset.cpus og cpuset.mems Jeg adskiller tjenester rent efter node og sørger for, at Første berøring forbliver inden for tilladte noder.

# Eksempel: konservativ, men responsiv balancering
sysctl -w kernel.numa_balancing=1
sysctl -w kernel.numa_balancing_scan_delay_ms=30000
sysctl -w kernel.numa_balancing_scan_period_min_ms=60000
sysctl -w kernel.numa_balancing_scan_period_max_ms=300000
sysctl -w kernel.numa_balancing_scan_size_mb=256

# Brug THP omhyggeligt
echo madvise > /sys/kernel/mm/transparent_hugepage/enabled
echo defer > /sys/kernel/mm/transparent_hugepage/defrag

Det er stadig vigtigt: Skift kun én justeringsskrue pr. testrunde, og test effekten i forhold til den samme belastningskurve. Det er sådan, jeg adskiller årsag og virkning.

Placer arbejdsbelastninger korrekt: Databaser, cacher, containere

Databaser nyder godt af, at bufferpuljer forbliver lokale pr. NUMA-node, og at tråde er bundet tæt på deres heaps. I in-memory caches sætter jeg sharding til Knudepunkt for at undgå fjernhentninger. Containerplatforme modtager limits og anmodninger, så pods ikke hopper på tværs af noder. Til hukommelsesreservationer bruger jeg Huge Pages, som gør det nemmere at gemme hotsets i Cacher passer. Følgende tabel opsummerer strategier og typiske effekter i kompakt form.

Strategi	Brug	Forventet effekt	Hint
Første berøring	Databaser, JVM-heaps	Tildeling af lokal side	Udfør initialisering på målknudepunkt
Interleave	Bredt fordelt belastning	Jævn fordeling	Ikke optimal til hotspots
Fastgørelse af opgaver	Latency-kritiske tjenester	Konstant latenstid	Mindre fleksibel under belastningsændringer
Automatisk afbalancering	Blandede arbejdsbelastninger	Dynamisk nærhed	Afvejning af faste omkostninger mod fortjeneste
Store sider	Store heaps, caches	Færre TLB-misses	Planlæg rene reservationer

Virtualisering: Virtuel NUMA, scheduler og gæstetilpasning

Virtual NUMA sender værtstopologien til gæsteoperativsystemet i en forenklet form, så første berøring og Allocator arbejde fornuftigt. Hypervisor-planlæggere er opmærksomme på node-nærhed, når de fordeler vCPU'er og migrerer VM'er. Jeg placerer sjældent store VM'er på tværs af flere noder, medmindre arbejdsbyrden spreder sig meget og drager fordel af interleave. I gæsten tilpasser jeg JVM'ernes eller databasernes heaps, så de forbliver lokale på synlige NUMA-noder. For hukommelsesstyring i gæsten kan man se på Virtuel hukommelse, for at tæmme sidestørrelser og swapping.

PCIe-nærhed: NVMe og NIC'er på de rigtige knudepunkter

Hvis det er muligt, tildeler jeg NVMe SSD'er og hurtige NIC'er til den node, hvor Arbejdsbyrde kører. Det forhindrer I/O-anmodninger i at krydse interconnect og øge ventetiden. Jeg binder multikø-NIC'er til kernesæt i en node med RSS/RPS, så IRQ'erne forbliver lokale. For storage stacks er det værd at opdele trådpuljerne node for node. Hvis du er opmærksom på dette, vil du mærkbart reducere P99-latency og skabe plads til belastningstoppe.

IRQ og kø-affinitet i praksis

Jeg tjekker først, hvilken NUMA-node enheder og pin-IRQ'er og køer på passende vis. Dette sikrer, at datastiens lokalitet opretholdes.

#-enhed-til-node-kortlægning
cat /sys/class/net/eth0/device/numa_node
cat /sys/block/nvme0n1/device/numa_node

# Indstil IRQ-affinitet specifikt (eksempel: kerner 0-7 i en node)
irq=
echo 0-7 > /proc/irq/$irq/smp_affinity_list

# Bind NIC-køer til kerner (RPS/RFS)
for q in /sys/class/net/eth0/queues/rx-*; do echo 0-7 > "$q"/rps_cpus; done
sysctl -w net.core.rps_sock_flow_entries=32768
for q in /sys/class/net/eth0/queues/rx-*; do echo 4096 > "$q"/rps_flow_cnt; done

# Forbedre NVMe-køaffinitet
echo 2 > /sys/block/nvme0n1/queue/rq_affinity
cat /sys/block/nvme0n1/queue/scheduler # "none" preferred

„Jeg kører “irqbalance" med node awareness eller sætter den til Undtagelser til hot-path afbrydelser. Resultatet er mere stabile ventetider, færre IRQ-hop på tværs af noder og en målbar stigning i lokale I/O-hits.

Statisk binding vs. dynamisk afbalancering - den gyldne middelvej

Jeg bruger „taskset“ og cgroups til at sætte hårde regler, når det er deterministisk Forsinkelse tæller. Jeg lader automatisk NUMA-balancering være aktiv, når belastningen flytter sig, og jeg har brug for adaptiv nærhed. En blanding fungerer ofte bedst: hårde stifter til hotpaths, mere åbne grænser til hjælpearbejde. Jeg tjekker regelmæssigt, om migreringerne stiger mærkbart, da det er tegn på dårlig planlægning. Målet er fortsat at vælge data- og trådplaceringer på en sådan måde, at migrering forbliver sjælden, men mulig.

NUMA i containere og Kubernetes

Jeg medbringer en beholder cpusets og Store sider på linje. Jeg tildeler pods/containere til en NUMA-node ved at gemme konsistente CPU- og hukommelsesmængder. I orkestreringer indstiller jeg politikker, der favoriserer enkeltnode-tildelinger og dermed respekterer first touch.

Container-kørselstid: „-cpuset-cpus“ og „-cpuset-mems“ holder opgaver og hukommelse sammen; tildeler store sider som ressourcer.
Topologi/CPU ManagerStrenge eller foretrukne tildelinger sikrer, at relaterede kerner og hukommelsesområder tildeles.
Garanteret QoSFaste anmodninger/grænser minimerer planlæggerens omfordeling.

Jeg opdeler bevidst sidevogne og hjælpeprocesser til andre kerner inden for af den samme node, så hotpath forbliver uforstyrret, men ikke kommer ind i cross-node race.

Forståelse af CPU-topologier: CCD/CCX, SNC og Cluster-on-Die

Nuværende server-CPU'er opdeler sokler i Underdomæner med sine egne cacher og stier. Det tager jeg hensyn til, når jeg skærer i kerner/heaps:

AMD EPYCCCD/CCX og „NUMA per socket“ (NPS=1/2/4) har indflydelse på, hvor fint NUMA er skåret. Flere noder (NPS=4) øger lokaliteten, men kræver ren pinning.
IntelSub-NUMA Clustering (SNC2/4) opdeler LLC i klynger. God til hukommelsesbundne belastninger, forudsat at operativsystemet og arbejdsbelastningen er node-aware.
L3-nærhedJeg binder tråde, der bruger de samme heaps, til den samme L3-klynge for at spare kohærens-trafik og hops på tværs af klynger.

Disse muligheder fungerer som en multiplikator: Hvis de bruges korrekt, øger de Lokalitet Desuden øger de - forkert konfigureret - fragmentering og fjerntrafik.

Trin-for-trin introduktion og rollback-plan

Jeg introducerer aldrig „big bang“ NUMA-tuning. En spændstig Planlæg undgår overraskelser:

BaselineHardwaretopologi, P50/P95/P99-latency, throughput, numastat rate capture.
HypoteseFormuler et specifikt mål (f.eks. fjernadgang -30%, P99 -20%).
Et skridtSkift kun én justeringsskrue (f.eks. VM cut, cpuset, THP-politik, scanningsintervaller).
KanariefuglTest på 5-10% af flåden under reel belastning, hold rollback klar.
VærdiansættelseSammenlign målte værdier, definer regressionsvinduer, log bivirkninger.
UdrulningRul ud skaft for skaft, og mål igen efter hvert skaft.
VedligeholdelseMål igen hvert kvartal (kerne-, firmware- og arbejdsbelastningsopdateringer ændrer det optimale).

Det sikrer, at forbedringer er reproducerbare og kan vendes på få minutter i tilfælde af en fejl.

Almindelige fejl - og hvordan du undgår dem

Et typisk fejltrin er at aktivere node interleaving i BIOS, hvilket skjuler NUMA-topologien og Afbalancering sværere. Lige så ugunstigt: VM'er med flere vCPU'er, end en node tilbyder, plus urent reserverede store sider. Nogle administratorer sætter alt på spidsen og mister dermed al fleksibilitet, når arbejdsbyrden skifter. Andre stoler helt på kernen, selvom hårde hotspots kræver klare regler. Jeg registrerer måleserier, genkender afvigelser tidligt og justerer opsætningen og politikkerne trin for trin.

THP „altid“ uden kontrol: Uplanlagt komprimering forstyrrer ventetiden. Jeg foretrækker at bruge „madvise“ og reservere store sider specifikt.
vm.zone_reclaim_mode for aggressiv: Lokal genanvendelse kan gøre mere skade end gavn på det forkerte tidspunkt. Mål først, skærp derefter.
irqbalance blindUkritiske IRQ'er flyttes på tværs af noder. Jeg indstiller undtagelser eller faste masker for hotpaths.
Blanding af interleave + hard pinningModstridende politikker skaber ping-pong. Jeg går ind for en klar linje for hver tjeneste.
Urene cpusetsContainere ser en node, men mapper hukommelsen til andre noder. Indstil altid „cpuset.mems“ i overensstemmelse med CPU-sættet.
Sub-NUMA-funktioner aktiveret, men ikke brugt: Flere noder uden planlægning øger fragmenteringen. Tænd kun efter test.

Kort opsummeret

NUMA Balancing Server bringer processer og data sammen på en målrettet måde, hvilket gør lokale adgange hyppigere og mere effektive. Forsinkelser bliver kortere. Med en passende VM-størrelse, ren BIOS-konfiguration og værktøjer som numactl skabes der en klar topologi, som kernen udnytter. Virtuel NUMA, store sider og affiniteter supplerer den automatiske afbalancering i stedet for at erstatte den. Tilslutning af I/O-enheder tæt på noder og brug af hotpaths eliminerer dyr fjernadgang. På denne måde skaleres hosting-hardware pålideligt, og hvert CPU-sekund giver mere nyttelast.