Computing power comparison: mainframe versus Intel Xeon

[StrangerR]

Кстати да. Серверы свои (обычные Интелы) ИБМ похоронила фактически. Полностью уступив ДЕЛЛу, ХП и китайцам.

[Dmitry67]

Кстати да. Серверы свои (обычные Интелы) ИБМ похоронила фактически. Полностью уступив ДЕЛЛу, ХП и китайцам.

ThinkPadы тоже

[Dmitry67]

Кстати, вот интересная статья:
https://m.habrahabr.ru/post/346884/

Ребята делают inmem db для highload. На чем же?

У системы порядка 10м пользователей. Мы посчитали, что с учетом профиля теле-смотрения, 10М пользователей может дать сотни тысяч RPS на всю систему.

Все тесты проводились в docker контейнере, запущенном на MacBookPro 15", 2016. Гостевая ОС — Ubuntu 16.04 LTS. Чтобы минимизировать влияние сетевого стека, все БД, тестовый микро-бэкенд и обстрел запускались внутри общего контейнера и все сетевые соединения были на localhost.
На контейнер выделено 8GB ОЗУ и все 8 ядер CPU.

[zVlad]

Из статьи на Вики:

OS/2 was used by Trenitalia, both for the desktops at Ticket Counters and for the Automatic Ticket Counters up to 2011. Incidentally, the Automatic Ticket Counters with OS/2 were more reliable than the current ones running a flavor of Windows.

[mskmel]

уже очень скоро банку будет много проще развернуть какой-нибудь apache ignite на 10TB памяти и получить недоступные ораклу скорости, при этом не жертвуя ни ACID ни консистентностью.

Если этот банк - сбербанк с кучей специалистов это всё настроить и поддерживать, то шансы есть. А так банки в США массово на МФ как раз и сидят, потому как вкладывать копейку на замену уже работающего не хотят.
Но даже если open source допишут, до состояния поставил и работает, 10ТБ это совершенно не о чём даже в банках, не говоря о телко, где объёмы на порядки больше. Всё-таки RAM всё еще ужасно дорого из расчёта на 1ГБ.
Но Open Source скорее всего не допишут никогда, над почти всеми есть настройка в виде "Enterprise edition", за которую хотят денег. Много денег!

Вот недавно как раз обсуждалось viewtopic.php?f=2&t=213184&start=25#top

[iDesperado]

Если этот банк - сбербанк с кучей специалистов это всё настроить и поддерживать, то шансы есть. А так банки в США массово на МФ как раз и сидят, потому как вкладывать копейку на замену уже работающего не хотят.
Но даже если open source допишут, до состояния поставил и работает, 10ТБ это совершенно не о чём даже в банках, не говоря о телко, где объёмы на порядки больше. Всё-таки RAM всё еще ужасно дорого из расчёта на 1ГБ.
Но Open Source скорее всего не допишут никогда, над почти всеми есть настройка в виде "Enterprise edition", за которую хотят денег. Много денег!

всякие спарки и хадупы толком не дописали, но они уже отобрали у оракла здоровый кусок пирога в dwh и аналитике. 10ТБ RAM стоит много, много, очень много меньше, чем лицензия оракла, в то время как в 10ТБ большинство билингов телекома влезет. речь то не о архивных данных в бигдате за многие года, а текущий билинг.
так что если не начнут скидывать ценник и на OLTP поле их начнут зажимать точно так же как жмут бигдаты в аналитике. конечно запас прочности у оракла еще на десятилетия, но ...

[mskmel]

всякие спарки и хадупы толком не дописали, но они уже отобрали у оракла здоровый кусок пирога в dwh и аналитике.

DWH у оракла редкостная какашка всегда была. Экзадата это невелировала, но всё равно костыли. Терадата, Нетезза, даже Вертика все кусочки пирога оттяпывают. Пришёл модный Хадуп, здорово, еще один интрумент! Гуглим "Magic Quadrant for Data Warehouse and Data Management Solutions for Analytics" и почему то всё равно в лидерах.

iDesperado, я агностик по отношению к вендорам. Мне аболютно всё равно Оракл это, или Хадуп, или Монго. Каждой задаче свой инструмент.

10ТБ RAM стоит много, много, очень много меньше, чем лицензия оракла

8 ядер, 10ТБ места ЕЕ Oracle Database Cloud Service $3655 в месяц. Это дорого чтоли?!
Половинка экзадаты с лицензиями, хостингом и всем-всем - $60к\месяц, это тоже дорого?
"Крупный нефтегавозый холдинг возьмет в аренду дырокол".

в то время как в 10ТБ большинство билингов телекома влезет. речь то не о архивных данных в бигдате за многие года, а текущий билинг.

Могу об этом поговорить

10ТБ это меньше чем дневные "сырые" данные для тарификации у многих операторов. Помимо тарификации есть еще много-много чего. Например анализ качества работы сети. В далёком 2006м когда работал на не очень крупного оператора были сотни ГБ в день в... Постгресс.

Посмотрите SK Telecom объёмы в 2011м году. Общая тенденция, как понимаете, к существенному росту объёмов. Если у них за это время данных стало больше всего лишь в 2-3 раза - буду сильно удивлён. 7я страничка: http://www.oracle.com/technetwork/datab ... 071393.pdf

Собственно поэтому хочется понять, почему компании у которых действительно большие задачи - не смотрят на МФ, который на бумаге, и по утверждениям прикоснувшихся, просто идеальный интрумент. Блин, поставил на каждый регион по полному МФ и счастье...

[StrangerR]

У нас играются с новыми решениями. Для репортов. Ускорение, сравнивая с Ораклом - в сотни (даже не десятки) раз. А у Оракла все, что не ядро базы данных и не Жаба - дерьмо редкостное и по скорости и по объемам которые она жрет (что говорить, простейшая фигня которая перезапускает базы - тянет на 4 гига всякого хлама на дисках..)

[iDesperado]

Гуглим "Magic Quadrant for Data Warehouse and Data Management Solutions for Analytics" и почему то всё равно в лидерах.

потому что эти квадраты не инсталяции, а доли от бабла рисуют. хадуп же зачастую и без подписки ставят.

8 ядер, 10ТБ места ЕЕ Oracle Database Cloud Service $3655 в месяц. Это дорого чтоли?!
Половинка экзадаты с лицензиями, хостингом и всем-всем - $60к\месяц, это тоже дорого?
"Крупный нефтегавозый холдинг возьмет в аренду дырокол".

очень дорого. хадуп то нефтегазовый холдинг уже взял. не постеснялся.
у малого же бизнеса, что на треть процессора (8 ядер) может посмотреть, в принципе другой взгляд на жизнь.

Посмотрите SK Telecom объёмы в 2011м году. Общая тенденция, как понимаете, к существенному росту объёмов. Если у них за это время данных стало больше всего лишь в 2-3 раза - буду сильно удивлён. 7я страничка: http://www.oracle.com/technetwork/datab ... 071393.pdf

ну так это DWH какого-то мелкого оператора. у крупных телекомов DWH имхо уже тотально на бигдате.

У нас играются с новыми решениями. Для репортов. Ускорение, сравнивая с Ораклом - в сотни (даже не десятки) раз. А у Оракла все, что не ядро базы данных и не Жаба - дерьмо редкостное и по скорости и по объемам которые она жрет (что говорить, простейшая фигня которая перезапускает базы - тянет на 4 гига всякого хлама на дисках..)

у нас тоже. ускорение обалденное, но качество софта ... я думал оракл индусы, но хадупы откровенно из овна и палок собраны. но блин за те же деньги в сотни раз быстрее, а если много стараться, то еще и работает.

[mskmel]

Посмотрите SK Telecom объёмы в 2011м году. Общая тенденция, как понимаете, к существенному росту объёмов. Если у них за это время данных стало больше всего лишь в 2-3 раза - буду сильно удивлён. 7я страничка: http://www.oracle.com/technetwork/datab ... 071393.pdf

ну так это DWH какого-то мелкого оператора.

SK Telecom совсем не мелкий оператор, 30 млн сабскрайберов. Не на много меньше отдельно взятых из амерканской тройки.
Проблемы именно посчитать текущие CDR, даже в реалтайме, нет давно, считали же как-то 20 лет назад, без хадупов и тыщ ядер.

у крупных телекомов DWH имхо уже тотально на бигдате.

Это Ваш ИМХО, далёкий от реалий. Он на всём И вертика, и оракл, и терадата и всё-всё. На то они и крупные, что насобирали зоопарк из технологий. И добавление новых элементов в текущий зоопарк еще больше усложняет модернизацию и изменение функционала. "Взять и переписать" - очень дорого, особенно когда всё меняется в процессе переписывания.

хадуп же зачастую и без подписки ставят.
...
я думал оракл индусы, но хадупы откровенно из овна и палок собраны.

Вы серьёзно думаете, что данные для важной системы положат в софт с таким качеством да еще и без поддержки?

Целый сбербанк уже несколько лет целенаправлено пытается это всё запилить, но пока еще как-то нет результата. Конторы поменьше не смогут себе позволить иметь столько квалифицированных спецов.

Ключевые ERP как работали на Oracle, MS SQL, Hana так и будут еще много лет. Их еще долго переписывать не начнут.
Кто думаете в числе крупнейших клиентов Оракла? Амазон - клауд есть, может позволить лучших специалистов, а как важные данные хранить, так всё по старинке Гугл тоже, свой клауд есть, но Oracle e-Business Suite никуда не делся.

[flip_flop]

flip_flop, пажалуйста, внимательно прочти страницу 13 отчета, о котором мы толкуем, и скажи тебе все там нравится, нет никаких возражений, сомнений. Я не об арифметике говорю, а о сущности, о физическом смысле, особенно в свете того что я говорил ранее о сильно разных параметрах испытуемых установок.
Все приглашаются тоже, естественно, обсудить это.

Хе-хе, раз обещал - надо отвечать. Прочитал, пытался быть внимательным, но сильно времени тратить жалко. Отчёт явно буллшитит, хоть и не то чтобы явно врёт ("никогда не ври, если можно буллшитить").

Отмеченный буллшит:
1) сравнивается МФ как с подобной архитектурой (одиночная машина, scale up), так и с другой (кластер из двух машин, scale out: application server + DB server). Фигуральное масштабирование до 2 ядер относится только для application server, тогда как DB server работает в полной конфигурации. Масштабирование до 2 ядер - буллшит. Но этого и не требовалось, это перебор и издержки.
2) на стр. 13 зачем то умножается пропускная способность на процент утилизации CPU для "delivered MIPS". Не уверен, что они это делают для своих машин, и тем более не понятно, зачем это нужно.

Я что-то ещё упустил?

Тем не менее, простое сравнение одной машинки (server application) с МФ было бы достаточно - сравнение не в пользу МФ (в особенности график 7). Ну да, 8 ГБ мало, но указано что это как бы типовая конфигурация. Не знаю, на МФ не работаю, ничего не могу сказать.

Не надо забывать, что авторы отчётов и статейй - сильно заинтересованные стороны, трудно от них ожидать обьективности, хе-хе. "Vendors speaks"

Как делают нормальные тесты? Например, SPEC CPU (spec. org), или TPC-C, или TOP500/Green500/etc/. Публикуют собственно тесты и приглашают всех принять участие. Фирмы сами, со всеми лучшими спецами, оптимизируют конфигурации, компиляторы, выжимают максимум производительности и публикует результаты. Поэтому и хотелось бы нечто подобного от нашпигованного по максимуму z14 и от нашпигованных по максимуму x86 серверных машинок от HP, Oracle и т.д. Причём мне были бы интересны не кластерные решения (тут как бы "и так всем понятно" [zVlad] ), а SMP, scale up, их тоже есть на х86. "Хотелось бы, но не могу"

По поводу процессоров и их скорости - не стоит принижать ни современные процессоры для z14 МФ ("бегут очень медленно") ни современные х86 процессоры ("застой где-то с 201х года"). Ни то, ни другое не отражает действительности. Я могу очень детально привести аргументы с точки зрения микроэлектроники и немного с точки зрения низкоуровневой архитектуры, но боюсь никому не будет интересны такие детали.

[iDesperado]

SK Telecom совсем не мелкий оператор, 30 млн сабскрайберов. Не на много меньше отдельно взятых из амерканской тройки.
Проблемы именно посчитать текущие CDR, даже в реалтайме, нет давно, считали же как-то 20 лет назад, без хадупов и тыщ ядер.

ну пусть не мелкий, но это другая задача (DWH), на этой задаче хадупы с тыщ ядер уже с успехом подвинули все остальное.

Вы серьёзно думаете, что данные для важной системы положат в софт с таким качеством да еще и без поддержки?

кладут. мало что ли хадупов в банках и телекомах ? канторы попроще и без поддержки кладут.

Целый сбербанк уже несколько лет целенаправлено пытается это всё запилить, но пока еще как-то нет результата. Конторы поменьше не смогут себе позволить иметь столько квалифицированных спецов.

да, конторы поменьше не могут позволить себе исследования и нащупывания подходов как сбер с apache ignite, но когда сбер этот этап пройдет остальным переход станет много дешевле. и повторится у инмемори гридов история аля хадуп, а оракл с идеей "запросы отправляют на стойки памяти" запросто может проиграть. пора ораклу снижать цены.

[zVlad]

......
Отмеченный буллшит:
1) сравнивается МФ как с подобной архитектурой (одиночная машина, scale up), так и с другой (кластер из двух машин, scale out: application server + DB server). Фигуральное масштабирование до 2 ядер относится только для application server, тогда как DB server работает в полной конфигурации. Масштабирование до 2 ядер - буллшит. Но этого и не требовалось, это перебор и издержки.
2) на стр. 13 зачем то умножается пропускная способность на процент утилизации CPU для "delivered MIPS". Не уверен, что они это делают для своих машин, и тем более не понятно, зачем это нужно.

Я что-то ещё упустил?
....

По-моему достаточно чтобы дальше не продолжать и забыть об этом "труде" "компьютерных наук".
Я могу лишь добавить что, не знаю как на х86, но на мф практически любой результат можно улучшить не потратив ни цента, тем более что на первых страницах они честно говорят что никакими оптимизациями на мф не занимались, мол так и заведено. Очередной булшит, кстати.
Такой жe булшит как и про 8 GB RAM. В моделях начала 90х достигалось 9 GB, а в используемых в тесте z10 (2008 года) - 1.5 TB. А в тесте берут 8 GB для теста с базой данных где размер RAM напрямую связан с производительностью даже если всю базу в память на запихать.
Разница в 128 раз по RAM и в 40 раз по cores тебя, похоже, до сих пор не напрягает? А там что под лозунгом "так принято" ввод-вывод зажали до 2 Gb/sec против 8 Gb/sec. И потом на голубом глазу делают вычисления MIPS, которые вообщем то для относительных пропорций между разными мф используется, а не чтобы соотноситься с другими платформами, на которых такого же показателя нет, верно?

[flip_flop]

По-моему достаточно чтобы дальше не продолжать и забыть об этом "труде" "компьютерных наук".

Ok, больше можно не продолжать, но мы продолжаем

Разница в 128 раз по RAM и в 40 раз по cores тебя, похоже, до сих пор не напрягает?

Ну так нам так много твердили что и RAM и cores разные, "золотые" на МФ и "так себе" на х86, приходится брать количеством Ну, а если серьёзно, то надо скорее мерятся сокетами а не ядрами: как распорядится ядрами, кешами, IO внутри процессора - зависит от задачи, архитектуры и истории разработок. А ещё лучше, как я и говорил - меряние конечными машинами, оптимизированными производителями, без буллшита.

Ладно, давай таки больше об этом опусе не продолжать, каких только чудернастых белых статей я не видел

[zVlad]

......
Ok, больше можно не продолжать, но мы продолжаем
.......
Ну так нам так много твердили что и RAM и cores разные, "золотые" на МФ и "так себе" на х86, приходится брать количеством Ну, а если серьёзно, то надо скорее мерятся сокетами а не ядрами: как распорядится ядрами, кешами, IO внутри процессора - зависит от задачи, архитектуры и истории разработок. А ещё лучше, как я и говорил - меряние конечными машинами, оптимизированными производителями, без буллшита.

Ладно, давай таки больше об этом опусе не продолжать, каких только чудернастых белых статей я не видел

Нет уж, раз мы переступили через некорректную интерпретацию недобросовестно полученных результатов и ты перевернул эту страницу, начав новую тему, то я не могу не присоединиться к твоему призыву.
RAM и cores конечно разные, но когда вопрос ставится о производительности, тем более производительности на задачах с базой данных, то в первую очередь влияет размер памятии пропускная способность каналов ввода-вывода. Хотя RAM на мф образует RAIM, т.е. на самом деле каждый байт хранится в нескольких экземплярах, на в обном байте мф памяти хранится восемь информационных битов, так же как и в памяти HP DLxxx и за каждым байтом надо лезть на диски и пропускать этот байт через те каналы, которые развивают разную скорость пропускания битов. Ну и ты не будешь спорить ведь что в 1TB помещается в 128 раз больше данных чем в 8 GB и если данные запрашиваются повторно и их еще не прекрыли новые данные, а такая вероятность всегда есть, и в случае бОльшей памяти вероятность перекрытия данных другими снижается и лезть на диски становится не нужным вообще.
На самом деле мне этот тест как раз показывает насколько же на самом деле мф лучше может распоряжаться наличными ресурсами что даже в такой сильно выигрышной для х8 по мощности ситуации мф не сильно проиграл. Случай с одним пакетным задание можно вынести за скобки - одно задание это вообще не тест. Т.е. предположение что 80 корый и 1 TB МФ разорвал бы НР DLxxx в лоскуты, согласен?

Сокеты операционной системе вообще как бы не важны. Но на мф действительно это учитывается определенным образом. Интересно в ОС для х86 тоже? На машинах с большим количеством коров это учитывать сложнее (если конечно это учитывается).
Меряться можно и не конечными машинами, но делать это надо аккуратно, не обманывая себя. Я предлагал схемы, но мы об этом можем только говорить здесь без выхлопа.

Жаль что ты железячник и некоторые аспекты систем и баз данных не ощущаешь полностью. Дима, от разговора дистанцировался, другие тоже. Тем не менее спасибо тебе за попытку и согласие что обсуждаемый тест не презентативен ни для чего того что декларируется как выводы. У тебя это был список мифов и реальностей где то в начале темы.