Porovnání výkonu procesoru AWS vs GCP vs

Nedávno jsem měl možnost podílet se na projektu, kde jsme museli vyhodnotit poměr ceny a hodnoty různých poskytovatelů cloudu a porovnat jej s existujícím hardwarem v místě instalace. Během našeho výzkumu na internetu jsme zjistili překvapivě malé množství skutečných, užitečných standardů, pokud jde o surový výkon procesoru, a tak jsme se rozhodli vytvořit si vlastní.

Cíl: shromáždit data, která mohou podpořit rozhodnutí o tom, kterého poskytovatele cloudu zvolit, a pomoci přesně, kolik vCPU je třeba koupit v cloudu, když už víte, kolik normálně používáte na fyzickém serveru ve svém vlastním holém kovu životní prostředí.

Toto kolo testování nemá v úmyslu být dokonalé a důkladné, existují profesionální IT časopisy, které to dělají; chtěli jsme mít rychlá a spolehlivá referenční data, která vyhovují našim potřebám. Pokud máte více času, bylo by zajímavé vidět podrobné referenční hodnoty s různými jádry, před / po testech Meltdown-Specter s různým počtem podprocesů / CPU atd.

Metoda

Jako příklad uvedu fyzický server s vlastním hostitelem s nejnovějším modelem Intel Xeon. Všichni účastníci budou různé modely Xeon. Na Amazonu i na Googlu najdete pouze procesory Intel Xeon, doslova nic jiného, ​​a tento trend je v datových centrech téměř stejný.

Testy jsem provedl pomocí Dockerova obrazu známého nástroje sysbench, ale pro srovnání jsem provedl stejné měření jako binární, aniž bych použil Docker. Našel jsem <0,5% rozdíl ve více sériích, takže pro zjednodušení testování a zajištění toho, abychom používali přesně stejnou verzi sysbench se stejnými knihovnami (sysbench 1.0.13 (pomocí balíčku LuaJIT 2.1.0-beta2)), rozhodli jsme se jít all-in na Docker (CE 17.xx stabilní).

Byly použity následující testovací příkazy:

docker run - cpus 1 - rm -ti několikinů / sysbench sysbench cpu --cpu-max-prime = 20000 - threads = 1 - time = 900 run
docker run - cpus 2 - rm -ti několikinů / sysbench sysbench cpu --cpu-max-prime = 20000 --thdsds = 2 - time = 900 run
docker run - cpus 8 - rm -ti několikinin / sysbench sysbench cpu - cpu-max-prime = 20000 --thdsds = 8 - time = 900 run

Čas měření bude

  • 10 sekund, abyste viděli výkon špice a
  • 15 minut k zobrazení skutečného dlouhodobého výkonu.

Budeme porovnávat rychlost procesoru podle událostí za sekundu hodnot výsledků testu.

Na holém kovu jsem provedl několik testů, abych zjistil, zda existuje významný rozdíl v závislosti na použitém operačním systému (a tedy i v jádře): Testoval jsem stejný stroj se stabilním procesorem CoreOS Container Linux (1632.3.0 - jádro 4.14.19) , Ubuntu 14.04 LTS a CentOS 7. Rozdíl byl opět v kategorii chyb měření, takže uvidíme následující operační systémy:

  • na holém kovu: CentOS 7 a CoreOS 1632.3.0
  • na webových službách Amazon: Amazon Linux
  • na platformě Google Cloud Platform: CoreOS 1632.3.0

Skupina 1: fyzické servery

Referenční stroj: procesor Intel XR Xeon® 2016 E5–2690 v4 @ 2,60 GHz.

Foto Igor Ovsyannykov na Unsplash

V nastavení s jedním jádrem a jedním vláknem získáme během krátkého 10sekundového testu 303,13 událostí za sekundu, zatímco test s dlouhým trváním ukázal mírně lepší výkon s 321,84 e / s. Vezmeme 15minutový výsledek jako 100% a porovnáme všechno ostatní s touto hodnotou.

Dále uděláme benchmark na 2 vyhrazených CPU procesorech, pomocí 2 paralelních vláken. Je zajímavé, že nyní se zdá, že rozdíl 10 oproti 900 sekundám je velmi malý: 670,61 vs. 672,89 e / s. Tyto výsledky ukazují, že 2 jádra CPU vs 2 * 1 jádra CPU jsou o 4,54% výkonnější v tomto konkrétním modelu Intel Xeon.

Podobně na 8 vláknech jádra-8 dostáváme 2716,31 událostí za sekundu, což nám dává + 5,50% (nebo 105,50%) výkonu jádra 8 * 1.

Srovnejme to s jinými fyzickými stroji!

Soutěžící:

  • Model CPU Intel® Xeon® 2014 E5–2660 v3 při 2,60 GHz v roce 2014
  • Model 2013 procesoru Intel® Xeon® E5–2658 v2 při 2,40 GHz
  • a pro trochu zábavy, model Intel® Xeon® X3460 @ 2,80 GHz z roku 2009

Jak se očekávalo, čím starší CPU, tím pomalejší bude:

2016 → 2014 → 2013: 321,84 → 308,67 → 284,93 na jednotném základním benchmarku

Nebo v procentech ve srovnání s rokem 2016 Xeon:

100,00% → 95,91% → 88,53% (jednojádrové)
100,00% → 96,36% → 86,55% (dvoujádrové)
100,00% → 95,14% → 86,53% (8jádrové)

Jak vidíte, na fyzických serverech je výkon procesoru lineární s počtem jader a vláken. Výkon n jádra vs. n * 1 jádra je mezi 102–105%, podobně jako u prvního testovaného modelu.

Ale hej, nezmínil jsi v porovnání 4 xeony ?!

* buben * - téměř 10 let Xeon X3450 způsobil neočekávaná překvapení: porazil kecy ze všech novějších bratrů na syntetickém benchmarku s jediným vláknem, když zaznamenal neuvěřitelnou hodnotu 431,13 e / s - to je 133,96% z roku 2016 referenční model. Jo, tehdy vícevláknové zpracování nebylo pro průměrnou aplikaci opravdu věcí.

Samozřejmě, jak se očekávalo, se tato výhoda velmi rychle roztavila, když jsme zvýšili počet vláken nejprve na 2, později na 8: zatímco u dvojjádrového nastavení stále dosahujeme šumivých 127,71% z roku 2016, na 8jádrech 'už výkon jen velkého bratra 73,52% (1996,96 e / s vs 2716,31 e / s). Tento procesor má 8 logických jader, takže s testy nemůžeme dále pokračovat.

Výsledkem je 10sekundový benchmarkový benchmarkVýsledek 15minutového benchmarku na místě

Zajímavé je, že benchmark ukázal stejné výsledky na 20jádrové E5–2658 v2 se 40 vlákny (nebo 40 logických jader, jako v Hyper Threading), se 60 vlákny, 80 vlákny nebo 160 vlákny - a do 40 lineárně se zvýšila: 10 jader bylo 25% výsledku 40 jádrů, 20 jader bylo 50%, 30 jader 75% atd. Takže vypadá, že se shodujete se skutečným počtem logických jader CPU, čímž se zvýší počet podprocesů nad tento počet Z dlouhodobého hlediska vám nic nezískám.

Výnosy z fyzických zkoušek strojů

  • výkon se škáluje lineárně s počtem jader: pokud vložíte více jader, získáte lineárně vyšší výkon
  • u nového modelu Xeon se zdá, že v novém modelu Xeon bude každý rok přibližně + 5% oproti předchozímu roku
  • starý model Xeon z roku 2009 je podstatně silnější na pracovní zátěž s jedním vláknem, ale rychle se ztrácí, jakmile se objeví více vláken
Relativní výkon v porovnání s rokem 2016 Xeon E5–2690 v4Optimalizace s více vlákny vs. pracovní postupy s jedním vláknem, v prostorách

Skupina 2: instance Amazonu EC2

Na platformě AWS máte spoustu různých typů instancí, které můžete přizpůsobit vašim potřebám, takže jsme provedli testy s mnoha z nich. Také jsem zde zahrnul navrhovaný případ použití těchto typů instancí Amazonem:

  • reference: na místě procesor Intel Xeon® E5–2690 v4 @ 2,60 GHz
  • t2 (základní): Intel (R) Xeon (R) CPU E5–2676 v3 @ 2,40 GHz
  • m5 (obecný): procesor Intel® Xeon® Platinum 8175M při @ 2,50 GHz
  • c5 (vysoký procesor): procesor Intel (R) Xeon® Platinum 8124M při 3,00 GHz
  • r4 (high mem): Procesor Intel® Xeon® E5–2686 v4 @ 2,30 GHz
  • i3 (vysoké IOPS): Procesor Intel® Xeon® E5–2686 v4 @ 2,30 GHz

S výjimkou typu t2 (2015) jsou všechny CPU procesory 2016 nebo nejnovější 2017, takže jsou všechny srovnatelné s naším referenčním údajem. Zajímavá vedlejší poznámka: tyto konkrétní modely Xeon Platinum jsou ve skutečnosti šité na míru pro Amazon, nemůžete si je koupit na trhu.

Amazon prodává vCPU, což je podle jemného tisku, logických procesorových jader, s povoleným Hyper Threadingem a nejen skutečných fyzických jader. Tato jádra obvykle nejsou nadměrně zásobována; i když se nejedná o sdílená jádra CPU s nejlepším úsilím, neexistuje žádná záruka, že neprovádějí optimalizace mezi různými uživateli na stejném hostiteli. (U mikro instancí máte možnost zakoupit částečná jádra sdílená mezi více nájemníky za mnohem nižší cenu.)

Tak pojďme na testy! Po provedení stejných měření sysbench jsme při 10 sekundovém krátkém testu dospěli k následujícím hodnotám:

Výsledkem je 10sekundový test špiček, AWS

Už můžete vidět:

  • jednojádrový výkon je mnohem lepší než naše reference, s jedinou výjimkou
  • ale již s 2 vlákny začnete ztrácet 10–25% ve srovnání s fyzickým hardwarem hostovaným samostatně
  • t2 se jeví jako velmi spolehlivý, stabilní příklad s výkonem holého kovu

Nezapomeňte, že Amazon může povolit dočasný nárůst vaší pracovní zátěže bez omezení výkonu procesoru. Proto jsme provedli 15minimální benchmarky:

Výsledky za 15 minut, AWS

Z dlouhodobého hlediska vykazovaly fyzické instance konstantní výkon 105% ve srovnání s výsledky s jedním vláknem.

Opět platí, že t2 funguje jako naše vlastní servery hostované s velmi předvídatelným výkonem.

Zbytek není tak přitažlivý, dokonce i v nejlepším případě prohrajeme ~ 17%, což v případě instancí m5 generického účelu stoupne na ~ 27%. To znamená, že pokud máte ve svém datovém centru 100 jader CPU, musíte si v Amazonu koupit 127 jader vCPU, aby odpovídaly stejnému výkonu.

Relativní výkon AWS ve srovnání s Xeon E5–2690 v4 v roce 2016Optimalizace s více vlákny vs. pracovní postupy s jedním vláknem, AWS

Aktualizace: jeden z mých kolegů zdůraznil, že t2 je prasklý typ, pokud ostatní; pracuje s tzv. „kredity CPU“: https://aws.amazon.com/ec2/instance-types/#burst

Obecně to znamená, že buď budete trpět omezeným výkonem pomocí syntetického benchmarku (100% využití CPU) po sobě jdoucích 2 hodin, nebo budete muset zaplatit minimálně dalších 5 centů za hodinu, abyste získali neomezenou funkci výbuchu CPU t2. Pokud velmi dobře neznáte vlastnosti vaší aplikace, mohlo by to vést k nepředvídatelným nákladům.

Zajímalo by mě, zda by bylo možné zničit a znovu vytvořit všechny mé instance T2 každých 23 hodin, abych mohl zůstat na pevné ceně, levné vysoce výkonné instance ...? (Samozřejmě, pokud ji aplikace a infrastruktura podporuje.)

Skupina 3: instance služby Google Compute Engine

Na rozdíl od Amazonu nabízí Google velmi zjednodušené portfolio příkladů: buď si kupujete standardní nebo optimalizované procesory - a to je vše. Dokonce i CPU-optimalizované znamená, že získáte stejný standardizovaný hardware, ale s přidělením více procesorových jader, místo aby jste například dávali více RAM.

Vypadá to, že používají velmi jednoduchý, velmi plochý hardware park a pravděpodobně jim hodně pomáhá s údržbou. Ve skutečnosti vám neříká, jaký hardware ve vašem virtuálním počítači běží, když děláte kočka / proc / cpuinfo, ale podle frekvence můžete hádat, protože tvrdí, že mají následující portfolio:

  • 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)
  • Intel Xeon 2,0 GHz (Skylake)

Při všech mých testech jsem vždy obdržel model 2,5 GHz, informace o CPU uváděly pouze toto: Procesor Intel (X) Xeon (R) @ 2,50 GHz. Zdá se, že se jedná o model 2013.

Protože existují v zásadě pouze dva druhy případů, byl test velmi rychlý a snadný. Vybral jsem typy n1-standard a n1-highcpu.

Pojďme rozdrtit čísla!

Výsledky 10sekundového testu špiček, GCP

Všechny výsledky jednoho jádra byly lepší než náš fyzický hardware (2016 Xeon), ale jen nepatrně. Jestli je to opravdu rok 2013, pak páni, veškerý respekt k technikům optimalizace Google!

Připomínáme: Amazon zaznamenal 10–24% ztrátu výkonu, když jsme zvýšili počet jader. (S výjimkou velmi konstantní instance t2.) Vypadá to, že Google je doposud víceméně stejný.

Překvapivě, vysoká instance CPU byla ve skutečnosti pomalejší než standardní. Ale jak jsem již zmínil výše, jedná se o stejný typ hardwaru, ve srovnání se standardní instancí je to jen více jader než RAM.

Stejně jako u Amazonu vám Google opět umožňuje dočasně zvýšit využití procesoru, aniž byste omezili dostupnou výpočetní kapacitu. Uvidíme tedy dlouhodobé standardy:

Výsledky za 15 minut, GCP

Jak se zdá, zvyšujeme pracovní zátěž, ztratíme neustále 15–22% výkonu. Na Amazonu to bylo 17–27%.

Tady jsem bohužel neviděl instanci ekvivalentní t2, má to být standard n1, ale rozhodně to nefunguje jako naše fyzické stroje.

GCP relativní výkon ve srovnání s Xeon E5–2690 v4 v roce 2016Optimalizace s více vlákny vs. pracovní postupy s jedním vláknem, GCP

Shrnutí: AWS vs GCP

Když se podíváte pouze na surový výkon, zdá se, že Amazon je v soutěži velmi silný:

Relativní výkon procesoru, AWS vs GCP ve srovnání s Xeon E5–2690 v4 v roce 2016

Takové hloupé srovnání však nikdy není opravdu užitečné: Amazon nabízí spoustu různých typů instancí, které mohou mít slabý procesor, ale dostanete bleskurychlé úložiště NVMe atd. Někdy je to přesně to, co potřebujete. Přesto se tento článek týká pouze prvotního výkonu procesoru, takže se podívejme, kde končí účet.

Ceny na vyžádání pro 8 jader vCPU, Amazon vs Google

Nyní můžete vidět, že je mnohem vyrovnanější! Získáte to, za co platíte.

V případě, že potřebujete menší stroje, může diagram vypadat trochu jinak - řekněme pro dvojí základní instance:

Ceny na vyžádání pro 2 jádra vCPU, Amazon vs Google

Samozřejmě můžete ušetřit tunu peněz pomocí instancí Amazon spotových spotů (burzovní druh licencí na bezplatnou výpočetní kapacitu) nebo preferovaných instancí Google (které může společnost Google kdykoli náhodně vypnout, nejpozději však po 24 hodinách) . Pokud jde o skutečné pracovní vytížení, nepovažuji za realistické, že byste si mohli vyhradit veškerou svou kapacitu nebezpečným vyjednáváním, abyste získali 20–90% slev.

Realistickým scénářem může být nákup fixních instancí na vyžádání pro vaše obvyklé základní pracovní vytížení, a pak je automaticky upravovat pomocí okamžitých / předvídatelných levných instancí, když je nejvyšší provoz. Také pro vaše prostředí QA by levné mělo být dokonale v pořádku - stačí přizpůsobit všechny své nástroje tak, aby správně spravovaly náhle mizející virtuální stroje a dynamicky alokovat zdroje. A samozřejmě cloud je hlavně o automatickém škálování: když v noci nemáte tolik návštěvníků, nemusíte za mnoho běžících instancí platit. A to je jedna z věcí, kde můžete mít velký zisk ve srovnání s tradičními místními infrastrukturami. (Nemusíte kupovat +200 fyzických strojů se smlouvami na údržbu atd. Pouze proto, že máte každý den špičku 2 hodiny, pak tyto stroje spotřebovávají pouze elektřinu s 40% nečinnosti procesoru…)

Můžete mít další možnost: oba poskytovatelé nabízejí také dlouhodobé slevy, pokud se zavazujete k nepřetržitému používání 12 nebo 36 měsíců.

Náklady na řešení A nebo B jsou mnohem složitější, než kdybyste jen kontrolovali náhodné ceny za každou hodinu, když začnete uvažovat o vlastních sítích, požadavcích na úložiště, šířce pásma atd. Tento článek měl za cíl soustředit se pouze na porovnání prvotní výpočetní kapacity, protože jsem zjistil, že chybí aktuálních informací na internetu.

Klíčové rozdíly: výkon CPU v cloudu na místě

Pokud existuje několik klíčových věcí, určitě jsme si tímto porovnáním uvědomili:

  • na fyzických strojích: pokud přidáte více jader CPU, získáte lineárně vyšší výkon
  • zatímco u poskytovatelů cloudu to platilo jen částečně: lineárně se zvyšuje s více vCPU, ale stále máte sklon získat ~ 80% výkon fyzického stroje (= musíte si koupit více CPU v cloudu)
  • na jednořetězcových pracovních procesech s jediným procesorem získávají poskytovatelé cloudových služeb hands-down, protože mají nejdražší a největší CPU, které jsou velmi silné na jedno vlákno

Aktualizace: zpětná vazba od poskytovatelů cloudu

Jeden ze dvou poskytovatelů cloudu nám poskytl přímou zpětnou vazbu o dosažených výsledcích. Řekli, že ztráta výkonu je způsobena použitím jader Hyper Thread, namísto skutečných, jako v testu holého kovu - protože ve fyzickém stroji, když omezíte Docker na 8 procesorových jader, máte stále nainstalováno dalších 12, připraven pro OS k přerušení atd.

Navrhli tedy, že pokud potřebujeme 8 skutečných jader k porovnání s fyzickými stroji, měli bychom se rozhodnout pro 16jádrovou instanci, abychom si pro nás vyhradili skutečně 8 fyzických jader CPU. Jeden na straně, to absolutně dává smysl, na druhé straně to stále znamená, že musím koupit 2x velikost (a cenu) instance, abych dosáhl / překonal skutečný výkon na místě ...

Abychom potvrdili jejich tvrzení, udělali jsme stejná měřítka v našem KVM clusteru v areálu a přiřadili jsme 8, 2, 1 jádra vCPU, stejně jako v cloudu. Pak jsme jen vyzkoušeli, co navrhovali, také jsme udělali kolo s +2 dalšími vCPU, ponechané pouze na OS.

Výsledky byly v souladu s našimi předchozími měřeními z jiných než KVM, testů hardwaru na místě:

Výsledky za 15 minut, KVM v areálu

Jak vidíte, jedná se o přesně stejný výsledek: pokud do KVM vložíte 8x více virtuálních jader, získáte 8x vyšší výkon. Ne více než 6x víc.

Kvůli nedostatku času jsem právě provedl rychlý test v Google Cloud, pomocí výše uvedené metody: overprovision dostupná jádra hodně - tak v podstatě potřebuji pouze 2 jádra pro mou aplikaci, ale já si koupím 8:

Výsledkem 15minutového benchmarku je GCP s nadhodnocenými zdroji

Ano, je to pravda, tady jsem dostal lineární zvýšení výkonu, stejně jako u holého kovu - ale za cenu nákupu 2x, 8x atd. Víc, než jsem původně chtěl zaplatit, zatímco u fyzických strojů jsem to neměl limit, dokonce s virtualizací KVM.

Dalším krokem by bylo provést skutečný Java benchmark nebo nějaký jiný realističtější test výkonu, ale tyto výsledky lze zatím použít při plánování a výpočtech.

Děkuji, že jste si našli čas na přečtení tohoto textu, a doufám, že vám to také připadalo užitečné. Prosím, neváhejte a podělte se o své myšlenky, nebo pokud jste udělali podobný benchmark, bylo by hezké vidět, jak se srovnávají s těmito výsledky.