Computing power comparison: mainframe versus Intel Xeon

[flip_flop]

Вы хотите сказать, нет подходящих нагрузок? Миллионы х86 ядрышек крутят java, вполне понятная и тестируемая нагрузка.

Нет, я лишь привожу краткий вывод наших прошлых дискуссий. По мнению zVlad-a для МФ нет подходящих тестов, поскольку МФ сияет в зените славы не при пошлой однотипной нагрузке а при неких особенных смешанных нагрузках, для которых тестов не было, нет, и (по моему предвидению) не будет никогда.

Можно zVlad спросить, но это было жёвано - пережёванно много раз. Без консенсуса, к сожалению. Так что я не уверен в новых прениях.

[zVlad]

Сравнение делать по MIPS глупо, согласен, надо брать стандартные тесты и их сравнивать.

Обсуждали уже. Раз сто. Для МФ нет подходящих тестов. Всё, что есть - не подходит, а что подходит - мы не знаем и не узнаем никогда. Аминь.

Нет, это не совсем так. Вы (не Вы лично) ждете и пытаетесь сравнивать делая простые тесты. Вы считаете что именно их простота позволяет понимать что делается. Плюс, ваше понимание сервера предполагает использование сервера для одного сервиса (бд, вебсервер, и т.д.), более того вы эти одиночные сервисы еще и на кластер растянуть пытаетесб.
А мф предназначен для сложной, комплексной нагрузки, когда на одном сервере не один, а много сервисов выполняется - и база данных и сервер приложений и вебсервер. В этом случае связи их происходят не по сети, а напрямую, через память.
В тесте по которому эта тема, если мне память не изменяет (завтра я уточню), тесты с пакетными заданиями и диалоговые выполнялись раздельно, а в реальной жизни, на мф, это все делается одновременно.
Чем нагрузка сложнее и комплекснее тем больше отдача от мф. Чем проще тем отдача меньше. Мы все время анализируем простые нагрузки, такие как принято делать на распределенных системах. Когда будет сделан сложный тест (кем?) тогда картина и проясниться как вы хотите - на тестах. Вам это надо, вы и делайте. Тем кто работает серьезно на мф и так все понятно, им никаких тестов с участием х86 не нужно, они не собираются уходить с мы.
Это нужно тем кто хочет погреть руки на решивших уйти с мф, вот они делают такие тесты. Но фишка в том что решение уходить с мф принимается тоже не по тестам вовсе, как например у нас это происходит.
Остаются только любопытствующие вроде наших, приветовских пикетных жилетах, которые чтобы zVlad-а "завалить" этим интересуются чисто теоритически. Вот эти тесты жля них, для вас ребята.

Спокойной ночи. Да завтра.

[flip_flop]

Тем кто работает серьезно на мф и так все понятно, им никаких тестов с участием х86 не нужно

Спасибо за ответ, старина. Я выделил квинт ессенцию, так сказать. В дидактических целях, для нашей аудитории.

[oshibka_residenta]

Тем кто работает серьезно на мф и так все понятно, им никаких тестов с участием х86 не нужно

Спасибо за ответ, старина. Я выделил квинт ессенцию, так сказать. В дидактических целях, для нашей аудитории.

Хорошо когда можно не сравнивать. У нас вот есть старая система построенная на МФ и новая, постороенная на х86, так что роскоши не сравнивать нет. Некоторые вредные страны хотят чтобы данные пользователей хранились только в локальном датацентре. Поэтому переодически возникает вопрос: на чем строить датацентр- МФ или х86. Решение на МФ оказывается в _сто_ раз дороже. Так наши МФ специалисты не такие гордые как zVlad- скромно смотрят в пол и надеются дожить по пенсии.

[mskmel]

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

Хочется понять, а сколько оно потянет в линейке Amazon>FB>GMail>....>ларёк торгующий пивом? Распределенные системы на х86 тянут всё что надо просто добавлением в топку новых ядер\гигабайт памяти.

Остаются только любопытствующие вроде наших, приветовских пикетных жилетах, которые чтобы zVlad-а "завалить" этим интересуются чисто теоритически. Вот эти тесты жля них, для вас ребята.

Вот зря Вы так. Завалить нет желания совсем.
Хочется понять, почему победили Linux на х86 VM, а не zLinux. Почему java workload живёт массово на x86, а не МФ.
Может в следующем моём месте работы получится организовать POC ребятами из IBM, и таки убедить поменять тыщи винтел на один z14.

[zVlad]

Тем кто работает серьезно на мф и так все понятно, им никаких тестов с участием х86 не нужно

Спасибо за ответ, старина. Я выделил квинт ессенцию, так сказать. В дидактических целях, для нашей аудитории.

Хорошо когда можно не сравнивать. У нас вот есть старая система построенная на МФ и новая, постороенная на х86, так что роскоши не сравнивать нет. Некоторые вредные страны хотят чтобы данные пользователей хранились только в локальном датацентре. Поэтому переодически возникает вопрос: на чем строить датацентр- МФ или х86. Решение на МФ оказывается в _сто_ раз дороже. Так наши МФ специалисты не такие гордые как zVlad- скромно смотрят в пол и надеются дожить по пенсии.

Вы должны помнить мои рассказы о том как один из наших клиентов ушел с МФ. С одним и тем же приложением, от одного и того же вендора. Я приводил подробные данные на чем этот клиент работал пока это был МФ и на чем он стал работать когда ушел. Также я рассказывал что у клиента долго не было ДР и долго (пока не заменили то что им насчитали изначально на установки в разы более мощные, а следовательно и дорогие). Это тоже из разряда сравнений и оно было более адекватное и корректное чем то что мы обсуждаем, я имею в виду от HP. Так что сравнения есть, не надо ля-ля, и их никто не боится, даже наоборот.

Я не знаю Ваших систем, ни старой ни новой, не знаю Ваших МФ специалистов, но могу уверенно сказать что "сто раз дороже" это булшит или чье то лукавство - обман, и как минимум это деньги только на TCA, а не на TCO. Приведите больше данных и я Вам обьясню что не так. Предложите Вашему руководству пригласить меня для проверки и консультации (я готов приехать куда угодно). Причем, на данном уровне, я не утверждаю что в Вашем случае датацентр надо обязательно строить на МФ, а не на х86. Скорее всего в датацентре должно быть и другое, а может быть и только x86, но точнo не вариант "потому что в _сто_ раз дороже".

[zVlad]

...
Хочется понять, почему победили Linux на х86 VM, а не zLinux. Почему java workload живёт массово на x86, а не МФ.
Может в следующем моём месте работы получится организовать POC ребятами из IBM, и таки убедить поменять тыщи винтел на один z14.

Где победили? Как? Крапленные карты в студию.

Я Вам могу рассказать как у нас несколько лет назад такого рода "победа" состоялась, да я это уже и рассказывал в реальном времени.

Несколько (больше десяти) лет назад у нас имплементировали Java приложение - вебморду к нашей ERP системе на МФ. Сначала наш клиент требовал это установить на МФ, провели POC, с ребятами из IBM, все было установленно и работало. Потом была пауза на два-три года, видимо сменилось руководство в отделе CIO клиента (мне как-то по ошибке пришел e-mail, так я в addressee list насчитал больше 20 головов из CIO клиента), была нанята внешняя сила для нового проекта этой Java вебморды, и вот эта вот внешняя сила просто силовым приемом "убедила" нашего клиента ставить вебморду не на МФ, а на Power и AIX.
Как я не пытался переубеждать (а до клиента я естественно добраться не мог, не тот у меня уровень) с фактами на руках - меня просто не слушали, не слушали и все.
Несмотря на зaпрет я создал всю инфраструктуру на МФ (WebSphere), продеплоил и сконфигурировал Java приложение той вебморды, IBM нам дали поиграться zIIP на два месяца. Сам протестировал работу, послал всем URL к вебморде на МФ. Ни одна сука даже не подошла и не попробовала. Причем я это все сделал на МФ на несколько месяцев раньше чем это появилось на Power и AIX - сервера тогда еще долго и мучительно покупали, потом долго и мучительно устанавливали WebSphere и DB2 Connect (платная фишка в случае МФ не нужная в принципе) на AIX, пытались даже меня привлечь - я их послал на х.й, в итоге это делали IBM-вцы.
Мне грозили дисциплинарными мерами вплодь до увольнением за самоуправство. Шутили наверное.
Одной из причин почему не МФ называлось цена zIIP, мол это дорoго. Самое смешное что когда все уже улеглось и мы делали upgrade на то что у нас сейчас - zBC12 - то в конфигурацию нового МФ включили этот zIIP, он есть у нас. Но поскольку у нас нет Java workload, то этот zIIP используется только DB2 нa 2-3% - там немного случаев когда DB2 использует zIIP. В итоге клиент наш купил WebSphere for z/OS ($400 000), zIIP ($40 000) и работает на купленных же Power, AIX, WebSphere for AIX, i DB2 Connect for AIX. Фактически оплатил два комплекта инфраструктуры, а использует один.

Это еще ладно - был период когда серьезно хотели использовать МФ. А обычно про МФ даже не думают - некому и нечем (нет знаний) думать. Вот так и побеждает х86. Это не победы никакие. Я таких "побед" стеснялся бы и не вылазил с ними в приличное, технически образованное общество.

[zVlad]

Тем кто работает серьезно на мф и так все понятно, им никаких тестов с участием х86 не нужно

Спасибо за ответ, старина. Я выделил квинт ессенцию, так сказать. В дидактических целях, для нашей аудитории.

В этой работе настолько много белых ниток (я сейчас пробежался по тексту и просто ужаснулся и удивился насколько надо быть зашоренным чтбы не видеть этих белок ниток и принимать эти тесты всерьез) что никакой вообще ессенции выделить невозможно, кроме одной - если привлечь настоящих спецов по МФ и вырaвнять хотя бы приблизительно некоторые технические параметры сравниваемых установок в первую очередь RАМ (неужели Вы считаете нормальным даже начинать тесты с базой данный на установках с 8 GB и 1 TB RAM? x128 разница!) далее каналы ввода-вывода: 4*2 Gb и 4*8 Gb, которые в случае с 8 GB RAM загасят response time раньше чем наступит 100% CPU busy что и демострируется Figure 2 - там нет 100% CPU busy, следовательно MF держал ввод-вывод. Причем те в среднем 5% каждого из двух CPU могли бы продвинуть TPS в пределах 1 sec response time вперед значительно, но насколько мы никогда не узнаем, Плюс если бы хотя бы 32 GB RAM (с 2013 года это минимум с каким IBM поставляет МФ) попробовали то тоже ТПС ушел бы вперед, опять же насколько мы никогда не узнаем.

Смешанного выполнения CICS+Batch на МФ почему то не делали, а это весьма классический вариант нагрузки МФ. Почему? Кто, что, мешало поставить тест против которого у меня не было бы принципиальных возражений против того что тест нерелевантный для МФ? ИБМ не тестирует, почему HP не протестировал CICS+Batch на MF?

И есче одно замечание по финансовому разделу "исследования". Как я думаю уже показал чисто техническая часть "исследования" не выдерживает элементарной критики (я не все что нашел здесь озвучил). Kакой тогда вообще может быть смысл считать деньги? Нисколько не стоит подключить диски к МФ не через switch, а напрямуы (так кстати уу нас и большенства MF shops сделано. Switch вообще то нужен только для GDPS - geographically dispersed Parallel Sysplex, а уже совсем другая история. RAM как я уже сказал на МФ можно минимум иметь 35 GB по состоянию на следущий за "исследиванием" год, да и вообще могли бы логически ограничить 1 TB ну хотя бы до 128 GB. Хотя все это, конечно, зависит от размера используемой БД, которого я в "исследовании" не нашел.

Самое смешное что кроме варианта RDBMS и Application на одном сервере, что единственно возможно было для МФ, еще не лень было делать тесты x86 когда они раздельны. Зачем? Думаю чтобы показать нерелевантные в принципе 936 TPS.

[mskmel]

Где победили? Как? Крапленные карты в студию.

AWS, Google Cloud, тыщи более мелких public clouds и ни одного МФ.

[flip_flop]

zVlad, одно дело говорить что тесты фиговые и надо было бы провести те же тесты в других, более адекватных условиях. Ну, как в моей области - конкурент N утверждает, что его решения в 100 раз лучше нашего (при этом махлюет на тестах). Мы делаем те же тесты в адекватных условиях и приводим данные, что наше решение в 1.5 раза лучше (ну или всего в 3 раза хуже вместо 100 раз, но мы приводим обьективные данные). Тесты воспроизводимые, любой может вникнуть в детали и прогнать самому.

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

Как говорится, две большие разницы.

[Сабина]

[zVlad]

zVlad, одно дело говорить что тесты фиговые и надо было бы провести те же тесты в других, более адекватных условиях. Ну, как в моей области - конкурент N утверждает, что его решения в 100 раз лучше нашего (при этом махлюет на тестах). Мы делаем те же тесты в адекватных условиях и приводим данные, что наше решение в 1.5 раза лучше (ну или всего в 3 раза хуже вместо 100 раз, но мы приводим обьективные данные). Тесты воспроизводимые, любой может вникнуть в детали и прогнать самому.

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

Как говорится, две большие разницы.

Чтобы такие тесты организовать и провести нужно иметь определенные ресурсы или быть приглашенным на такой тест в качестве спеца. У меня нет таких ресурсов и никто меня на такие тесты как спеца не приглашал.

Тем не менее я никогда не ссылался на магические способности MF, ни одного теста не отвергал, всегда внимательно их изучал и предоставлял свои замечания, которые естественно оставались и будут оставаться пустым звуком для тех кто такие тесты проводит. Воспроизводимых в моих скромных возможностях тестов у меня тоже не было, да никто и не даст мне использовать наши МФ чтобы всерьез их гонять если бы они даже и были бы.

Кстати, по существу моих конкретных замечаний к этому тесту у Вас есть что сказать?

[zVlad]

Где победили? Как? Крапленные карты в студию.

AWS, Google Cloud, тыщи более мелких public clouds и ни одного МФ.

А кто-нибудь пытался? Или хотя бы теоритически рассматривали такой вариант? Ответ нет. Иными словами битвы то и не было.
Да, ИБМ тоже предлагает cloud не на МФ, но ИБМ и cloud на МФ тоже предлагает и утверждает что это хорошо. Никто не делает? Да, нет наверняка кто-нибудь где-нибудь делает. Просто мы (я) об этом не знаем. Мы много чего не знаем.

[mskmel]

А кто-нибудь пытался? Или хотя бы теоритически рассматривали такой вариант? Ответ нет. Иными словами битвы то и не было.

"Одержать сто побед в ста битвах — это не вершина воинского искусства. Повергнуть врага без сражения — вот вершина."

[flip_flop]

Кстати, по существу моих конкретных замечаний к этому тесту у Вас есть что сказать?

Я немного запутался, мы на Вы, или на ты? Мне всё равно, но хотелось бы определиться.

Нет, сказать нечего, я не знаю состояние и особенности МФ на архитектурном/системном/программном уровне, я знаю немного на уровне железа, и всё.

Просто хотелось бы обьективной информации о производительности для какой угодно нагрузки. Есть много всякой разной информации о x86, power, sparc, arm, etc. Каздый производитель берёт тест и выжимает максимум для своих продуктов. Но нет информации для МФ. Мне кажется, сам факт отсутствия таких тестов говорит о многом - МФ слишком тяжелый, дорогой, и закрытый, чтобы гонять на нём тесты. А лёгкие, открытые, дешёвые системы на х86 позволяют легко прогнать огромное число разных тестов.

Тот факт, что битвы за клауды не было, тоже говорит о многом. Без битвы, х86 легко заняли >90% рынка серверных процессоров. Факт, от которого нельза отмахнуться. Можно философствовать о причинах отсутствия битвы, но факт занятия поля боя (даже без битвы) не подвергается сомнению.

Простите Вашего кэпа за тривиальный очевидный пересказ того, что "Волга впадает в Каспийское море"