SHAREPOINT BUILDING BLOCKS.

SHAREPOINT BUILDING BLOCKS.

Uoffisiell blogg av Benjamin Athawes.

Bestemme NUMA node grenser for moderne CPUer.

Siste onsdag hadde jeg gleden av a presentere i East Anglia SharePoint brukergruppen (SUGUK). Brukergruppen er organisert av Randy Perkins og Peter Baddeley som begge er meget vennlige, kunnskapsrike SharePoint-gutter. Mens okten min hadde til hensikt a gi noen generell veiledning om SharePoint-administrasjon (jeg presenterer en lignende dekk pa SharePoint Saturday), er emnet i denne bloggen et tema dekket under kveldens forste sesjon: & # 8220; SharePoint 2010 Virtualisering & # 8220;, presentert av John Timney (MVP). For a v re mer spesifikk, diskuterer dette innlegget NUMA node grenser i forbindelse med virtualisering av SharePoint, og forhapentligvis reiser noen sporsmal om MS-dokumentasjonen bor oppdateres for a inkludere veiledning for storre multi-core prosessorer (dvs. mer enn 4 kjerner).

Jeg foler behovet for a legge til en ansvarsfraskrivelse pa dette stadiet, siden jeg ikke er en ekspert nar det kommer til NUMA-arkitektur eller maskinvare generelt. Jeg tror at jeg skylder at funnene mine bor deles, ettersom veiledningen fra Microsoft nesten helt sikkert har en reell innvirkning pa maskinvareinnkjopsbeslutninger pa et tidspunkt da virtualisering av SharePoint er et industrielt tema (som det fremgar av den store brukergruppens valgdeltagelse).

Bruk denne veiledningen pa egen risiko & # 8211; sok rad fra maskinvareleverandoren din.

Hva er NUMA, og hvorfor skal jeg bryr meg?

La & # 8217; s starte med en definisjon fra Wikipedia:

& # 8220; Ikke-enhetlig minnetilgang (NUMA) er et dataminnemonster som brukes i Multiprocessing, hvor minnetilgangstidspunktet avhenger av minnestedet i forhold til en prosessor. Under NUMA kan en prosessor fa tilgang til sitt eget lokale minne raskere enn ikke-lokalt minne, det vil si minnet lokalt til en annen prosessor eller minne som deles mellom prosessorer. & # 8221;

Sa vi kan hente noen fa grunnleggende fakta fra den definisjonen. NUMA er relevant for flere prosessorer, og betyr at minne kan nas raskere hvis det er n rmere. Dette betyr at minnet vanligvis er delt opp og & # 8221; pa maskinvareniva for a gi hver prosessor i et multi-CPU-system med eget minne. Tanken er a unnga et argument nar prosessorene forsoker a fa tilgang til det samme minnet. Dette er en god ting, og betyr at NUMA har potensial til a v re mer skalerbar enn en UMA (flere stikkontakter deler samme buss) -design – spesielt nar det gjelder miljoer med et stort antall logiske kjerner.

En mulig NUMA-arkitektur som markerer lokal og ekstern tilgang. Kilde: Frank Denneman.

Som du kan se fra diagrammet ovenfor, kunne NUMA betraktes som en form for klyngedatabase fordi de ideelt logiske kjernene samarbeider med lokalt minne for forbedret ytelse.

For vi fortsetter, er det verdt a merke seg at det er to former for NUMA: maskinvare og programvare. Programvare NUMA benytter virtuell minnepaging og er i de fleste tilfeller en storrelsesorden ganger tregere enn hardware NUMA. I dag ser vi pa maskinvaresmak – det vil si CPU-arkitekturer som har en integrert minnekontroll og implementerer en NUMA-design.

The & # 8220; hvorfor skal jeg bry meg? & # 8221; En del kommer nar man innser at NUMA burde ha direkte innflytelse pa a bestemme:

Hvor mye minne a installere pa en server (en beslutning pa forhand) og Hvor mye minne a allokere til hver VM (en pagaende vurdering), forutsatt at du planlegger a virtualisere.

Faktisk har Microsoft gatt sa langt som a si at & # 8220; Under testingen hadde ingen endring storre innvirkning pa ytelsen enn a endre storrelsen pa RAM tildelt til et enkelt Hyper-V-bilde & # 8220 ;. Det var nok til a fa meg til a sitte og v re oppmerksom. Hvis du er en for beregninger, anslar Microsoft at ytelsen faller med rundt 8% nar en VM-minneallokering er storre enn NUMA-grensen. Dette betyr at du kan ende opp i en situasjon der tildeling av mer RAM til en VM reduserer ytelsen pa grunn av at gjestesessionen krysser over en eller flere NUMA-nodelinjer.

Den nav rende Microsoft-veiledningen.

Vi har sett pa teorien, og forhapentligvis er det klart at vi ma bestemme vare NUMA knutepunktgrenser nar vi bygger en virtualisert SharePoint-losning. Microsoft gir folgende veiledning for a bidra til a beregne dette:

& # 8220; I de fleste tilfeller kan du bestemme dine NUMA knutepunktgrenser ved a dividere mengden fysisk RAM ved antall logiske prosessorer (kerner). Det anbefales at du leser folgende artikler:

La oss se pa den dristige teksten over som representerer & # 8220; tommelfingerregelen & # 8221; beregning som vanligvis refereres til nar du diskuterer NUMA-noder. Michael Noel (veldig kjent i SharePoint-plassen) bruker denne beregningen i de fleste av hans virtualiseringssessioner, et godt eksempel er tilgjengelig her:

En dobbel quad-core-vert (2 * 4 = 8 kjerner) med 64 GB RAM pa verten ville bety at NUMA-grensen er 64/8 eller 8 GB. I dette eksempelet vil allokering av mer enn 8 GB til en enkelt gjestesession resultere i ytelsesdraper & # 8221 ;.

Ved forste oyekast kan [RAM / logical cores] -beregningen gitt av Microsoft virke overbevisende pa grunn av sin enkelhet. Jeg vil gjette at formelen ble testet og funnet a v re et palitelig middel for a bestemme NUMA node grenser (eller i det minste ytelsesgrenser for virtuelle gjestesesjoner) pa tidspunktet for publisering.

Men som du vil se senere, har jeg ikke funnet et flertall av bevis som tyder pa at denne veiledningen faktisk gir NUMA knutepunktgrenser for moderne prosessorer (les mer enn 4 logiske kjerner). Det er ikke a si at det er darlige rad: i et verste tilfelle & # 8221; scenario (dvs. veiledningen virker ikke for storre CPUer); Utfallet ville v re at de som har fulgt det til brevet, vil bli igjen med store servere (med plass til vekst). I et beste tilfelle & # 8221; scenario Jeg er helt utenfor merket med dette innlegget, og alle (inkludert meg) kan v re sikre pa at vare servere er dimensjonert riktig. Det er en vinn-vinn.

Bruke gjeldende NUMA node veiledning i praksis.

Som flittige SharePoint-utovere satser vi alltid pa a bruke den beste praksis veiledningen fra Microsoft, og anbefalingen til NUMA-noden bor i teorien ikke v re noe unntak. For a gi et eksempel, ma vi vurdere eventuelle relaterte rad, for eksempel Microsofts veiledning om prosessorbelastning:

Forholdet mellom virtuelle prosessorer og logiske prosessorer er en av de avgjorende elementene i maling av prosessorbelastning. Nar forholdet mellom virtuelle prosessorer og logiske prosessorer ikke er 1: 1, sies det at CPU’en er overskrevet, noe som har en negativ effekt pa ytelsen. & # 8221;

Mens vi diskuterer storrelsen pa prosessor, ma du ikke glemme at Microsoft-liste 4 kjennetegnes som et minimumskrav for web- og applikasjonsservere. Vi har na to potensielt motstridende retningslinjer:

For store NUMA-grenser ma vi enten installere en stor mengde fysisk minne (et akseptabelt potensielt dyrt alternativ) eller holde antall logiske kerner nede. For a konsolidere vare servere ma vi sikre at det er nok logiske kjerner for a gi et godt virtuelt: logisk prosessorforhold.

La oss bruke disse retningslinjene til et forholdsvis enkelt konsolideringsscenario der vi onsker a migrere to fysiske servere til en virtuell vert. La oss anta at hver server har 16 GB RAM og en quad-kjerneprosessor for tiden. Tillater noe overhead for vertsserveren, tror jeg at vi ville v re ganske trygge med 10 logiske kjerner og si 36 GB RAM … med unntak av at vi ikke kan kjope 5-kjerneprosessorer. Vi ma avgjore to heksekjerneprosessorer, og gir totalt 12 logiske kjerner.

Sa hva ville var NUMA-grense v re i det scenariet?

36 GB / 12 kjerner = 3 GB RAM.

Det hores ikke riktig. Hvis hver gjestesesjon er tildelt 16 GB RAM, vil vi krysse 6 NUMA grenser! Fra hva vi har samlet sa langt, vil ytelsen konkurrere med en sneglekjoring.

La i stedet sla formelen pa hodet og finne ut hvor mye RAM vi ma allokere for a sikre at vi ikke krysser en NUMA-grense. 16GB NUMA node * 12 CPU-kjerner = 192 GB RAM. Det hores ikke riktig heller, gitt at vi bare provde a konsolidere to VM. Vare alternativer vises begrenset til a kjope en skurmengde eller redusere mengden minne som er tildelt hver gjestesesjon. Downsizing-alternativet vil trolig bety at vi trenger en ekstra server eller to, noe som betyr at vi skal skalere ned og ut og # 8221 ;. Et storre antall & # 8220; tynn & # 8221; servere kan potensielt fungere bedre enn et mindre antall & # 8220; tykk & # 8221; servere, sa dette er ikke nodvendigvis en darlig ide (selv om lisensavgiftene dine vil ga opp! J).

Pa dette stadiet ser det ut til at de ofte nevnte NUMA-kravene er sv rt restriktive og begrenser oss til a oversize servere eller endre var planlagte topologi. I lys av hva vi kjenner sa langt om NUMA og var korte diskusjon ovenfor, tror jeg at sporsmalet som vi alle spor oss selv er: gjor NUMA-grenselinjene fortsatt aktuelt for moderne CPUer?

I et forsok pa a gi bevis for a svare pa sporsmalet mitt bestemte jeg meg for a gjore en liten undersokelse rundt NUMA og tok en titt under hetten ved hjelp av beregninger hentet fra passende verktoy (vi bruker CoreInfo og Hyper-V PerfMon statistikk).

Gitt at NUMA er et minne design som er relevant for CPUer, fant jeg ut at et godt sted a starte, ville v re to store spillere i dette rommet: AMD og Intel. Forutsatt at de produserer sjetonger som implementerer NUMA, gir de noen retningslinjer rundt ytelsen. Jeg fanget folgende ressurser rett fra hestenes munn og # 8221 ;:

En stotteerkl ring (selv om ikke autoritativ pa samme mate som uttalelser om CPUer fra Intel eller AMD er) fra en MSFT-ansatt, lyder som folger:

& # 8220; I dag er enheten til en NUMA knutepunkt vanligvis en prosessor eller stikkontakt. Midler i de fleste tilfeller er det et 1: 1 forhold mellom en NUMA knutepunkt og en socket / prosessor. Unntak er AMDs nav rende 12-kjerneprosessor som representerer 2 NUMA noder pa grunn av prosessorens interne arkitektur. & # 8221;

Sa langt har vi funnet bevis for a foresla at CPU-kontakten (ikke logisk kjerne) generelt representerer NUMA-noden i moderne prosessorer. For a forsterke vare funn, la oss se hva CoreInfo og PerfMon har a si om saken.

Til referanse er serveren i dette eksemplet en HP DL 380 G7 med 64 GB RAM og to hex-kjerne Xeon E5649s (som implementerer NUMA). CPUene har hypertrad aktivert. Operativsystemet er Windows Server Core Enterprise 2008 R2 SP1.

Hex core HP-server med Intel E5649s: Oppgavebehandling.

Hex core HP server med Intel E5649s: CoreInfo.

Hex core HP server med Intel E5649s: PerfMon (ProcessorCount)

Hex core HP server med Intel E5649s: PerfMon (PageCount)

Det er noen punkter av interesse i skjermbildene ovenfor:

CoreInfo forteller at tilgangskostnaden for cross-NUMA (ekstern) node er ca. 1,2 i forhold til raskeste (lokale) tilgang. Hyper threading betyr at 24 logiske kjerner vises i bade CoreInfo og PerfMon. PerfMon indikerer at 12 prosessorer er knyttet til hver NUMA knutepunkt. Bare to NUMA noder viser i bade CoreInfo og PerfMon. Hver NUMA-node inneholder 8 388 608 4K sider eller 32 GB RAM.

Formelen levert av Microsoft virker ikke i dette tilfellet hvis CoreInfo og PerfMon er korrekte (MS-veiledningen vil indikere at det er 12 NUMA-grenser pa omtrent 5,3 GB hver). I dette tilfellet er det et 1: 1-forhold mellom CPU-stikkontakter og NUMA-noder, noe som betyr at det er 2 NUMA-noder pa 32 GB hver.

Med noen forste analyser i handen (men uten noen stottende data rundt ytelsen) trodde jeg det var verdt a dele med en bransjeekspert og # 8211; Michael Noel. Michael var snill nok til a reagere veldig fort med dette innsiktet:

& # 8220; Som det ser ut, endret chipproducentene seg selv NUMA-tildelingen i noen av disse storre kjerneprosessorer. Nar vi opprinnelig gjorde denne analysen, var de vanlige flerkjerneprosessorene dobbeltkjerne eller mest quad-kjerne. Pa disse sjetongene delte maskinvareprodusentene NUMA-grensene inn i kjerner, i stedet for stikkontakter. Men det ser ut som at den konfigurasjonen ikke er den samme for de storre flerkjernene (6, 12, etc.). Det er faktisk en god ting; det betyr at vi har mer designfleksibilitet, selv om jeg fortsatt vil anbefale storre minnestorrelser …

CoreInfo er sannsynligvis det beste verktoyet for dette ogsa, avtalt om din tiln rming. & # 8220;

A se disse dataene pa en fysisk server er ikke noyaktig avgjorende. Jeg tror at det reiser sporsmal om hvorvidt Microsofts forskriftsmessige veiledning gir litt forvirring nar det gjelder virtuell vert og gjesteglassering. Uten tilleggsdata vil mitt forslag pa dette stadiet v re a justere veiledningen for a ta mer av en & # 8220; det avhenger av & # 8221; holdning snarere enn a gi et magisk nummer. Forhapentligvis vil leverandorene gi ut noen ytelsestatistikk relatert til NUMA og virtualisering for moderne (storre) CPUer som vil bidra til a veilede fremtidige maskinvareinnkjopsbeslutninger.

For a v re rettferdig mot MS, gir de denne visdomspissen: & # 8220; Fordi minnekonfigurasjonen er maskinvarespesifikk, ma du teste og optimalisere minnekonfigurasjonen for maskinvaren du bruker til Hyper-V. & # 8221; Selv om det teknisk sett skal slettes av kroken, vil jeg foretrekke at tommelfingerregelen blir fjernet hvis det begynner a bli mindre relevant for moderne maskinvare.

Kort sagt, ikke anta at NUMA-grensene dine er delt inn i kjerner – det avhenger veldig mye av din spesifikke CPU-arkitektur. Mitt rad vil v re a sjekke ved hjelp av verktoy som CoreInfo og ytelsesmonitor eller spor maskinvareleverandoren pa forhand.