Comments 45
ну я понимаю маркетинг, но заявлять что сравниваете производительность ARM и x86 в базах данных, но ставить разные диски участникам? Это же в принципе лишено смысла. В сравнении должен быть минимум различий. Одна и та же физически пара накопителей должна переставляться с сервера на сервер для корректного сравнения возможностей именно CPU, а не дисков.
Аналогично по RAM, впрочем я не вижу у вас scale factor, так что от него значение меньше.
Корректный заголовок "погоняем синтетику на наших тарифах", исключив при этом из теста кастомную конфигурацию.
Все диски были nvme u.2 одинакового поколения и тесты гонялись на них, по RAM вся была ddr4, разница по частоте минимальна. Не понял где увидели разные диски?
Объём разный. Особенно на не топовых по объёму моделях это очень часто означает разницу производительности. Иногда кратную.
Ну например, самсунговый PM9A3 https://semiconductor.samsung.com/ssd/datacenter-ssd/pm9a3/ :
объёмом 960гб - 70к IOPS random write, а 1920гб - уже 130к IOPS. Почти двукратно по спецификации. Что там в реальности - тема отдельного вдумчивого теста.
Не всегда объем сильно влияет на IOPS вот пример моей синтетики micron 7450 разного объема не вижу сильной разницы....есть еще примеры
https://i.postimg.cc/SxVqd5Xq/2023-06-08-15-19-01.png
Не всегда, да. Но вы это не указали в статье. Поискал внимательнее, в описании конфигурации вы вообще никак не упоминаете ни модели дисков, ни что они хотя бы одноклассники. Честно не помню, какие диски вы ставите обычно, для нас вы собирали кастомные конфигурации с оговорёнными конкретными моделями дисков под write intensive базы. Но часто если хостер говорит в описании что поставит абстрактное "2 × 960 ГБ SSD NVMe", то на двух одинаковых заказанных одновременно серверах запросто можно увидеть разные диски (а то и на одном сервере две разные модели, привет hetzner'у).
Различие конфигурации должно устраняться или хотя бы подтверждаться тестом, что оно не является значимым фактором для результата тестирования. У вас есть тест, что различие в объёме RAM 192 и 512гб не имеет значения для результата теста? (а про частоту и тайминги вы тоже не писали в статье)
В частности, вы так же не указали, сколько у вас каналов памяти вообще работает. Для того же восьмиканального 6336Y может быть значимым различие, установлено ли 16 модулей по 16гб или 8 по 32гб или максимальным поддерживаемым объёмом одного DIMM (4 по 64? 2 по 128?).
Полностью согласен с Вами, все выше сказанное учту в будущем тесте когда буду сравнивать 2 сокетный АРМ сервер с другими. Если же зашла речь об объективности тестирования, хотелось бы узнать Ваше мнение о том как бы вы осуществили тестирование БД и сравнение?) возможно не TPS а запросы сравнивали бы?
performance testing is the state of art (c)
железо:
поизучать наработки годов этак 2006-2012 overclokers, fcenter, ixbt и других грандов былых времён по части тестовых стендов и методик сравнения различающегося железа. Особенно методики тестирования i7 920 как первого 3-канальника. Какие шишки на нём собрали, как сглаживали эффекты различия объёма, как тестировали изменение числа каналов памяти.
одну и ту же пару дисков переставлять физически в каждый сервер. В начале короткий fio минут на 5 для детектирования аномалий, различия результатов теста между серверами, понятное дело, должно быть минимально. Если это не так - то искать причину.
желательно использовать одну и ту же коллекцию модулей памяти, с проверкой что они стартуют в одинаковом режиме частота&тайминги среди всех участников
влияние разной конфигурации заполнения слотов памяти - идея для тестирования платформы в отдельности, на самом деле. Это лично мне, кстати, действительно интересно - имеет ли значение число каналов памяти кроме как для увеличения максимального объёма памяти. Максимум памяти в реальности не столь актуален для СУБД, даже террабайт RAM очень мало кто ставит, а вот есть ли смысл просить именно задействовать каналы памяти, а не добить до нужного объёма теми модулями что под рукой нашлись?
на разных платформах соответственно дать настолько близкую разбивку модулей по каналам и сокетам насколько получится, различия задокументировать
контроль температуры и троттлинга на протяжении тестов (для серверов тоже не шутка, да, была у нас машинка в ovh (вполне серверный xeon D-2141I, не десктоп), которая под нагрузкой перегревалась и сбрасывала частоту CPU втрое)
ОС:
NUMA. NUMA это проблема. Честно не знаю как сглаживать его артефакты кроме как переключением всей системы в interleave либо сознательно через numactl тестировать только половину сервера. Особое счастье с EPYC'ами, где по 4 NUMA ноды бывает даже в одном сокете.
cpu performance mode. В реальности под базой данных CPU решает выходить из powersafe и поднимать частоту до рабочей довольно поздно (мой опыт - это разница в полтора раза по графикам среднего времени выполнения запросов от веба). Но главное для теста - непостоянно. performance mode нам тоже не даст постоянную рабочую частоту, но куда лучше чем powersafe.
postgres
ох (с)
сейчас я упомянут даже в списках разработчиков postgresql, но понимания как корректно тестировать его производительность стало даже меньше, чем когда я про него даже не знал =)
pgbech - ну, это pgbench. Чистая синтетика, довольно бесполезная сама по себе. А вот что-то полезное моделировать... (за это DBA не любят детей ораклового маркетинга "у нас 10k tps, справится postgres?" - каких именно транзакций-то?)
Разглядел, кстати, затаивщийся в опциях scale factor, с первого раза не признал его в краткой форме. То есть примерно 150гб рабочий набор у вас на начало теста. Боюсь, что на самом деле протестировали менеджер локов и реализацию spinlock нежели собственно производительность запросов: все операции над данными postgres выполняет только в shared_buffers, а он в дефолте аж целых 128МБ. Получается конкурентные процессы активно дрались между собой, чтобы скопировать из page cache системного в shared buffers нужный именно этому процессу блок (памяти явно достаточно во всех случаях, чтобы реально на диск только писать, но не читать). А вот со spinlock'ами на ARM у postgresql действительно не всё хорошо: https://www.postgresql.org/message-id/flat/CAB10pyamDkTFWU_BVGeEVmkc8%3DEhgCjr6QBk02SCdJtKpHkdFw%40mail.gmail.com Скорей всего так до сих пор не оптимальный машинный код и компилируется в GCC для ARM.
Поскольку тестировать хотим CPU, в меньшей мере память и не хотим диск, то стоит поставить shared_buffers гигабайт в 180 (хотя на сотне процессов уже может отвалиться вот тот конфиг на 192гб памяти с OOM), synchronous_commit = off. huge_pages = on на таком объёме памяти уже точно нужен (соответственно в ОС тоже выделить huge pages)
PS: я понимаю почему выбрана модель "специально ничего не настраиваем", в этом есть смысл, но по моему опыту shared_buffers всё-таки пользователи крутят чуть менее чем всегда, думаю полезнее чем дефолтные 128мб тестировать будет.
Благодарю за очень развёрнутый ответ, очень полезная для меня информация, думаю следующий тест буду по вашим рекомендациям делать) по температуре и частоте тоже были мысли писать графики, но время было ограничено. С NUMA тоже экспериментировал с равномерным распределением памяти разницы не увидел, буду изучать дальше.
Если не лень, можно еще почитать TPC, эти ребята уже 30 лет измеряют производительность СУБД на разных боксах (точнее, они придумывают тесты, а по ним уже производители серверов измеряют свои решения). Там сотни всякого интересного можно найти, особенно если посмотреть, как производители оптимизировали свои решения.
PostgreSQL взял самую свежую — 14 версию.
На сегодня актуальная версия 15.3.
если я правильно понял вы сравниваете 1 ядро из 128 Ampere и 1 из 32 Xeon
мне кажется просто выдавать места в зависимости от того, у какой конфигурации больше золота не вполне корректно. Скажем в тесте mysql slap разница между золотом и бронзой — 1%, в sysbench pg score — 30%. Возможно было бы корректней привести к единой шкале и объявить победителем того, у кого больше баллов в сумме или на 100Р
В итоговой таблице в тесте MySQL SLAP все наоборот.
Интересно было бы сравнить на единицу стоимости
думаю придется сравнить 8 ядер Ampere против 1 Intel
Причем тут ядра? Меня в сервере интересует производительность и то, сколько он стоит. Вот и я хочу узнать, сколько один балл стоит у того и у другого сервера. Сколько там ядер и сколько каждое ядро может перемолоть данные — мне глубоко вторично, пока у меня не появляется специфичных задач, в которых эти различия проявляются.
Я бы посоветовал посмотреть на оформление подобных отчетов тут https://www.percona.com/blog/comparing-graviton-arm-performance-to-intel-and-amd-for-mysql-part-3/ - по-моему, они намного легче читаются и "смотрятся".
было бы интересно кроме производительности сравнить энергопотребление и стоимость решений на данных процессорах.
Бесполезные и ни о чем не говорящие тесты. Во-первых - Настройки БД по умолчанию , Вы с таким же успехом могли запустить эти тесты на железе 2010 года и получили бы такие же попугаи. Во-вторых как можно сравнивать разное по конфигурации железо и ожидать хоть каких то результатов для сравнения? Ну как? Это бред.
Настройкой PostgreSQL тоже не занимался
Т.е. будут дефолтные shared memory 128Мб и work memory 4Мб? И зачем тогда 256 Гб памяти в системе, для галочки?
посмотрели TPS в трех режимах — READ, WRITE, MIX
Если READ = простые select-ы, то особой работы cpu нет, это чтение из кеша бд или чтение с диска (через кеш ос).
Если WRITE = простые insert / update, то опять же особой работы cpu нет, это запись в wal и работа с буферами.
Работа cpu будет заметна в запросах с сортировками, агрегациями, аналитическими функциями. Потому без примеров данных и примеров запросов, подобные замеры не имеют особого смысла. Да, что-то измерили, но насколько это будет иметь пользу при выборе железа под нагрузку?
Использовал Ubuntu 22.10
А в чем преимущества перед debian, на основе которого ubuntu и собирается? Вы ведь не десктоп сборку накатываете.
256 Гб и больше памяти в системе из за того что это фиксированные конфигурации, а не кастом или какая-то сборка.
"Работа cpu будет заметна в запросах с сортировками, агрегациями, аналитическими функциями." Можете пожалуйста привести примеры для замеров производительности?
В Ubuntu в общем-то нет ни каких преимуществ за исключением того что она работала стабильнее на АРМ платформе.
Поправьте КДПВ, пожалуйста. 1 560px × 798px PNG на 1.6Мб это негуманно в ленте. Не говоря уже о том, что использовать PNG для фотографии - странно. Сделайте JPG на пару сотен кило и визуально почти ничего не изменится.
Покуда номинальный победитель самый дорогой, его лидерство в рамках теста в известной мере девальвируется. Условная метрика отношения производительности к цене выглядит заметно более интересной, а в ней абсолютный лидер не попадает, как я понял, даже в первую тройку - и это при всего восьми участниках.
Я не буду критиковать методику измерения - она такая, как захотелось автору. У меня, делай я подобный обзорный тест, была бы другая, необязательно лучше или правильнее. Просто понимаем, что были запущены какие-то определенные тесты и они показали какую-то производительность на каждой из систем, вот и все. Вот это мы и сравниваем.
Параллелизм. x86 имеет многопоточность на уровне инструкций (instruction-level parallelism, ILP), что позволяет выполнять несколько инструкций одновременно. ARM, в свою очередь, имеет конвейер команд, который оптимизирован по-другому.
И там, и там есть и конвейер, и суперскалярность. А многопоточность - это все-таки не про конвейер и не про ILP :-)
Кто мощнее в базах данных? Сравниваем производительность БД на серверах с ARM- и x86-процессорами