AWS vs GCP vs CPU jõudluse võrdlus

Hiljuti oli mul võimalus osaleda projektis, kus pidime hindama erinevate pilveteenuse pakkujate hinna ja väärtuse suhet ning võrdlema seda olemasoleva kohapealse riistvaraga. Internetis tehtud uurimistöö käigus leidsime keskseadme töötlemata jõudluse kohta üllatavalt vähe tegelikke, kasulikke võrdlusaluseid, nii et otsustasime teha oma.

Eesmärk: koguda andmeid, mis toetavad otsust, millist pilveteenuse pakkujat valida, ja aidata täpselt, kui palju vCPU-sid peate pilves ostma, kui te juba teate, kui palju te tavaliselt oma paljaste metallide füüsilises serveris kasutate. keskkond.

See testimisvoor ei kavatse olla täiuslik ja põhjalik, leidub professionaalseid IT-ajakirju; me tahtsime saada kiireid ja usaldusväärseid võrdlusandmeid, mis vastavad meie vajadustele. Kui teil on rohkem aega, oleks huvitav näha üksikasjalikke võrdlusaluseid erinevate tuumadega, enne / pärast Meltdown-Specter teste erineva keerme / CPU tuumade arvuga jne.

Meetod

Viitena kavatsen kasutada ise hostitud füüsilist serverit koos Intel Xeoni uusima mudeliga. Kõik osalejad on erinevad Xeoni mudelid. Nii Amazonis kui ka Google'is leiate ainult Inteli Xeoni protsessoreid, sõna otseses mõttes mitte midagi muud, ja see suundumus on andmekeskustes üsna sama.

Testid tegin tuntud sisselülitatud tööriista Dockeri pildi abil, kuid võrdlusena tegin sama mõõtmise binaariga, ilma Dockerit kasutamata. Leidsin erinevatel käitustel erinevuse <0,5%, nii et testimisprotseduuri lihtsustamiseks ja selle tagamiseks, et kasutaksime täpselt sama sysbenchi versiooni samade teekidega (sysbench 1.0.13 (kasutades komplekteeritud LuaJIT 2.1.0-beeta2)), otsustasime minna all-ini Dockeril (stabiilne CE 17.xx).

Kasutati järgmisi testkäske:

doki käitamine - 1. ring - rm-mitu mitu rida / sysbench sysbench cpu - cpu-max-prime = 20000 - niidid = 1 - time = 900 run
doki käitamine - 2. ring - rm-mitu mitu rida / sysbench sysbench cpu - cpu-max-prime = 20000 - niidid = 2 - time = 900 run
doki käitamine - 8. rpus - rm - mitu mitu rida / sysbench. süstemaatiline protsessor - CPU-max-prime = 20000 - niit = 8 - aeg = 900 käitamist

Mõõtmise aeg on

  • 10 sekundit spike-performance'i nägemiseks ja
  • 15 minutit tegeliku pikaajalise jõudluse nägemiseks.

Võrdleme CPU kiirust sündmuste sekundi väärtuste testi tulemustega.

Paljasmetalliga tegin mitu testi, et näha, kas kasutatud operatsioonisüsteemil (ja seetõttu ka kernelil) on oluline erinevus: testisin sama masinat CoreOS Container Linuxi stabiilse versiooniga (1632.3.0 - kernel 4.14.19). , Ubuntu 14.04 LTS ja CentOS 7. Jällegi oli erinevus mõõtmisvigade kategooria, seega näeme järgmisi opsüsteeme:

  • paljasmetallil: CentOS 7 ja CoreOS 1632.3.0
  • Amazoni veebiteenuste kohta: Amazon Linux
  • Google'i pilvplatvormil: CoreOS 1632.3.0

1. rühm: füüsilised serverid

Võrdlusmasin: 2016. aasta mudeli Intel (R) Xeon (R) CPU E5–2690 v4 @ 2,60 GHz.

Foto autor Igor Ovsyannykov saidil Unsplash

Ühetuumalise, ühe keermega seadistuse korral saame lühikese 10-sekundilise testi jooksul 303,13 sündmust sekundis, pikaajaline test näitas aga pisut paremat jõudlust kiirusega 321,84 e / s. Võtame 15-minutise tulemuse 100% -ks ja võrdleme kõike muud selle väärtusega.

Järgmisena teeme sihttaseme 2 spetsiaalsel protsessorituumil, kasutades 2 paralleelset niiti. Huvitav on see, et nüüd on 10 vs 900 sekundi võrdlusaluse erinevus väga väike: 670,61 vs 672,89 e / s. Need tulemused näitavad, et 2 CPU tuuma vs 2 * 1 CPU tuuma on selle konkreetse Intel Xeoni mudeli puhul 4,54% paremad.

Sarnaselt saame 8 südamiku-8 niidil 2716,31 sündmust sekundis, mis annab meile + 5,50% (või 105,50%) 8 * 1 protsessori tuuma jõudlusest.

Võrrelgem seda teiste füüsiliste masinatega!

Võistlejad:

  • Inteli (R) Xeon (R) CPU E5–2660 v3 @ 2,60 GHz 2014. aasta mudel
  • Intelligentse (X) Xeon (R) keskseadme 2013. aasta mudel E5–2658 v2 @ 2,40 GHz
  • ja lõbutsemiseks 2009. aasta mudeli Intel (R) Xeon (R) CPU X3460 @ 2.80GHz

Nagu arvata võis, mida vanem protsessor, seda aeglasem see on:

2016 → 2014 → 2013: 321,84 → 308,67 → 284,93 ühetuumalisel võrdlusalusel

Või protsentides võrreldes 2016. aasta Xeoniga:

100,00% → 95,91% → 88,53% (ühetuumaline)
100,00% → 96,36% → 86,55% (kahetuumaline)
100,00% → 95,14% → 86,53% (kahetuumaline)

Nagu näete, on füüsiliste serverite protsessori jõudlus tuumade ja keermete arvuga lineaarne. N-tuuma ja n * 1 -tuuma jõudlus on sarnaselt esimese katsetatud mudeliga vahemikus 102–105%.

Aga hei, kas sa ei nimetanud 4 Xeoni võrdluses ?!

* drumroll * - ligi 10-aastane Xeon X3450 põhjustas ootamatuid üllatusi: see peksis kõigist uuematest vendadest jama ühe keermega sünteetilisele etalonile, andes uskumatu 431,13 e / s väärtuse - see on 133,96% 2016. aastast võrdlusmudel. Jah, toona ei olnud mitme keermestamine keskmise rakenduse jaoks tegelikult asi.

Muidugi, nagu eeldatud, sulab see eelis väga kiiresti, kui suurendame niidide arvu kõigepealt 2-ni, hiljem 8-ni: kui kahetuumalise seadistuse puhul saavutame ikkagi sädeleva 127,71% 2016. aasta referentsist, siis 8-südamikul Suure venna jõudlus on juba vaid 73,52% (1996.96 e / s vs 2716.31 e / s). Sellel CPU-l on 8 loogilist südamikku, nii et me ei saa testidega kaugemale minna.

10-sekundiline teravik on tulemuseks ruumides15-minutilise võrdlustulemuse tulemus on ruumides

Muide, huvitaval kombel näitas võrdlusalus samu tulemusi 20-tuumalise E5–2658 v2 korral 40 niidiga (või 40 loogilise südamikuga, nagu näiteks Hyper Threading), 60 niidi, 80 niidi või 160 niidiga - ja kuni 40-ni suurenenud lineaarselt: 10 tuuma moodustas 25% 40 tuuma tulemusest, 20 tuuma oli 50%, 30 südamiku 75% jne. Nii näeb välja nagu pärast loogiliste protsessorituumade tegeliku arvu sobitamist, suurendades niidide arvu üle selle, mis ei Pikaajaliselt ei saa te midagi.

Füüsiliste masinatestide juurest minema

  • jõudluse skaala lineaarselt tuumade arvuga: kui paned rohkem tuuma, saad lineaarselt rohkem jõudlust
  • tundub, et uues Xeoni mudelis on igal aastal umbes + 5% rohkem kasu kui eelmisel aastal
  • vana, 2009. aasta mudel Xeon on ühe keermega töökoormuse korral märkimisväärselt tugevam, kuid kaotab kiiresti, kuna ilmub mitu lõime
Suhteline jõudlus võrreldes 2016. aasta Xeon E5–2690 v4-gaMitme lõime optimeerimine võrreldes ühe lõimega töövooga, ruumides

2. rühm: Amazon EC2 juhtumid

AWS-i platvormil on teil hulgaliselt erinevaid eksemplaritüüpe, mida saate oma vajadustele kohandada, nii et me tegime katseid üsna paljude nendega. Lisasin siia ka nende eksemplaritüüpide soovitatud kasutuse juhtumi Amazon poolt:

  • viide: kohapealne Intel (R) Xeon (R) CPU E5–2690 v4 @ 2,60 GHz
  • t2 (põhiline): Intel (R) Xeon (R) CPU E5–2676 v3 @ 2,40 GHz
  • m5 (geneeriline): Intel (R) Xeon (R) Platinum 8175M CPU @ 2,50 GHz
  • c5 (kõrge CPU): Intel (R) Xeon (R) Platinum 8124M CPU @ 3,00 GHz
  • r4 (kõrge mem): Intel (R) Xeon (R) CPU E5–2686 v4 @ 2,30 GHz
  • i3 (kõrge IOPS): Intel (R) Xeon (R) CPU E5–2686 v4 @ 2,30 GHz

Kõik CP2-d, välja arvatud baastüüp t2 (2015), on 2016. aasta või uusimad 2017. aasta mudelid, seega on nad kõik võrreldavad meie referentsiga. Huvitav kõrvalmärkus: need konkreetsed Xeon Platinum mudelid on tegelikult Amazoni jaoks kohandatud, te ei saa neid turul osta.

Amazon müüb vCPU-sid, mis on peentrükiga loogiliste protsessorituumade kohaselt lubatud ja hüperkeermestatud ning mitte ainult tegelike füüsiliste tuumadega. Neid südamikke ei varustata tavaliselt ülemäära; kuigi neid ei jagata "parimate jõupingutustega" protsessorituumadele, ei garanteeri nad, et nad ei optimeeriks sama masina erinevate kasutajate vahel. (Mikroeksemplaride abil on teil võimalus osta mitme üürniku vahel jagatud osalisi südamikke palju madalama hinnaga.)

Läheme siis testidele! Pärast samu süsteemset mõõtmist saime 10-sekundilise lühitesti korral järgmised väärtused:

10-sekundilise teraviku tulemus on AWS

Võite juba näha:

  • ühetuumaline jõudlus on meie referentsist palju parem, ainult ühe erandiga
  • kuid juba kahe lõimega hakkate kaotama 10–25% võrreldes ise hostitud füüsilise riistvaraga
  • t2 tundub väga usaldusväärne ja stabiilne näide metallist

Ärge unustage, et Amazon võib lubada teie töökoormuses ajutisi piike, ilma et teie protsessori jõudlust piirataks. Sellepärast tegimegi 15-minutilised mõõdupuud:

15-minutilise võrdlustulemuse AWS

Pikemas perspektiivis näitasid füüsikalised juhtumid konstantset 105% -list jõudlust võrreldes ühe lõime tulemustega.

Jällegi, t2 toimib nagu meie enda hostitud serverid, väga toimuvaga.

Ülejäänud pole nii ahvatlev, isegi parimal juhul kaotame ~ 17%, mis ulatub m5 üldotstarbeliste eksemplaride korral ~ 27% -ni. See tähendab, et kui teie andmekeskuses on 100 CPU-tuuma, peate sama jõudluse tagamiseks ostma Amazonis 127 vCPU-tuuma.

AWS-i suhteline jõudlus võrreldes 2016. aasta Xeon E5–2690 v4-gaMitme lõime optimeerimine vs ühe lõimega töövood, AWS

Uuendus: üks mu kolleegidest tõi välja, et t2 on purunev tüüp, välja arvatud juhul, kui teised; see töötab niinimetatud CPU krediitidega: https://aws.amazon.com/ec2/instance-types/#burst

Nii et üldiselt tähendab see, et kas kannatate järjestikuse 2 tunni pikkuse sünteetilise etaloniga (100% CPU kasutamine) drosseldatud jõudluse tõttu või peate maksma vähemalt 5 senti lisatasu eest tunnis, et saada piiramatu CPU-plahvatuse funktsioon t2. Kui te ei tea oma rakenduse omadusi väga hästi, võib see kaasa tuua ettearvamatuid kulusid.

Ma mõtlen, kas oleks võimalik kõiki oma t2 eksemplare iga 23 tunni järel hävitada ja uuesti luua, et saaksin jääda kindlaksmääratud hinnaga, odavalt suure jõudlusega eksemplari ...? (Muidugi, kui rakendus ja taristu seda toetavad.)

3. rühm: Google Compute Engine'i eksemplarid

Vastupidiselt Amazonile pakub Google väga lihtsustatud eksemplaride portfooliot: kas ostate tavalisi või protsessoriga optimeeritud virtuaalseid masinaid - ja see selleks. Isegi protsessori jaoks optimeeritud tähendab, et saate sama standardiseeritud riistvara, kuid eraldades rohkem protsessori südamikke, selle asemel, et anda näiteks rohkem RAM-i.

Tundub, et nad kasutavad väga lihtsat, väga lamedat riistvaraparki ja tõenäoliselt aitab see nende hooldamisel palju. Nad ei ütle teile, mis riistvara teie VM-is töötab, kui teete kassi / proc / cpuinfo, kuid sageduse järgi võite arvata, kuna neil on väidetavalt järgmine portfell:

  • 2,6 GHz Intel Xeon E5 (Sandy Bridge)
  • 2,5 GHz Intel Xeon E5 v2 (Ivy Bridge)
  • 2,3 GHz Intel Xeon E5 v3 (Haswell)
  • 2,2 GHz Intel Xeon E5 v4 (Broadwell)
  • 2,0 GHz Intel Xeon (Skylake)

Kõigil oma testidel sain alati 2,5 GHz mudelit, protsessori teave ütles ainult järgmist: Intel (R) Xeon (R) CPU @ 2,50 GHz. See näib olevat 2013. aasta mudel.

Kuna põhimõtteliselt on ainult 2 tüüpi juhtumeid, oli test väga kiire ja lihtne. Valisin n1-standardi ja n1-highcpu tüübid.

Mõõdistame numbrid!

Kümne sekundi pikkuse mõõtetulemuse tulemus on GCP

Kõik ühetuumalised tulemused olid paremad kui meie füüsiline riistvara (2016 Xeon), kuid ainult pisut. Kui see on tõesti 2013. aasta Xeon, siis vau, kogu lugupidamine Google'i optimeerimise inseneridele!

Meeldetuletuseks: Amazoni jõudluse langus oli 10–24%, kuna tuumade arvu suurendasime. (Välja arvatud väga püsiv t2-juhtum.) Näib, et Google on seni enam-vähem sama.

Üllataval kombel oli kõrge CPU esinemisaste standardist aeglasem. Kuid nagu ma eespool mainisin, on see sama tüüpi riistvara, see on tavalise eksemplariga võrreldes lihtsalt rohkem südamikke kui RAM.

Sarnaselt Amazonile lubab Google jällegi teie protsessori kasutamisel ajutisi piiranguid, ilma et teie vaba arvutusvõimsust kasutataks. Seetõttu vaatame pikaajalisi eesmärke:

15-minutilise võrdlustulemuse GCP

Ilmselt kaotame töökoormuse suurenemisega pidevalt 15–22% jõudlusest. Amazonis oli see 17–27%.

Kahjuks ei näinud ma t2-ga samaväärset eksemplari, see pidi olema n1-standard, kuid see ei tööta kindlasti nagu meie füüsilised masinad.

GCP suhteline jõudlus võrreldes 2016. aasta Xeon E5–2690 v4-gaMitme lõime optimeerimine vs ühe lõimega töövood, GCP

Kokkuvõte: AWS vs GCP

Kui vaadata ainult tooreid esitusi, siis tundub Amazon olevat konkurentsis väga tugev:

CPU suhteline jõudlus, AWS vs GCP võrreldes 2016. aasta Xeon E5–2690 v4-ga

Niisugusest summutatud võrdlusest pole aga kunagi eriti kasu: Amazon pakub palju erinevaid esinemisliike, millel võib olla nõrk protsessor, kuid saate NVMe-välkmäluseadme jne. Mõnikord on see just see, mida vajate. See artikkel räägib siiski ainult töötlemata protsessori jõudlusest, nii et vaatame, kus arve lõpeb:

8 vCPU südamiku tellitavad hinnad, Amazon vs Google

Nüüd näete, et see on palju tasakaalustatum! Sa saad selle, mille eest maksad.

Kui vajate väiksemaid masinaid, võib diagramm tunduda pisut erinev - oletame näiteks kahetuumaliste juhtumite puhul:

2 vCPU südamiku, Amazon vs Google, tellitavad hinnad

Muidugi saate säästa tonni raha, kasutades Amazoni kohapealseid eksemplare (väärtpaberibörsi tüüpi litsentse tasuta arvutusvõimsusel) või eellõikavaid Google'i eksemplare (mida Google võib juhuslikult igal ajal välja lülitada, kuid hiljemalt 24 tunni pärast) . Reaalse tootmiskoormuse jaoks ei ole minu arvates realistlik, et saaksite kogu oma võimete reserveerimisega ohtlike läbirääkimiste teel võita 20–90% allahindlustest.

Realistlik stsenaarium võib olla osta tellitavaid fikseeritud eksemplare teie tavapärase põhitöömahu jaoks ja seejärel automaatseks skaleerida seda spot- / ennetatavate odavate eksemplaridega, kui liiklus on tipptasemel. Ka teie QA-keskkonna jaoks peaks odav olema täiesti korras - kohandage lihtsalt kõiki oma tööriistu, et äkitselt kaovaid virtuaalmasinaid õigesti hallata ja ressursse dünaamiliselt ümber paigutada. Ja loomulikult on pilve eesmärk automaatne skaleerimine: kui teil pole öösel nii palju külastajaid, ei pea te maksma paljude jooksvate eksemplaride eest. Ja see on üks neist asjadest, kus teil on võrreldes traditsiooniliste kohapealsete infrastruktuuridega palju kasu. (Te ei pea ostma +200 füüsilist masinat koos hoolduslepingutega jne ainult seetõttu, et teil on iga päev 2-tunnine maksimum, siis need masinad tarbivad elektrit ainult 40% tühikäigul töötava protsessoriga ...)

Võimalik lisavõimalus: mõlemad pakkujad pakuvad ka pikaajalisi allahindlusi, kui pühendute 12- või 36-kuulisele pidevale kasutamisele.

Lahenduse A või B maksumus on palju keerulisem kui lihtsalt juhuslike esinemisjuhtude tunnihindade kontrollimine, kui hakkate kaaluma kohandatud võrgustamist, salvestusvajadusi, ribalaiust jne. Selle artikli eesmärk oli keskenduda ainult töötlemata arvutusvõimsuse võrdlusele, kuna mul oli puudus ajakohase teabe Internetis.

Peamised erinevused: pilv vs ettevõttesisese protsessori jõudlus

Kui on mõned põhiasjad, siis saime selle võrdluse kindlasti aru:

  • füüsilistel masinatel: kui lisate rohkem protsessori tuuma, saate lineaarselt suurema jõudluse
  • pilveteenuse pakkujate juures oli see vaid osaliselt tõene: rohkemate vCPU-dega suureneb see lineaarselt, kuid füüsilise masina jõudlus kipub teil olema ainult ~ 80% (= peate pilves ostma rohkem CPU-sid)
  • ühe lõimega, ühe protsessori töövoogudes võidavad pilveteenuse pakkujad käed-alla-kätte, kuna neil on kõige kallimad, suurimad protsessorid, mis on ühe keermega väga tugevad

Värskendus: pilveteenuse pakkujate tagasiside

Üks kahest pilveteenuse pakkujast andis meile saavutatud tulemuste kohta otsest tagasisidet. Nad ütlesid, et jõudluse langus tuleneb Hyper Thread-südamike kasutamisest, selle asemel, et kasutada reaalseid, nagu näiteks palja metalli testimisel - kuna füüsilises masinas, kui piirata Docker 8 protsessorituumaga, on teil ikkagi võib-olla veel 12 installitud, valmis OS-i kasutamiseks katkestuste jaoks jne.

Nii tegid nad ettepaneku, et kui meil on füüsiliste masinatega võrdlemiseks vaja 8 reaalset südamikku, peaksime valima 16 tuuma eksemplari, et saada meile reserveeritud tõelised 8 füüsilise protsessori tuuma. Ühest küljest on see absoluutselt mõistlik, teisalt tähendab see ikkagi, et ma peaksin ostma 2x suuruse (ja hinna) eksemplari, et saavutada / ületada ruumide tegelikku toimivust ...

Nende väidete kinnitamiseks tegime samu võrdlusaluseid oma ruumide KVM-klastrisse, määrates 8, 2, 1 vCPU tuuma, just nagu pilves. Siis lihtsalt nende pakutud testimiseks tegime ka vooru +2 vCPU-ga, mis jäeti ainult OS-i.

Tulemused olid kooskõlas meie varasemate mõõtmistega, mis tehti mitte-KVM-i kohapealse riistvaratesti abil:

15-minutilise võrdlustulemuse tulemus on KVM kohapeal

Nagu näete, on see täpselt sama tulemus: kui lisate KVM-i 8x rohkem virtuaalseid südamikke, saate 8x rohkem jõudlust. Mitte ainult 6x rohkem või nii.

Ajapuuduse tõttu tegin just siis Google Cloudis kiire testi, kasutades ülalmainitud meetodit: pakume saadaolevaid südamikke palju üle - seega vajan ma põhimõtteliselt oma rakenduseks vaid 2 südamikku, kuid ostan 8:

15-minutilise võrdlustulemuse kohaselt on GCP üleprognoositud ressurssidega

Jah, see on tõsi, siin sain jõudluse lineaarselt suureneda, nagu ka palja metalli puhul - aga selle eest, et ostsin 2x, 8x jne, rohkem kui see, mida ma algselt maksta tahtsin, samas kui füüsiliste masinate puhul mul seda polnud piirata, isegi KVM-i virtualiseerimisega.

Järgmine samm oleks teha tõeline Java võrdlusalus või mõni muu realistlikum jõudlustesti, kuid siiani saab neid tulemusi juba planeerimisel ja arvutustes kasutada.

Täname, et leidsite aega seda lugeda, loodan, et ka teile oli see kasulik. Jagage julgesti oma mõtteid. Kui teil oleks sarnane mõõdupuu, oleks tore näha, kuidas nad neid tulemusi võrreldavad.