AWS vs GCP спрямо локалното сравнение на производителността на процесора

Наскоро имах възможността да участвам в проект, в който трябваше да оценим съотношението цена / стойност на различните доставчици на облак и трябваше да го сравня със съществуващия локален хардуер. По време на нашето изследване в Интернет открихме изненадващо малко количество действителни, полезни показатели, когато става въпрос за сурова производителност на процесора, затова решихме да направим своя собствена.

Целта: да се съберат данни, които могат да подкрепят решението кой доставчик на облак да изберете, и да помогнете точно колко vCPU трябва да купите в облака, когато вече знаете колко обикновено използвате на физически сървър във вашия собствен голи метал околен свят.

Този кръг от тестове няма намерение да бъде перфектен и задълбочен, има професионални ИТ списания, които правят това; искахме да имаме бързи и надеждни данни за сравнение, които отговарят на нашите нужди. Ако имате повече време, би било интересно да видите подробни показатели с различни ядра, преди / след тестове на Meltdown-Spectre с различен брой нишки / процесорни ядра и т.н.

Методът

Като ориентир, ще използвам самостоятелно хостван физически сървър с неотдавнашен модел на Intel Xeon. Всички участници ще бъдат различни модели Xeon. Както в Amazon, така и в Google можете да намерите само процесори Intel Xeon, буквално нищо друго, и тази тенденция е почти еднаква в центровете за данни.

Направих тестовете с помощта на изображение на Докер на добре познатия инструмент sysbench, но за сравнение направих същото измерване с двоичния, без да използвам Докер. Открих <0,5% разлика в множество тиражи, така че за да улесним процедурата на тестване и да гарантираме, че използваме същата версия на sysbench със същите библиотеки (sysbench 1.0.13 (използвайки пакет LuaJIT 2.1.0-beta2)), решихме да влезете all-in на Docker (CE 17.xx стабилен).

Използвани са следните тестови команди:

docker run --cpus 1 --rm -ti somenines / sysbench sysbench cpu --cpu-max-prime = 20000 --threads = 1 --time = 900 run
docker run --cpus 2 --rm -ti somenines / sysbench sysbench cpu --cpu-max-prime = 20000 --threads = 2 --time = 900 run
docker run --cpus 8 --rm -ti somenines / sysbench sysbench cpu --cpu-max-prime = 20000 --threads = 8 --time = 900 run

Времето за измерване ще бъде

  • 10 секунди, за да видите шипово изпълнение и
  • 15 минути, за да видите действителната дългосрочна ефективност.

Ще сравним скоростта на процесора по събития на секунда от стойностите на резултатите от теста.

На голия метал направих няколко теста, за да видя дали има значителна разлика на базата на използваната операционна система (и следователно ядрото): Тествах същата машина с стабилна CoreOS Container Linux (1632.3.0 - ядро ​​4.14.19) , Ubuntu 14.04 LTS и CentOS 7. Отново разликата беше категорията грешка в измерването, така че ще видим следните операционни системи:

  • на голия метал: CentOS 7 и CoreOS 1632.3.0
  • в уеб услуги на Amazon: Amazon Linux
  • в облачната платформа на Google: CoreOS 1632.3.0

Група 1: физически сървъри

Референтната машина: 2016-модел Intel (R) Xeon (R) процесор E5–2690 v4 при 2.60GHz.

Снимка на Игор Овсянков на Unsplash

При едноядрена настройка с една нишка по време на кратък тест от 10 секунди получаваме 303,13 събития / секунда, докато дългосрочният тест показа малко по-добра производителност с 321,84 e / s. Ще вземем резултата от 15 минути като 100% и ще сравним всичко останало с тази стойност.

След това ще направим показателя на 2 специални ядра на процесора, използвайки 2 успоредни нишки. Интересното е, че сега разликата на показателя 10 срещу 900 секунди изглежда много малка: 670.61 срещу 672.89 e / s. Тези резултати показват, че 2 CPU ядра срещу 2 * 1 CPU ядра са с 4.54% по-добри в този специфичен модел Intel Xeon.

По същия начин, на 8 ядра-8 нишки, получаваме 2716,31 събития в секунда, което ни дава + 5,50% (или 105,50%) от 8 * 1 процесорното ядро.

Така че нека сравним това с други физически машини!

конкуренти:

  • 2014-модел на Intel (R) Xeon (R) процесор E5–2660 v3 при 2.60GHz
  • 2013-модел на Intel (R) Xeon (R) процесор E5–2658 v2 при 2.40GHz
  • и за малко забавление, модел 2009 на Intel (R) Xeon (R) процесор X3460 @ 2.80GHz

Както се очаква, колкото по-стар е процесорът, толкова по-бавно ще бъде:

2016 → 2014 → 2013: 321.84 → 308.67 → 284.93 на базата на единичната база

Или в проценти, в сравнение с 2016 г. на Xeon:

100.00% → 95.91% → 88.53% (1-ядро)
100.00% → 96.36% → 86.55% (2-ядро)
100.00% → 95.14% → 86.53% (8-ядро)

Както можете да видите, на физическите сървъри производителността на процесора е линейна с броя на ядрата и нишките. Производителността на n ядро ​​срещу n * 1 сърцевина е между 102–105%, подобно на първия тестван модел.

Но ей, не споменахте ли 4 Xeons в сравнение ?!

* барабан * - близо 10-годишният Xeon X3450 предизвика някои неочаквани изненади: той победи глупостите от всички по-нови братя по синтетичния бенчмарк с една нишка, като вкара невероятна стойност от 431.13 e / s - това е 133.96% от 2016 г. референтен модел. Да, тогава многорежещите резби всъщност не бяха нещо за средното приложение.

Разбира се, както се очаква, това предимство се стопява много бързо, тъй като увеличаваме броя на нишките първо до 2, по-късно до 8: докато при двуядрената настройка все още постигаме блестящи 127,71% от референтната 2016 г., на 8-ядра ние вече са само 73.52% производителност на големия брат (1996.96 e / s срещу 2716.31 e / s). Този процесор има 8 логически ядра, така че не можем да продължим по-нататък с тестовете.

Резултатът от 10 секунди на шиповете в помещенияРезултатите от 15-минутната оценка на място

Между другото, интересно е, че бенчмаркът показа същите резултати на 20-ядрената E5-2658 v2 с 40 нишки (или 40 логически ядра, както в Hyper Threading), с 60 нишки, 80 нишки или 160 нишки - и до 40, тя се увеличава линейно: 10 ядрото е 25% от 40-ядрения резултат, 20 ядрото е 50%, 30 ядрото 75% и т.н. Така изглежда, след като съответствате на действителния брой на логическите ядра на процесора, увеличавайки броя на нишките над това няма да ти спечеля нищо в дългосрочен план.

Отнема се от тестовете на физическата машина

  • производителност мащабира линейно с броя на ядрата: ако поставите повече ядра, получавате линейно по-висока производителност
  • изглежда има около + 5% печалба всяка година в новия модел Xeon, в сравнение с предходната година
  • старият модел на Xeon от 2009 г. е значително по-силен при едноредов работен товар, но бързо губи, тъй като се появяват множество нишки
Относителна ефективност в сравнение с 2016 Xeon E5–2690 v4Оптимизация с много нишки спрямо еднопоточни работни процеси в помещения

Група 2: случаи на Amazon EC2

В платформата AWS имате много различни видове екземпляри, които можете да приспособите според вашите нужди, затова направихме тестове с доста от тях. Тук също включих предложения от Amazon случай на използване на тези типове инстанции:

  • справка: локален процесор Intel (R) Xeon (R) E5–2690 v4 при 2.60GHz
  • t2 (основен): Intel (R) Xeon (R) CPU E5–2676 v3 @ 2,40GHz
  • m5 (общо): Intel (R) Xeon (R) платина 8175M процесор @ 2,50GHz
  • c5 (висок процесор): Intel (R) Xeon (R) Platinum 8124M CPU @ 3.00GHz
  • r4 (висока памет): Intel (R) Xeon (R) процесор E5–2686 v4 при 2.30GHz
  • i3 (висок IOPS): Intel (R) Xeon (R) процесор E5–2686 v4 при 2.30GHz

С изключение на базовия t2 тип (2015), всички процесори са 2016 или най-новите модели за 2017 г., така че всички те са сравними с нашата справка. Интересна странична забележка: тези специфични Xeon Platinum модели всъщност са пригодени за Amazon, не можете да ги купите на пазара.

Amazon продава vCPU, което е според финия шрифт, логическите ядра на процесора, с активирана Hyper Threading, а не само от действителните физически ядра. Обикновено тези ядра не се превишават; макар да не са споделени ядра на CPU с най-добри усилия, няма гаранция, че не правят оптимизации между различните потребители на един и същ хост. (С микроинстанциите имате възможност да закупите частични ядра, споделени между множество наематели, за много по-малка цена.)

Така че нека да ходим на тестовете! След като направихме същите измервания на sysbench, стигнахме до следните стойности в 10-секундния кратък тест:

Резултатите от 10-секундния показател за шипове, AWS

Вече можете да видите:

  • едноядрената производителност е много по-добра от нашата референция, само с 1 изключение
  • но вече с 2 нишки, започвате да губите 10-25% в сравнение със самоуправлявания физически хардуер
  • t2 изглежда като много надежден, стабилен екземпляр с изпълнение на голи метали

Не забравяйте, че Amazon може да допусне временни скокове в натовареността ви, без да ограничава скоростта на процесора. Ето защо направихме 15-минутните показатели:

15-минутните резултати от сравнителните показатели, AWS

В дългосрочен план, физическите случаи показват постоянна 105% ефективност в сравнение с резултатите с една нишка.

Отново, t2 действа като нашите собствени хоствани сървъри, с много предсказуема производителност.

Останалото не е толкова привлекателно, дори в най-добрия случай губим ~ 17%, което стига до ~ 27% с m5 ролевите инстанции. Това означава, че ако имате 100 CPU ядра във вашия център за данни, трябва да купите 127 vCPU ядра в Amazon, за да съответства на една и съща производителност.

Относителна производителност на AWS в сравнение с 2016 г. Xeon E5–2690 v4Оптимизация с много нишки спрямо еднопоточни работни процеси, AWS

Актуализация: един от колегите ми изтъкна, че t2 е сменяем тип, освен ако другите; работи с така наречените „CPU кредити“: https://aws.amazon.com/ec2/instance-types/#burst

Така че като цяло това означава, че или ще страдате от намаляване на ефективността от синтетичен бенчмарк (със 100% използване на процесора) за последователни 2 часа, или ще трябва да плащате минимум допълнителни 5 цента на час, за да получите функцията за неограничен CPU срив на t2. Ако не знаете много добре характеристиките на приложението си, това може да доведе до непредвидими разходи.

Чудя се дали би било възможно да се унищожат и пресъздадат всички мои случаи на t2 на всеки 23 часа, така че мога да остана на фиксираната цена, евтин екземпляр с висока производителност ...? (Разбира се, ако приложението и инфраструктурата го поддържа.)

Група 3: Екземпляри на Google Compute Engine

Напротив на Amazon, Google предлага много опростено портфолио от случаи: или купувате стандартни или оптимизирани за процесора виртуални машини - и това е всичко. Дори оптимизираният процесор означава, че получавате един и същ стандартизиран хардуер, но с разпределени повече ядра на процесора, вместо да дадете повече RAM например.

Изглежда, че използват много прост, много плосък хардуерен парк и вероятно много им помага при поддръжката. Те всъщност не ви казват какъв хардуер работи във вашия VM, когато правите cat / proc / cpuinfo, но по честотата можете да предположите, тъй като те твърдят, че имат следното портфолио:

  • 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)

При всичките си тестове винаги получавах 2,5 GHz модел, информацията за процесора казваше само следното: Intel (R) Xeon (R) CPU @ 2.50GHz. Изглежда това е модел от 2013 г.

Тъй като има само основно два вида случаи, тестът беше много бърз и лесен. Избрах типовете n1-стандарт и n1-highcpu.

Нека разбием числата!

Резултатите от 10-секундния сравнителен шип, GCP

Всички едноядрени резултати бяха по-добри от нашия физически хардуер (2016 Xeon), но само леко. Ако наистина е Xeon 2013 г., тогава уау, цялото ми уважение към инженерите за оптимизация на Google!

Като напомняне: Amazon имаше 10–24% загуба на производителност, тъй като увеличихме броя на ядрата. (С изключение на много постоянната инстанция на t2.) Изглежда, че Google е повече или по-малко еднакъв досега.

Изненадващо, високата инстанция на процесора всъщност беше по-бавна от стандартната. Но както споменах по-горе, това е един и същ тип хардуер, това е просто повече ядра от RAM в сравнение със стандартния екземпляр.

Отново, подобно на Amazon, Google ви позволява да имате временни скокове в използването на вашия процесор, без да намалявате наличния си изчислителен капацитет. Затова, нека да видим дългосрочните показатели:

15-минутните резултати от бенчмарка, GCP

Очевидно, като увеличаваме натовареността, ние губим постоянно 15-22% от производителността. В Амазонка тя е била 17–27%.

Тук за съжаление не видях еквивалентен t2 екземпляр, той трябва да е стандарт n1, но определено не се представя като нашите физически машини.

Относителна производителност на GCP в сравнение с 2016 г. Xeon E5–2690 v4Оптимизация с много нишки спрямо еднопоточни работни процеси, GCP

Обобщение: AWS срещу GCP

Когато гледате само суровото представяне, Amazon изглежда много силен в конкуренцията:

Относителна производителност на процесора, AWS спрямо GCP в сравнение с 2016 Xeon E5–2690 v4

Въпреки това, подобно извадено сравнение никога не е наистина полезно: Amazon предлага много различни типове инстанции, които може да имат слаб процесор, но получавате светкавично бързо съхранение на NVMe и т.н. Понякога точно това е необходимо. И все пак тази статия се отнася само за необработената производителност на процесора, така че нека да видим докъде стига сметката:

Цени при поискване за 8 vCPU ядра, Amazon vs Google

Сега можете да видите, че е много по-балансиран! Получаваш това, за което плащаш.

В случай, че имате нужда от по-малки машини, схемата може да изглежда малко по-различно - да речем за екземпляри с две ядра:

Цени при поискване за 2 ядра vCPU, Amazon срещу Google

Разбира се, можете да спестите един брой пари, като използвате инстанции на Amazon на място (борсова вид лицензи за свободен изчислителен капацитет) или предпочтителни екземпляри от Google (които могат да бъдат изключени по всяко време на случаен принцип от Google, но най-късно след 24 часа) , За истинска производствена натовареност не смятам за реалистично, че можете да запазите целия си капацитет чрез опасни сделки, за да спечелите 20–90% отстъпки.

Реалистичен сценарий може да бъде да купите по желание фиксирани екземпляри за обичайното си основно натоварване, след което автоматично го мащабирайте с точни / предсказуеми евтини случаи, когато има пик на трафика. Освен това, за вашата QA среда евтиното трябва да е напълно добре - просто адаптирайте всичките си инструменти, за да управлявате правилно изведнъж изчезващи виртуални машини и да разпределяте ресурси динамично. И разбира се, облакът е свързан с автоматичното мащабиране: когато нямате толкова много посетители през нощта, не е нужно да плащате за много работещи инстанции. И това е едно от нещата, при които можете да имате голяма печалба в сравнение с традиционните локални инфраструктури. (Не е нужно да купувате +200 физически машини с договори за поддръжка и т.н., само защото всеки ден имате 2-часов пик, тогава тези машини консумират електроенергия само с 40% празен процесор ...)

Допълнителна опция, която можете да имате: и двамата доставчици предлагат дългосрочни отстъпки, ако се ангажирате за 12 или 36 месеца непрекъснато използване.

Цената на решение A или B е много по-сложна, отколкото просто проверка на произволни часови цени на инстанции, когато започнете да обмисляте персонализирани мрежи, изисквания за съхранение, честотна лента и др. на актуална информация в Интернет.

Ключови разлики: облачност спрямо локална производителност на процесора

Ако има няколко ключови неща, които определено осъзнахме, като направим това сравнение:

  • на физическите машини: ако добавите повече ядра на процесора, получавате линейно по-висока производителност
  • докато при облачните доставчици това беше само частично вярно: увеличава се линейно с повече vCPU, но все пак сте склонни да получавате ~ 80% производителност на физическа машина (= трябва да купите повече процесори в облака)
  • при еднопоточните работни процеси с един процесор облачните доставчици печелят ръцете надолу, тъй като имат най-скъпите, най-големите процесори, които са много силни в единична нишка

Актуализация: обратна връзка от облачните доставчици

Един от двата облачни доставчика ни даде директна обратна връзка за постигнатите резултати. Те казаха, че загубата на производителност се дължи на използването на Hyper Thread ядра, вместо на истинските, като например в тест за голи метали - защото при физическата машина, когато ограничите Docker до 8 процесорни ядра, все още имате може би още 12 инсталирани, готов за ОС да се използва за прекъсвания и т.н.

Така че те предложиха, че ако имаме нужда от 8 истински ядра, които да сравним с физическите машини, трябва да изберем 16-ядрен екземпляр, за да получим истинските 8 физически ядра на процесора, запазени за нас. От една страна, това е абсолютно смислено, от друга страна, това все още означава, че трябва да купя 2х размера (и цената) на инстанцията, за да постигна / надмине действителната ефективност на помещенията ...

За да валидираме техните претенции, направихме същите показатели на нашия в помещенията KVM клъстер, присвоявайки 8, 2, 1 vCPU ядра, точно както в облака. Тогава само за да тестваме това, което предложиха, направихме и кръг с +2 допълнителни vCPU, оставени само за ОС.

Резултатите бяха в съответствие с предишните ни измервания от локални хардуерни тестове, различни от KVM:

15-минутните резултати от сравнителен анализ, KVM на място

Както можете да видите, това е точно същият резултат: ако поставите 8x повече виртуални ядра в KVM, получавате 8x повече производителност. Не само 6x повече или повече.

Поради липса на време, току-що направих бърз тест в Google Cloud, използвайки гореспоменатия метод: свръхпровизиране на наличните ядра от много - така че в общи линии се нуждая само от 2 ядра за моето приложение, но ще купя 8:

Резултатите от 15-минутния еталон, GCP с преразпределени ресурси

Да, вярно е, тук получих линейно увеличение на производителността, точно както с гол метал - но за цената на закупуване на 2x, 8x и т.н. повече от това, което исках да платя първоначално, докато с физическите машини нямах това лимит, дори при виртуализация на KVM.

Следващата стъпка ще бъде да се направи истински тест за Java или някакъв друг по-реалистичен тест за ефективност, но засега тези резултати могат да се използват вече в планирането и изчисленията.

Благодаря ви, че отделихте време да прочетете това, надявам се и вие да сте го намерили за полезно. Моля, не се колебайте да споделите мислите си, или ако сте направили подобен показател, би било хубаво да видите как те сравняват с тези резултати.