Hoppa till innehåll 
NUMA-balanseringen i Linux avgör om Kärnan Om minnesåtkomst automatiskt lokaliseras eller om jag själv styr placeringen på ett målinriktat sätt. I den här guiden visar jag när jag låter numa-balanseringen vara aktiv och när jag stänger av den för Fördröjning-Stäng av säkerhetsfunktionen.
Centrala punkter
- Automatisk hjälper vid blandade arbetsbelastningar utan NUMA-optimering.
- Inaktivera vid pinning, statiska policyer eller hög latens.
- Overhead uppstår till följd av skanningar, fel och migreringar.
- Konfiguration styra via sysctl eller startparametrar.
- Testning och mäta istället för att gissa, och sedan fatta ett beslut.
NUMA i korthet: Latenser och lokalitet
I NUMA-system fördelar hårdvaran minnet på flera noder, där de enskilda Processorer ligger nära varandra. Lokala åtkomstförfrågningar tar mindre tid än avlägsna, vilket jag omedelbart märker på Fördröjning och bandbredd. Om en process körs på en nod men data finns på en annan, förlorar jag värdefulla mikrosekunder vid varje åtkomst. Det är just här som kärnan träder in och optimerar Plats sidor. Den som förstår grundidén inser snabbt att närhet mellan processorkärnor och data är den direktaste vägen till konstant Prestanda.
Hur automatisk NUMA-balansering fungerar
Kärnan övervakar från vilka kärnor en process når sidor och utlöser målinriktat Hint-Faults. På så sätt kan den identifiera vilken nod som har flest åtkomstförfrågningar och därefter flytta relevanta sidor dit. Dessa migreringar minskar antalet åtkomstförfrågningar från avlägsna platser och ökar den lokala Träfffrekvens. Jag märker effekten särskilt vid dynamiska arbetsbelastningar, där trådar flyttar sig och minnet förflyttas. Den som vill fördjupa sig kan undersöka sambanden mellan CPU- och minnesnärhet via CPU-/minnesaffinitet förstå i praktiken.
När ska man låta det vara aktivt: typiska arbetsbelastningar
Jag låter funktionen vara aktiverad om applikationer inte har någon egen NUMA-logik och processer ofta förändring. Typiska exempel är applikationsservrar, databaser med varierande belastning och värddatorer med många Containrar. I sådana konfigurationer ser den automatiska funktionen till att sidor och trådar hamnar närmare varandra utan att jag behöver fästa dem manuellt. Särskilt på värdsystem med flera socklar ökar andelen lokala åtkomstförsök märkbart. För administratörer med heterogena tjänster ger detta en bra Kompromiss av tid och arbete.
När ska man inaktivera: tydliga kriterier
Jag stänger av den automatiska funktionen så fort jag medvetet gör ett misstag eller fattar beslut Policys ställer in. Om jag använder numactl, cgroups eller MPOL_BIND/MPOL_PREFERRED finns det redan ett fastställt val av minnesvägar. Då orsakar hint-fel och migreringar onödig Overhead. Detsamma gäller för realtids- eller HFT-scenarier, där varje mikrosekund räknas och förutsägbarhet är avgörande. Den som fördjupar sig i valet av placeringsregler har nytta av att ta en titt på lämpliga Minnespolicyer.
Att förstå och mäta overhead
Automatisk balansering medför arbete: skanningar, Fel och sidmigreringar tar upp CPU-tid. Det märks knappt när antalet fjärråtkomster minskar kraftigt, men lönar sig knappast när layouten redan finns lokalt. Därför kontrollerar jag alltid den faktiska effekten med numastat, perf och meningsfulla Riktmärken. Det är utvecklingen över flera minuter som är intressant, inte bara en kort topp. Först när mätvärdena konsekvent visar att de lokala åtkomsterna ökar och latenserna minskar behåller jag det här läget.
Konfiguration: Sysctl och startparametrar
Jag kontrollerar statusen via /proc eller sysctl och ändrar den omedelbart vid behov, utan att Omstart. För teständamål räcker det med enkla kommandon som de nedan, som jag kör i konsolen. På sikt ställer jag in värdet i en sysctl-fil så att det bevaras efter en omstart. Den som vill ställa in det redan vid uppstarten använder kärnparametern numa_balancing=enable eller inaktivera. Jag dokumenterar varje ändring och antecknar i vilken arbetsbelastningsfas jag har gjort den.
cat /proc/sys/kernel/numa_balancing
echo 0 > /proc/sys/kernel/numa_balancing
sysctl -w kernel.numa_balancing=1
# /etc/sysctl.d/90-numa.conf
# kernel.numa_balancing = 0
Container- och virtualiseringsscenarier
På värddatorer med många virtuella maskiner och containrar spelar den automatiska Lokalisering utnyttjar ofta sina styrkor. Processer startas och avslutas, Cgroups omfördelar belastningen, och kärnan håller minnet närmare de aktiva kärnorna. Jag märker detta framför allt på stora servrar med flera socklar och flera Noder. Särskilda fall där enskilda instanser är strikt fastställda skiljer jag tydligt åt och inaktiverar där automatiken på ett målinriktat sätt. För en mer ingående klassificering kan det vara bra att ta en titt på praktiska NUMA-optimering i värdläget.
Beslutstabell för praktiskt bruk
I följande översikt sammanfattas typiska scenarier, den förväntade effekten och min tydliga Rekommendation. Jag använder dem som utgångspunkt, men ersätter aldrig mätvärdena i det verkliga systemet med dem. Varje miljö har sina egna särdrag, och jag fattar beslut först efter att ha uppnått reproducerbara Resultat fast. Den som arbetar systematiskt sparar tid senare vid felsökning och finjustering. Små testkörningar inför en lansering lönar sig nästan alltid i Constance och förutsägbarhet.
| Scenario | Typiska effekter | Mitt förslag |
|---|---|---|
| Standardarbetsbelastningar utan NUMA-optimering | Fler lokala besök, färre från andra orter Läsning | Lämna aktiv |
| Databaser med varierande belastning | Dynamisk sidolokalisering, måttlig Skannar | Låt den vara aktiv, testa |
| Hård realtid eller HFT | Latensen vid hint-fel stör Jitter-Mål | Inaktivera, fästa manuellt |
| Manuell fastställning via numactl/cgroups | Automatiken kolliderar med fasta föremål Policys | Inaktivera |
| Statiska minnesregler (MPOL_BIND, m.fl.) | Migrationer ger ingen verklig Fördel | Inaktivera |
| Test- och analysmiljö | Bra överblick över platsen och Effekter | Lämna aktivt, granska alternativ |
Riktlinjer för testning och validering
Jag startar med Balancer aktiverat och loggar lokala kontra fjärranslutna Tillträden via Numastat. Därefter inaktiverar jag funktionen och upprepar mätningarna på exakt samma sätt. Jag utvärderar skillnaderna inte bara utifrån medelvärden, utan även utifrån Percentiler. Regressionskontroller med belastningsprofiler från produktionen ger de mest tillförlitliga resultaten. Först då fattar jag det slutgiltiga beslutet om server, virtuell maskin eller en viss Service.
Vanliga hinder och myter
En vanlig missuppfattning är att den automatiska funktionen ersätter alla Nålning. Det stämmer inte, eftersom fasta latensbudgetar knappt tål ytterligare fel. Lika felaktig är antagandet att migreringar alltid kostnadsfritt inträffa. Särskilt när det gäller lokala layouter verkar overhead oftare ha en negativ än en positiv inverkan. Den som undviker myter och mäter noggrant fattar beslut med betydligt högre Noggrannhet.
Automatiseringens gränser och interaktioner
AutoNUMA har stor inverkan på anonyma sidor som en process själv allokerar. Men det går inte att migrera allt på ett meningsfullt sätt. Fästa sidor (mlock), DMA-/enhetsminne, DAX eller RDMA-registrerade områden förblir där de är. Även delade sidor (t.ex. flitigt delade bibliotek eller sidcache) ger endast begränsad nytta genom migrering, eftersom flera processer konkurrerar om Åtkomstmönster generera. Jag tar dessutom hänsyn till kostnaderna för Transparenta stora sidor (THP): deras migrering är dyrare än för 4-KiB-sidor och kan orsaka belastningstoppar. Den som har strikta latensmål kombinerar ofta THP=never eller madvise med inaktiverad balansering och ren pinning för att undvika överraskningar.
En annan aspekt är samspelet med CPU-schemaläggaren. Schemaläggaren försöker placera trådar där deras data finns – och balanseraren flyttar data dit där trådarna körs. De båda kompletterar varandra, men kan vid ojämn belastning tillfälligt leda till Svängningar leda till. I praktiken dämpar skanningsintervallen dessa effekter; den som ser extremt ojämna belastningsprofiler kan jämna ut situationen genom längre skanningsperioder eller genom stabilare trådfästning.
Finjustering av skanningsparametrarna
Förutom den globala inställningen finns det kärnparametrar som jag kan använda för att finjustera automatikens aggressivitet. De exakta namnen kan variera något beroende på kärnversionen, men syftet är detsamma:
- kernel.numa_balancing_scan_delay_ms: Väntetid efter start, fork eller exec tills den första skanningen påbörjas.
- kernel.numa_balancing_scan_period_min_ms / _max_ms: Minimi- och maximigräns för skanningsfrekvensen per processadressområde.
- kernel.numa_balancing_rate_limit_mb: Övre gräns per tidsfönster för sidmigreringar, för att spara på minnesbandbredden.
- kernel.numa_balancing_scan_size_mb: Mängden minne som markeras per skanningsomgång (om tillgängligt).
I system där latensen är avgörande brukar jag, av försiktighetsskäl, öka minimiperioderna och maximiperioderna samt sänka hastighetsbegränsningarna, istället för att omedelbart stänga av den automatiska funktionen. Det ger ofta en bra medelväg: färre ”hint-faults”, färre migreringar, men ändå tillräcklig reaktion på verkliga felplaceringar.
#-exempel (tillfälligt, fram till omstart)
sysctl -w kernel.numa_balancing_scan_period_min_ms=60000
sysctl -w kernel.numa_balancing_scan_period_max_ms=240000
sysctl -w kernel.numa_balancing_rate_limit_mb=64
Mätvärden och diagnostik på djupet
För att kunna fatta välgrundade beslut granskar jag nyckeltal som tydligt belyser mekanismen. Jag använder regelbundet tre källor:
- numastat: Förhållandet mellan lokala och fjärråtkomster på systemnivå och per process.
- /proc//numa_maps: Fördelning av en process minnessidor över noder, inklusive flaggor som active, file och anon.
- /proc/vmstat: Räknare som numa_hint_faults, numa_hint_faults_local och numa_pages_migrated visar om balanseringsmodulen är aktiv och om den Framgång har.
# Översikt per process
numastat -p
# Detaljvy: vilka områden finns var?
grep -E 'anon|file' /proc//numa_maps | head
# Kernelövergripande översikt över AutoNUMA-aktivitet
grep -E 'numa_(hint_faults|pages_migrated)' /proc/vmstat
I resultaten letar jag efter trender: Ökar andelen lokala åtkomstförsök stadigt? Minskar samtidigt antalet ”hint-faults”? Då har en bra layout slagit igenom. Om andelen lokala åtkomstförfrågningar förblir oförändrad trots många migreringar, slösar jag hellre bort cykler. För latensmål kontrollerar jag dessutom den 95:e och 99:e percentilen för svarstiderna; små förbättringar av medelvärdet kan genom Jitter täckas över.
Arbetsbelastningsprofiler: vad som vanligtvis fungerar
Erfarenheterna har visat vilka situationer där AutoNUMA oftast är till hjälp och när det inte är det:
- JVM-tjänster och applikationsservrar: De drar ofta nytta av detta, så länge ingen strikt trådbindningsstrategi och ingen egen aggressiv NUMA-logik är aktiv. Vissa runtime-miljöer erbjuder NUMA-alternativ; om jag använder dessa strikt, minskar jag den automatiska funktionen eller stänger av den helt.
- Relationella databaser: Vid varierande belastning med blandade cacher fungerar den automatiska funktionen ofta bra. Om jag däremot använder dedikerad pinning (Worker-to-Node, strikt fördelade delade buffertar) inaktiverar jag balanseringen för att säkerställa ren reproducerbarhet.
- In-memory-lagring och cacher: En stor, aktiv arbetsuppsättning drar nytta av lokal placering. Om instansen körs i en tråd eller är strikt fastlåst förhindrar jag onödiga migreringar genom att stänga av den.
- HPC/MPI och vetenskapliga program: Oftast finns det tydliga regler för placering och bindning (OpenMP/numactl). Här är förutsägbarhet viktigare än automatik – jag stänger av NUMA-balansering.
Virtualisering: vNUMA, pinning och live-migrering
I samspelet mellan värd och gäst tar jag hänsyn till båda nivåerna:
- Om vNUMA-topologin i gästsystemet stämmer överens med värdens fysiska NUMA-topologi kan gästbalanseraren fatta välgrundade beslut. Om det finns avvikelser uppstår „felaktiga grannskap“, vilket AutoNUMA endast kan kompensera i begränsad utsträckning.
- Om jag kopplar vCPU:er fast till värd-CPU:er och binder gästminnet till specifika noder, är det en explicit policy – jag minskar eller inaktiverar AutoNUMA på denna VM-nivå för att undvika dubbla migreringar.
- Efter live-migreringar ser jag en uppvärmningsfas: antalet hint-fel ökar tills en ny jämvikt har uppnåtts. Under den här tiden planerar jag in buffertar för Fördröjning-spetsar.
På tätbefolkade virtualiseringsvärdar, där instanser startas och stängs av och cgroups omfördelar belastningen, är den automatiska funktionen på värden ofta en nettofördel. För dedikerade virtuella maskiner som är känsliga för „Noisy Neighbors“ kapslar jag in resurserna ordentligt och ställer in reglerna statiskt.
Pragmatiska målvärden och acceptanskriterier
Jag definierar först vad „bra“ innebär, så att jag inte behöver finjustera i all oändlighet:
- Allmänna tjänster: 70–85% lokala åtkomstförsök räcker ofta om variansen är låg.
- SLA:er för latens: Mål >90% lokalt, tydliga övre gränser för Hint-Fault-Rate och stabila 99:e percentiler.
- Bandbreddstungt: Migreringar får inte överbelasta lagringskanalerna – justera hastighetsbegränsningar och tidsintervall därefter.
Jag dokumenterar dessa tröskelvärden och utvärderar A/B-tester över flera belastningsfaser. Jag fattar inte något beslut förrän resultaten är reproducerbara.
Checklista för felsökning
- Plötsliga latensspikar: Kontrollera om THP-migreringar eller toppar i numa_hint_faults korrelerar. Åtgärd: Öka skanningsintervallen, ställ in THP på madvise/never, stäng av Balance vid behov.
- Knappast någon effekt trots aktivering: Är trådarna starkt fästa eller finns det fasta minnesregler? I så fall kolliderar den automatiska funktionen med inställningarna.
- Hög migreringstakt, men ändå många fjärråtkomster: Kontrollera och höj hastighetsbegränsningen; alternativt stabilisera arbetsbelastningen (trådfästning, håll cachen så varm som möjligt).
- Otydliga mätvärden: Använd processvis vy med numastat -p och /proc//numa_maps, inte bara systemets sammanlagda värden.
Detaljer som ofta förbises
- Arbetsbelastningar som är beroende av sidcache: AutoNUMA har framför allt effekt på anonyma sidor. Den som främst arbetar med I/O-intensiva uppgifter bör inte förvänta sig några mirakel genom balansering.
- Cgroups och cpusets: cpuset.mems begränsar vilka noder en grupp får åtkomst till. Detta är en fast ram inom vilken det automatiska systemet verkar.
- Memory-Hotplug/Node-Offlining: Dynamiska topologier förändrar avstånden; efter ändringar är det lämpligt att utföra ett nytt test och vid behov justera skanningsparametrarna.
Kortfattat sammanfattat
För allmänna serverarbetsbelastningar låter jag den automatiska inställningen vara påslagen, eftersom den utan manuellt ingripande nästan Uppgifter vilket leder till aktiva kärnor. Vid realtidsdrift, HFT, manuell pinning eller fasta policyer stänger jag av dem för att undvika överbelastning och jitter. Under testfaser arbetar jag iterativt: mäta, besluta, upprepa validera. Jag håller konfigurationen enkel, dokumenterar varje ändring och kontrollerar effekten med hjälp av tillförlitliga nyckeltal. På så sätt utnyttjar jag styrkorna hos NUMA-hårdvaran utan onödiga Risker att ta hänsyn till.
