Привет, Хабр!
Мы в ECOMMPAY, помимо прочего, очень любим MySQL и «железные» серверы. MySQL используется как основная СУБД для нашего прода, и, кажется, мы умеем готовить её хорошо для высоких нагрузок. Так же хорошо (а может, и лучше) мы умеем работать с baremetal: они понятно масштабируются, управляются, имеют предсказуемую производительность и стоимость владения. Но кроме эксплуатации, где всё должно быть надёжно и стабильно, есть место и R&D: а как наша нагрузка будет работать в облачной среде, и сколько это будет стоить? А что насчёт альтернативных привычной для многих «Intel x86-64» платформ?
Много копий сломано в борьбе между сторонниками флагманских линеек процессоров компаний Intel и AMD — эта музыка будет вечной, а успехи семейства EPYC только добавляют масла в огонь. Но AMD и Intel выпускают процессоры на давно известной архитектуре x86, от которой больших сюрпризов ждать не приходится. Другое дело ARM — относительно новый игрок на серверном рынке. Тут как раз удачно вышел Graviton2 — второе поколение процессоров от Amazon, которое специально разработали и выпустили для использования в AWS, и мы не удержались.
Когда у AWS появились инстансы на ARM, они наделали много шума. Холодные, быстрые, дешёвые… выберите любые
Вот и проверим.
От редактора: этот пост следовало писать astellar, как непосредственному автору текста и тестирования. Но тогда, вероятно, публикация никогда бы не была закончена, как это часто случается с увлекающимися натурами. Поэтому мне пришлось брать дело в свои руки: ставить дедлайны, вычитывать, править и готовить для читателей.
От редактора: astellar начал статью ещё полгода назад, а совсем недавно, на re:invent 2021 анонсировали процессоры Graviton3. Мы их обязательно протестируем и сравним с предшественниками. Следите за анонсами.
Disclaimer 1: Никакие цифры, выводы или идеи в этой статье не могут являться рекомендациями к действию по построению инфраструктуры вашего проекта и приведены как одно из возможных направлений для дальнейших исследований.
Disclaimer 2: Результаты нагрузочных и стресс-тестов приведены как пример и не могут считаться повторяемыми или быть использованными при расчете производительности вашего приложения и/или инфраструктуры.
Другими словами: в расчете производительности и запаса прочности столько переменных, что авторы не имеют никакого желания отвечать за благополучие вашего прода.
О чем это все?
Одной из ключевых задач при работе в облаке является правильный выбор типа инстанса, если мы говорим о EC2. Количество вариантов огромно, так что с непривычки теряешься. Например на страничке описания типов инстансов в облаке AWS перечислено больше 50(!) различных типов, не говоря уже о том, что внутри каждого типа инстанса спрятана целая линейка различных вариантов нод. Почему так много? Дело в том, что спектр задач, которые решаются сегодняшними приложениями настолько широк, а нагрузки на каждый сервис настолько разные, что не получится ограничиться одним-двумя — даже одним-двумя десятками — типов инстансов. Ограничение будет означать либо переизбыток ресурсов — и значит, бесцельный расход бюджета на эксплуатацию — либо их нехватку, что может негативно сказаться на работе приложения. Поэтому для каждого класса задач создается свой тип виртуальных машин.
Опытные пользователи облачных сервисов скажут, что EC2 — прошлый век, и надо пользоваться Managed services вроде RDS или Aurora DB, если мы говорим о базах данных. Однако, наш опыт использования Managed Services разных облачных провайдеров в суровом продакшене показывает, что на больших нагрузках возникает настолько много подводных камней, неочевидных нюансов и “непредвиденного поведения”, что сравнение “в лоб” будет совершенно бесполезно, а попытка собрать сравнимые тестовые окружения потребует кучу времени, сил, и денег. В общем, мы рады, но как-нибудь в следующий раз, и с доброжелательным спонсором.
Типы инстансов
Типы облачных инстансов сильно различаются: тип процессора, количество и скорость памяти, тип, подключение и пропускная способность дисковой подсистемы и сети, наличие GPU и других аппаратных дополнений. Вопрос о тонкостях применения каждого занял бы по объему, как минимум, половину “Войны и Мира”, а поскольку между написанием статей нужно ещё и успевать работать, различия между каждым из пятидесяти типов мы пока отложим в сторону и начнем с базы, на которой строится любой вычислительный комплекс — с процессора.
От редактора: дальше были примерно пять стадий: энтузиазм, разочарование, тушение пожаров на растущем, как не в себя, продакшене, депрессия и, наконец, текст, который вы сейчас читаете
Что и как тестировать?
Это был первый вопрос на который нужно было ответить, но он же оказался самым простым. Интересно было получить и сравнить производительность чего-то понятного и вещественного. Последние много лет я решаю проблемы производительности БД MySQL, поэтому его и будем тестировать. Выбор версии тоже не составил труда. Официальный дистрибутив MySQL Community Version поддерживает ARM только для восьмой версии и для Red Hat Enterprise Linux и MacOS, поэтому выбор очевиден — тесты гоняли на RHEL8.
Какой бенчмарк использовать? Стандартом считаются TPC-C и TPC-H, тем не менее иногда известность этих инструментов не идет им на пользу, и появляются непроверенные слухи, что некоторые производители могут ориентироваться на их результаты при проектировании чипов. Мы таким слухам не верим и вам не советуем, но, на всякий случай, выбрали не очень известную утилиту sysbench, которая помимо SQL-бенчмарков умеет также тестировать процессор — что для для нас было очень кстати — а так же память и дисковую подсистему.
Какие параметры системы тестировать?
Было очень интересно, как новый процессор ведет себя под высокой нагрузкой, где находится точка насыщения, и как ведет себя система при стрессовой, запредельной нагрузке.
Самое простое, в случае баз данных, это график пропускной способности БД. Он очень хорошо отражает предельную нагрузку на систему и четко показывает пик пропускной способности системы и ее деградацию при дальнейшем росте нагрузки.
Для тестов взяли два типа инстансов: один из “средних” в линейке виртуалок “для повседневного использования”, и самые дорогие и мощные baremetal машины — фактически, выделенные серверы — для определения максимально возможной производительности платформы. Вдобавок, выделенный сервер исключает факторы “шумных соседей”, которые могут сильно влиять на результаты тестов.
Все скрипты тестирования находятся в открытом доступе и доступны по ссылке.
Тестирование
Скорость процессора (синтетический тест)
Тесты процессора показывают скорость ARM в два раза выше при меньшем количестве ядер.
Достаточно неожиданно, согласитесь. Что вообще тут происходит? Sysbench в качестве синтетической нагрузки использует алгоритм нахождения простых чисел. В тесте используются циклы, расчет корней, сравнения и деления по модулю. Очевидно здесь мы измеряем чистую производительность процессора без учета обращения к памяти, поскольку все переменные будут локальными.
Причиной таких результатов могут быть оптимизированные инструкции в ARM-процессорах — когда вместо “честного” деления используется битовый сдвиг. С одной стороны — «срезание углов» и читерство. С другой — x86 всю свою историю не чурается различных «оптимизаций», и что мешало добавить ещё одну — непонятно.
При анализе результатов также стоит учитывать, что не смотря на высокую производительность, которую показала RISC-архитектура, это все же синтетическая нагрузка, поэтому будем считать этот результат комплиментом, но не более.
Global Memory: рандомное чтение
Самое важное, что показывает этот график — это относительная консистентность скорости памяти. Все три платформы (Intel, AMD и ARM) обладают схожими характеристиками по скорости работы памяти на чтение, однако на запись картина совершенно иная.
Global Memory: рандомная запись
Как видим, скорость записи для ARM платформы на порядки выше, с пиковой производительностью в районе 6 одновременных потоков. “Провал” CISC-систем очевиден, но у авторов статьи не хватает технической экспертизы, чтобы найти причину. Оставим пока этот вопрос открытым — обязательно напишите в комментариях, если у вас есть мысли на этот счёт.
Local Memory: рандомное чтение
Local Memory: рандомная запись
Здесь никаких неожиданностей, локальная память консистентна на запись.
Производительность дисковой подсистемы
Как и ожидалось, производительность дисков не зависит от типа процессора, что подтверждается графиками. Девиации при низком количестве потоков связаны с особенностями работы лимитеров EBS. Данные пишутся и читаются блоками по 16k — особенности работы БД MySQL — страница данных InnoDB занимает ровно 16 килобайт и обмен с диском идет блоками кратными 16k.
Единственное существенное отличие мы наблюдаем на записи с форсированием фиксации данных вызовом fsync. ARM платформа начинает деградировать при количестве потоков выше количества ядер (64 для r6g.metal), что в целом ожидаемо — система заходит в красную зону по нагрузке.
Производительность MySQL
Посмотрим, как ведет себя софт, требовательный к производительности системы. Возьмем MySQL 8 (эта версия доступна как для x86, так и для ARM процессоров), и запустим его на инстансах типа 8xlarge (32vCPU, 256Gb RAM). Выполним тестирование на чтение, как наиболее чувствительное к производительности CPU. Данные при этом с запасом помещаются в память, чтобы минимизировать влияние дисковой подсистемы.
Инстансы типа 8xlarge ведут себя вполне адекватно — показывают сходную производительность как на ARM, так и на Intel. При этом стоимость транзакции на ARM-платформе r6g.8xlarge будет ниже — мы об этом ещё поговорим. Отдельно хочется прокомментировать более низкую производительность системы R5a, для которой используются процессоры AMD серии EPYC 7000. У меня нет разумного объяснения такой деградации, поэтому, чтобы сберечь нервы фанатов AMD, дальнейшее тестирование на платформе R5a не проводилось.
Остальные платформы показали больше полумиллиона запросов в секунду. Результат достойный, а можно больше? Как насчет действительно высоких нагрузок?
Производительность Baremetal
Действительно высокие нагрузки подразумевают, что мы не можем позволить себе роскоши “шумных соседей”, поэтому закрываем глаза на ценник и выбираем инстансы с приставкой .metal.
В отличии от обычных виртуалок, baremetal-инстансы дают возможность использовать все ресурсы железа — т.е. фактически это выделенный сервер, управляемый облаком. Запуск такого инстанса требует больше времени, чем обычно, поэтому не волнуйтесь, если придется подождать пару минут.
MySQL Read-Only 100 секунд
MySQL Read-Only 300 секунд
MySQL read/write
На последнем графике видим жесточайшую деградацию производительности MySQL при переходе нагрузки в красную зону — количество одновременно исполняемых запросов больше, чем ядер в системе.
Особенность работы MySQL заключается в том, что каждый запрос обрабатывается одним потоком, и занимает всё ядро, когда не ждет диск или сеть. Поэтому, когда количество активных клиентов превышает количество ядер, на каждое ядро приходится больше одного выполняемого запроса. В этом случае задачи по обслуживанию запросов и блокировок ложатся на ОС.
Почему так происходит?
Изначально MySQL написан для процессоров x86 и стоковая поставка не учитывает особенности работы ARM-процессоров и другого набора инструкций. Для небольших нагрузок деградация несущественна, но при очень высоких внутренняя система блокировок MySQL, которая успешно работает на x86, доставляет серьезные проблемы на ARM. Хотя патчи для MySQL под ARM процессоры существуют, публично доступны и успешно работают на известных авторам инсталляциях, но много ли найдётся желающих держать в продакшене собранный руками MySQL с кастомными патчами на сверхвысоких нагрузках? А если таковые и найдутся — наверняка, с выделенной под это командой — то зачем им идти в публичные облака?
Более простой вариант избежать деградации без пересборки MySQL — выставить параметр innodb_thread_concurrency равным количеству ядер, но это можно рассматривать только как временный вариант, поскольку он препятствует полноценному использованию ресурсов системы.
Повторим, что данная ситуация актуальна только для больших, и очень больших нагрузок, и бОльшая часть пользователей вряд ли столкнётся с такими особенностями, поэтому определяющим фактором для них будет стоимость владения.
Стоимость владения
В AWS есть несколько вариантов аренды вычислительных ресурсов EC2: самый простой — он же и самый дорогой — “On Demand”, или использование по запросу. Вы нажимаете кнопку, и через пару секунд виртуальная машина доступна для работы. Такой способ идеально подходит для краткосрочных проектов — поднял, запустил, прогнал задачу, выключил и забыл — именно так мы и проводили наше тестирование.
Для сравнения возьмем стоимость ноды типа 8xlarge и выделенных серверов (metal).
При сравнимых параметрах 8xlarge разница все же есть. Заключается она в полосе пропускания EBS: 4,750 Mpbs у R5a с процессором AMD; 6,800Mpbs у R5 на Intel; 9000Mpbs у R6g на ARM, и самая большая у самой дорогой R5b на том же самом Intel: целых 20,000Mbps, что логично.
Reserved instances
Очень часто инфраструктура раскатывается не на пару часов и даже не на день-два. В этом случае хочется сэкономить, и AWS здесь один из самых гибких провайдеров. Если вы определились с типом инстансов (в нашем случае R5 или R6G) вы можете сделать так называемый “резерв”: оплатить нужный инстанс на три года вперед и получить его на 60% дешевле чем On Demand. Можно оплатить не сразу, а частями или не на три года, а на год, но и скидка будет поскромнее. Вообще, AWS предоставляет несколько вполне рабочих вариантов по сокращению расходов, но это тема для отдельной статьи (или для беседы с вашим аккаунт-менеджером в AWS — прим. ред.).
Стоимость транзакции
Поскольку для сравнения мы выбрали разные платформы, то и максимальные инстансы у них тоже разные. В этом случае сравнивать эффективность лучше всего по стоимости условной транзакции. Диски мы выбрали одинаковые, поэтому можем позволить себе это сделать. Начнем с вычисления простых чисел (или других задач типа «числодробилка»).
Здесь ARM будет безусловным лидером, предлагая стоимость в 4 раза ниже, чем у старого доброго x86. Выглядит слишком хорошо, чтобы быть правдой. Возьмем стоимость запроса на чтение из таблицы.
А вот тут картина совсем другая. Не сильно оптимизированный под ARM код MySQL показывает средний результат между выделенным сервером типа R5 на Intel Xeon® Platinum 8000 и более дорогим R5b на Intel Xeon Scalable.
Выводы
Как и ожидалось, на реальной нагрузке результаты не столь радужные, и об однозначном лидерстве ARM-платформы говорить не приходится, как и о том, что новая платформа “не взлетела”.
Новый тип инстансов на основе ARM процессора Graviton2 показывает огромный потенциал для CPU-bound нагрузки — бекенды, кроны и любые задачи с математикой, не требующей для расчетов GPU. В этом случае стоимость серверов, обрабатывающих тот же самый объем данных, может быть, как показывают бенчмарки, до четырех раз ниже. Звучит настолько здорово, что хочется задать вопрос: “А где подвох?!”
Подвох в том, что чудес не бывает и законы физики не победить, поэтому в реальной жизни добиться такого результата можно, как мы сами убедились, далеко не во всех случаях. Здесь первый и главный вывод такой: тестируйте свое приложение и инфраструктуру перед тем, как принимать решение о переходе на ARM.
Просто так пересобрать софт под другую платформу (внезапно!) недостаточно, особенно если этот сервис, как например СУБД, использует множество оптимизаций на низком уровне, которые делают код зависимым от платформы. Поэтому, кроме функциональных тестов ваших сервисов на новой платформе, нужно проверять все его компоненты под нагрузкой. Это касается и баз данных и систем управления очередями — там, где процессы и потоки под высокой нагрузкой обмениваются друг с другом данными, причём тестировать лучше всего систему целиком, а не отдельные компоненты. Ну и разумеется, доверять синтетическим тестам, пусть и от уважаемых источников, стоит лишь с очень большими оговорками.
Второй вывод касается дистрибуции MySQL для ARM. Да, платформа относительно новая, тем не менее очень странно видеть, что пакеты MySQL 8й версии (5.7 для ARM отсутствует) не в полной мере реализуют возможности платформы, особенно с учетом наличия необходимых патчей. С чем это связано, авторы гадать не возьмутся, но то, что Oracle активно развивает собственное облако, как бы намекает, что упрощать жизнь конкурентам они явно не собираются.
Вывод третий, обобщающий. Безусловно, не смотря на большое количество оптимизаций в архитектуре x86 и огромное количество разработанного под платформу кода, легаси в несколько десятков лет дает о себе знать, и появление новых процессоров на ARM архитектуре в серверном и десктопном сегменте обозначает границы нового периода в развитии IT-инфраструктуры в целом.
Есть ощущение, что в течение следующих нескольких лет количественное перейдет в качественное, и мы увидим повальную миграцию серверных систем в сторону более дешевых, и при этом более производительных ARM-процессоров, и у разработчиков популярного opensource-софта просто не останется опции не оптимизировать их продукты под “новую” архитектуру. А следом подтянутся и inhouse-разрабы, ну а на долю DBA и системных администраторов останется только поддержка всего этого зоопарка в стабильном состоянии.
Appendix
Код синтетического теста CPU
