Forstå NUMA -arkitektur

Utformingen av I/O -busser representerer datamaskinens arterier og bestemmer betydelig hvor mye og hvor raskt data kan utveksles mellom de enkelte komponentene som er oppført ovenfor. Toppkategorien ledes av komponenter som brukes innen High Performance Computing (HPC). Fra midten av 2020 er blant de nåværende representantene for HPC Nvidia Tesla og DGX, Radeon Instinct og Intel Xeon Phi GPU-baserte akseleratorprodukter (se [1,2] for produktsammenligninger).

Forstå NUMA

Non-Uniform Memory Access (NUMA) beskriver en delt minnearkitektur som brukes i moderne flerbehandlingssystemer. NUMA er et datasystem som består av flere enkeltnoder på en slik måte at det samlede minnet deles mellom alle noder: hver CPU får sitt eget lokale minne og kan få tilgang til minne fra andre CPUer i systemet [12,7].

NUMA er et smart system som brukes til å koble flere sentrale prosessorenheter (CPU) til en hvilken som helst datamaskinminne som er tilgjengelig på datamaskinen. De enkelte NUMA -nodene er koblet over et skalerbart nettverk (I/O -buss) slik at en CPU systematisk kan få tilgang til minne assosiert med andre NUMA -noder.

Lokalt minne er minnet som CPU -en bruker i en bestemt NUMA -node. Utenlandsk eller eksternt minne er minnet som en CPU tar fra en annen NUMA -node. Begrepet NUMA -forhold beskriver forholdet mellom kostnaden for tilgang til utenlandsk minne og kostnaden for tilgang til lokalt minne. Jo større forhold, desto større kostnad, og dermed lengre tid tar det å få tilgang til minnet.

Det tar imidlertid lengre tid enn når den CPUen får tilgang til sitt eget lokale minne. Lokal minnetilgang er en stor fordel, ettersom den kombinerer lav latens med høy båndbredde. I kontrast har tilgang til minne som tilhører en hvilken som helst annen CPU høyere latens og lavere båndbreddeytelse.

Ser tilbake: Evolusjon av flerprosessorer med delt minne

Frank Dennemann [8] uttaler at moderne systemarkitekturer ikke tillater virkelig Uniform Memory Access (UMA), selv om disse systemene er spesielt designet for dette formålet. Enkelt sagt var tanken på parallell databehandling å ha en gruppe prosessorer som samarbeider for å beregne en gitt oppgave, og derved fremskynde en ellers klassisk sekvensiell beregning.

Som forklart av Frank Dennemann [8], på begynnelsen av 1970 -tallet, ble behovet for systemer som kunne betjene flere samtidige brukeroperasjoner og overdreven datagenerering mainstream med introduksjonen av relasjonsdatabasesystemer. Til tross for den imponerende hastigheten på enprosessorytelse, var flerprosessorsystemer bedre rustet til å håndtere denne arbeidsmengden. For å tilby et kostnadseffektivt system ble delt minneadresseplass fokus for forskning. Tidlig ble det anbefalt systemer som bruker en tverrstangbryter, men med denne designkompleksiteten skalert sammen med økningen av prosessorer, noe som gjorde det bussbaserte systemet mer attraktivt. Prosessorer i et bussystem [kan] få tilgang til hele minneplassen ved å sende forespørsler på bussen, en svært kostnadseffektiv måte å bruke tilgjengelig minne så optimalt som mulig.

Bussbaserte datasystemer har imidlertid en flaskehals-den begrensede mengden båndbredde som fører til skalerbarhetsproblemer. Jo flere CPUer som blir lagt til i systemet, desto mindre båndbredde per node er tilgjengelig. Videre, jo flere CPUer som blir lagt til, jo lengre buss, og jo høyere latens som et resultat.

De fleste CPUer ble konstruert i et todimensjonalt plan. CPUer måtte også ha integrerte minnekontrollere lagt til. Den enkle løsningen med å ha fire minnebusser (topp, bunn, venstre, høyre) til hver CPU -kjerne tillot full tilgjengelig båndbredde, men det går bare så langt. CPUer stagnerte med fire kjerner i lang tid. Å legge til spor over og under tillot direkte busser over til de diagonalt motsatte CPU -ene da sjetonger ble 3D. Å plassere en firekjernet CPU på et kort, som deretter ble koblet til en buss, var det neste logiske trinnet.

I dag inneholder hver prosessor mange kjerner med en delt on-chip-cache og et off-chip-minne og har variable minnetilgangskostnader på tvers av forskjellige deler av minnet på en server.

Forbedring av effektiviteten til datatilgang er et av hovedmålene med moderne CPU -design. Hver CPU -kjerne ble utstyrt med en liten cache på nivå 1 (32 KB) og en større (256 KB) nivå 2 -cache. De forskjellige kjernene ville senere dele en nivå 3 -cache på flere MB, hvis størrelse har vokst betraktelig over tid.

For å unngå hurtigbuffer - å be om data som ikke er i hurtigbufferen - brukes mye forskningstid på å finne riktig antall CPU -cacher, bufrestrukturer og tilsvarende algoritmer. Se [8] for en mer detaljert forklaring av protokollen for caching snoop [4] og cache coherency [3,5], samt designideene bak NUMA.

Programvarestøtte for NUMA

Det er to programvareoptimaliseringstiltak som kan forbedre ytelsen til et system som støtter NUMA -arkitektur - prosessoraffinitet og dataplassering. Som forklart i [19], muliggjør prosessoraffinitet [...] binding og oppbinding av en prosess eller en tråd til en enkelt CPU, eller en rekke CPUer, slik at prosessen eller tråden bare vil utføres på den eller de angitte CPU -ene eller CPUene i stedet for hvilken som helst CPU. Begrepet dataplacement refererer til programvaremodifikasjoner der kode og data holdes så nært som mulig i minnet.

De forskjellige UNIX- og UNIX-relaterte operativsystemene støtter NUMA på følgende måter (listen nedenfor er hentet fra [14]):

• Silicon Graphics IRIX -støtte for ccNUMA -arkitektur over 1240 CPU med Origin -serverserier.
• Microsoft Windows 7 og Windows Server 2008 R2 la til støtte for NUMA -arkitektur over 64 logiske kjerner.
• Versjon 2.5 av Linux -kjernen inneholdt allerede grunnleggende NUMA -støtte, som ble ytterligere forbedret i påfølgende kjerneutgivelser. Versjon 3.8 av Linux -kjernen brakte et nytt NUMA -fundament som muliggjorde utvikling av mer effektive NUMA -retningslinjer i senere kjerneutgivelser [13]. Versjon 3.13 av Linux -kjernen brakte en rekke retningslinjer som tar sikte på å sette en prosess nær minnet, sammen med håndtering av saker, for eksempel å ha minnesider delt mellom prosesser, eller bruk av gjennomsiktige store sider; nye systemkontrollinnstillinger gjør at NUMA -balansering kan aktiveres eller deaktiveres, samt konfigurasjon av forskjellige NUMA -minnebalanseringsparametere [15].
• Både Oracle og OpenSolaris modell NUMA -arkitektur med introduksjon av logiske grupper.
• FreeBSD la til Initial NUMA -affinitet og policy -konfigurasjon i versjon 11.0.

I boken Computer Science and Technology, Proceedings of the International Conference (CST2016) antyder Ning Cai at studiet av NUMA-arkitektur hovedsakelig var fokusert på high-end databehandlingsmiljø og foreslått NUMA-bevisst Radix Partitioning (NaRP), som optimaliserer ytelsen av delte cacher i NUMA -noder for å akselerere business intelligence -applikasjoner. Som sådan representerer NUMA en mellomting mellom systemer med delt minne (SMP) med noen få prosessorer [6].

NUMA og Linux

Som nevnt ovenfor har Linux -kjernen støttet NUMA siden versjon 2.5. Både Debian GNU/Linux og Ubuntu tilbyr NUMA -støtte for prosessoptimalisering med de to programvarepakkene numactl [16] og numad [17]. Ved hjelp av kommandoen numactl kan du liste opp oversikten over tilgjengelige NUMA -noder i systemet [18]:

NumaTop er et nyttig verktøy utviklet av Intel for å overvåke lokalitet for kjøretidsminne og analysere prosesser i NUMA -systemer [10,11]. Verktøyet kan identifisere potensielle NUMA-relaterte flaskehalser for ytelse og dermed bidra til å balansere minne/CPU-allokeringer for å maksimere potensialet til et NUMA-system. Se [9] for en mer detaljert beskrivelse.

Bruksscenarier

Datamaskiner som støtter NUMA -teknologi gir alle CPUer tilgang til hele minnet direkte - CPUene ser på dette som et enkelt, lineært adresserom. Dette fører til mer effektiv bruk av 64-biters adresseringsskjema, noe som resulterer i raskere bevegelse av data, mindre replikasjon av data og enklere programmering.

NUMA-systemer er ganske attraktive for server-side applikasjoner, for eksempel data mining og beslutningsstøttesystemer. Videre blir det mye lettere å skrive applikasjoner for spill og programvare med høy ytelse med denne arkitekturen.

Konklusjon

Avslutningsvis adresserer NUMA -arkitektur skalerbarhet, som er en av hovedfordelene. I en NUMA CPU vil en node ha en høyere båndbredde eller lavere latens for å få tilgang til minnet på den samme noden (f.eks. Ber den lokale CPU om minnetilgang samtidig med ekstern tilgang; prioriteten er på den lokale CPUen). Dette vil forbedre minnegjennomstrømningen dramatisk hvis dataene er lokalisert til spesifikke prosesser (og dermed prosessorer). Ulempene er de høyere kostnadene ved å flytte data fra en prosessor til en annen. Så lenge denne saken ikke skjer for ofte, vil et NUMA -system overgå systemer med en mer tradisjonell arkitektur.

Lenker og referanser

1. Sammenlign NVIDIA Tesla vs.Radeon Instinct, https://www.itcentralstation.com/products/comparisons/nvidia-tesla_vs_radeon-instinct
2. Sammenlign NVIDIA DGX-1 vs.Radeon Instinct, https://www.itcentralstation.com/products/comparisons/nvidia-dgx-1_vs_radeon-instinct
3. Cache -sammenheng, Wikipedia, https://en.wikipedia.org/wiki/Cache_coherence
4. Bussnokking, Wikipedia, https://en.wikipedia.org/wiki/Bus_snooping
5. Cache koherensprotokoller i flerprosessorsystemer, Geeks for nörd, https://www.geeksforgeeks.org/cache-coherence-protocols-in-multiprocessor-system /
6. Datavitenskap og teknologi - Proceedings of the International Conference (CST2016), Ning Cai (red.), World Scientific Publishing Co Pte Ltd, ISBN: 9789813146419
7. Daniel P. Bovet og Marco Cesati: Understanding NUMA architecture in Understanding the Linux Kernel, 3rd edition, O’Reilly, https://www.oreilly.com/library/view/understanding-the-linux/0596005652/
8. Frank Dennemann: NUMA Deep Dive Del 1: Fra UMA til NUMA, https://frankdenneman.nl/2016/07/07/numa-deep-dive-part-1-uma-numa/
9. Colin Ian King: NumaTop: Et NUMA systemovervåkingsverktøy, http://smackerelofopinion.blogspot.com/2015/09/numatop-numa-system-monitoring-tool.html
10. Numatop, https://github.com/intel/numatop
11. Pakke numatop for Debian GNU / Linux, https://packages.debian.org/buster/numatop
12. Jonathan Kehayias: Understanding Non-Uniform Memory Access/Architectures (NUMA), https://www.sqlskills.com/blogs/jonathan/understanding-non-uniform-memory-accessarchitectures-numa/
13. Linux Kernel News for Kernel 3.8, https://kernelnewbies.org/Linux_3.8
14. Ikke-enhetlig minnetilgang (NUMA), Wikipedia, https://en.wikipedia.org/wiki/Non-uniform_memory_access
15. Linux Memory Management Documentation, NUMA, https://www.kernel.org/doc/html/latest/vm/numa.html
16. Pakke nummer for Debian GNU/Linux, https://packages.debian.org/sid/admin/numactl
17. Pakke nummer for Debian GNU/Linux, https://packages.debian.org/buster/numad
18. Hvordan finner jeg ut om NUMA -konfigurasjon er aktivert eller deaktivert ?, https://www.thegeekdiary.com/centos-rhel-how-to-find-if-numa-configuration-is-enabled-or-disabled/
19. Prosessoraffinitet, Wikipedia, https://en.wikipedia.org/wiki/Processor_affinity

Takk skal du ha

Forfatterne vil takke Gerold Rupprecht for støtten under utarbeidelsen av denne artikkelen.

Om forfatterne

Plaxedes Nehanda er en flerdaglig, selvdrevet allsidig person som bærer mange hatter, blant dem en hendelsesplanlegger, en virtuell assistent, en transkriber, samt en ivrig forsker, basert i Johannesburg, Sør-Afrika.

Prince K. Nehanda er ingeniør for instrumentering og kontroll (metrologi) ved Paeflow Metering i Harare, Zimbabwe.

Frank Hofmann jobber på veien-fortrinnsvis fra Berlin (Tyskland), Genève (Sveits) og Cape Town (Sør-Afrika)-som utvikler, trener og forfatter for blader som Linux-User og Linux Magazine. Han er også medforfatter av boken Debian-pakkehåndtering ( http://www.dpmb.org ).