Computing power comparison: mainframe versus Intel Xeon

[Dmitry67]

Ну то есть мы согласились, что ваша МФ работает с чудовищным недогрузом?

[mskmel]

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

Больший абсурд, это уверенность, что один полностью нагруженный грузовик перевезёт любой груз на свете.

[zVlad]

Ну то есть мы согласились, что ваша МФ работает с чудовищным недогрузом?

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

Добавлю что у IBM есть два класса мф: EC (top class), and BC. У нас BC class мф. В отчете который мы обсуждаем использовался EC class мф. Дима, запомни пожалуйста это чтобы не делать в будущем новых открытий о мф. Спасибо.

[Flash-04]

Цена за софт на мф с классической нагрузкой - z/OS определяется количеством активизированных MIPS. Наш А01 кроме того что это DR site для основного приложения используется под продакшн систему с базой данных CA-IDMS. Цена за эту бд определяется 50 MIPS-ми мф на котором она у нас используется. Мы могли бы выполнять эту бд на втором нашем мф с 1000 MIPS, но тогда цена за CA-IDMS была бы, условно, в 20 раз больше. Это тоже глупость, но уже вендора который не хочет принимать во внимание что их бд можно выполнять в партиции с 50 MIPS, на мф с 1000 MIPS.

ага, вот мы и пришли к пониманию главного: МФ который у вас стоит, он вовсе не ваш, вы его арендуете и платите за потребляемые ресурсы, так? по ценнику IBM

[Dmitry67]

Наша мф нормально загружена в рамках активированных ресурсов, за которые мы платим ИБМ, во время пиковых часов.

И насколько загружена у вас МФ в пиковые часы?

Пока же я понял как переводятся следующий утверждения о МФ:

1. В отличие от x86, МФ прекрасно работает и на 100% нагрузке
Перевод: Как правило МФ сильно придушены, и "100% нагрузка" на самом деле означает всего лишь xx% загрузку железа

2. Даже при 100% нагрузке в МФ есть способы выполнить все SLA, даже если нагрузка растет
Для меня это звучало как магия, но перевод всего лишь:
Если 100% и тормоза, можно смего лишь relax параметров придушивания.

[мухобой]

Это всё монстрообразное архаичное говно давно проиграло x86.

[мухобой]

Если приложения перенести с мф на x86, оно кроме того что быстрее работать будет так и более переносимое станет. Но когда у кого-то появляется такая идея, тут же возникнут инженеры из 19-го века убеждающие, что мф это "золото", а x86 - ширпотреб. И всё останется на своих местах.

[Flash-04]

Пока же я понял как переводятся следующий утверждения о МФ:

+1

[zVlad]

Цена за софт на мф с классической нагрузкой - z/OS определяется количеством активизированных MIPS. Наш А01 кроме того что это DR site для основного приложения используется под продакшн систему с базой данных CA-IDMS. Цена за эту бд определяется 50 MIPS-ми мф на котором она у нас используется. Мы могли бы выполнять эту бд на втором нашем мф с 1000 MIPS, но тогда цена за CA-IDMS была бы, условно, в 20 раз больше. Это тоже глупость, но уже вендора который не хочет принимать во внимание что их бд можно выполнять в партиции с 50 MIPS, на мф с 1000 MIPS.

ага, вот мы и пришли к пониманию главного: МФ который у вас стоит, он вовсе не ваш, вы его арендуете и платите за потребляемые ресурсы, так? по ценнику IBM

Да, мы (наш клиент) МФ рентует. Платим мы не за потребляемыe, а за установленные ресурсы, за, грубо говоря 1000 MIPS в одном МФ и 50 MIPS (конструктивно и конфигурационно они абсолютно одинаковые, различаются только в MIPS и количестве активных кор: 4 и 1.
В любой момент мы может запросить и получить больше MIPS, гигабайт и карт ввода-вывода, если бы это нам понадобилось. Мы можем также уменьшить наши 1000 MIPS до, скажем, 800 MIPS и будем платим меньше.
А по какому еще ценнику можно было бы платить IBM?

[zVlad]

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

Приложение разработанное в Java, где угодно хоть на утюге, может выполняться на МФ в z/OS. Приложение на Java и WebSphere где угодно тоже прекрасно ложится на MF в z/OS. Приложения реляционных бд могут быть портированы в DB2 for z/OS. Приложeния в Linux могут быть портированны на МФ на рaз-два-три вместе с Linux.
Needless to say, что и разработаны такие приложения могут быть на МФ, а затем портированы на x86. Так уж устроен современный мир IT, ничего личного. Только Windows с .Net остается сам по себе на x86.

[zVlad]

Наша мф нормально загружена в рамках активированных ресурсов, за которые мы платим ИБМ, во время пиковых часов.

И насколько загружена у вас МФ в пиковые часы?

Пока же я понял как переводятся следующий утверждения о МФ:

1. В отличие от x86, МФ прекрасно работает и на 100% нагрузке
Перевод: Как правило МФ сильно придушены, и "100% нагрузка" на самом деле означает всего лишь xx% загрузку железа

2. Даже при 100% нагрузке в МФ есть способы выполнить все SLA, даже если нагрузка растет
Для меня это звучало как магия, но перевод всего лишь:
Если 100% и тормоза, можно смего лишь relax параметров придушивания.

Когда мы работали на предыдущем МФ z114 имевшем 5 коров и теже 1000 MIPS (кстати RAM был меньше чем сейчас) то с 9:00 do 15:00 исключая обед загрузка CPU подолгу была 100%. С нынешним zBC12 на 4 корах и 1000 MIPS 100% CPU наблюдается гораздо реже и я полагаю что мы смогли бы удовлетворить SLA с меньшими MIPS, с 800 MIPS - model O03 788 MIPS, например.

МФ прекрасно (но до определенных пределов, естественно) работает на 100% CPU (активизированного CPU) потому что всегда есть работы разной важности что означает что работы меньшей важности могут не удовлетворять SLA (или сля них нет SLA) при 100% CPU busy в то время как работа высокой важности и SLA свои потребности в CPU удовлетворяет в рамках SLA. Или еще проще: высокой важности работа потребляет 90-95% ЦПУ, а работы ниже важности добирают оставшиеся 5-10%, получается 100%.
Это кстати отвечает на твой пункт 2. Мы дважды принимали реальную и не мелкую нагрузку (с Unix серверов с Oracle) на наш МФ когда он еще был z114, недобавляя ни MIPSa ни байта не bit/second. На втором таком добавлении я бил в колокола (как оказалось напрасно) пытаюсь подвигнуть начальство на добавление мощей. Мы тогда добавляли больше 2000 пользователей клиента с других производств где у них был SAP/Oracle на серверах Unix. Все тогда прошло на ура.
Ни о каком "релах параметров придушивания" речь не идет, как ты уже понял.

[zVlad]

Это всё монстрообразное архаичное говно давно проиграло x86.

Анекдот:

Абрам, слышал, что Украина с Россией воюет?
Нет и что там?
Украина потеряла несколько тысяч убитыми и ранеными и просрала полуостров!
А русские что?
Ты не поверишь, они даже на войну не пришли!

[Flash-04]

Влад, во первых это ни к месту. Во вторых ты явно на мой взгляд закрываешь глаза на очевидное, что модель МФ очень проста с точки зрения IBM: ставим клиенту оборудование заведомо более мощное чем ему нужно, а чаржим за нагрузку. С точки зрения клиента это как вроде хорошо, ведь ты вроде как не платишь за неиспользуемое. Но я уверен что IBM тоже не дураки, и тарифная сетка рассчитана на то чтобы железо отбилось многократно даже при частичной загрузке. Отношения к преимуществам архитектуры это не имеет и действительно многое становится ясным.
Опять же с другой стороны мы явно варимся в разных проектах: у вас стандартная по сути задача гонять квери в БД в которой не так много данных. В наших системах потоки данных огромны и постоянно растут. Я как то в беседе с коллегой озвучил что на протяжении 10 лет я видел одну и ту же картину: какую бы мы систему ни взяли, через 3 года она упирается в "потолок".

[zVlad]

Влад, во первых это ни к месту. Во вторых ты явно на мой взгляд закрываешь глаза на очевидное, что модель МФ очень проста с точки зрения IBM: ставим клиенту оборудование заведомо более мощное чем ему нужно, а чаржим за нагрузку. С точки зрения клиента это как вроде хорошо, ведь ты вроде как не платишь за неиспользуемое. Но я уверен что IBM тоже не дураки, и тарифная сетка рассчитана на то чтобы железо отбилось многократно даже при частичной загрузке. Отношения к преимуществам архитектуры это не имеет и действительно многое становится ясным.
Опять же с другой стороны мы явно варимся в разных проектах: у вас стандартная по сути задача гонять квери в БД в которой не так много данных. В наших системах потоки данных огромны и постоянно растут. Я как то в беседе с коллегой озвучил что на протяжении 10 лет я видел одну и ту же картину: какую бы мы систему ни взяли, через 3 года она упирается в "потолок".

Я тебя, или кого другого, ни разу не агитирую за мф. Я просто рассказываю о мф на примере своей работы и знаний мф вообще.

Мы платим не за использование мф вовсе, не за нагрузку. Мы оплачиваем железо сполна, навроде лиза автомобилей нам посчитали плату за, скажем, 5 лет исходя из 10 летней амортизации. Плата эта включает цены за все железки которые мы попросили поставить в бокс, вместе с боксом. MIPS определяют цены за софт: z/OS, DB2, CICS. Эта часть переменная и зависит от установленных MIPS.

Масштаб МФ, как я уже не раз говорил, больше чем 1:1500 (по MIPS, zBC12). Уверен что за три года вы не растете так, вы даже 1:100 не растете. Кстати, как обычно, ты не намекнул в какой именно потолок вы упираетесь через 3 года.

[Flash-04]

То что ты описал, это именно за нагрузку. Иначе какие ограничения?

Про наш "потолок" - очень просто: дали ТЗ, спроектировали систему, собрали, работает. Дальше две ситуации: вендор говорит что система должна справляться на нашем железе, а она дохнет. Так было с предыдущей. Система три раза переползала на все более мощные сервера.
Нынешняя (Splunk) была спроектирована и потолок был известен заранее - 7 Tb в день. Вот только мы уперлись в него раньше чем наступил следующий бюджетный цикл расширения системы. Но технической проблемы нет - просто добавить серверов. Была техническая проблема, Splunk её решил очень быстро. Так что не вижу причин жаловаться.