Computing power comparison: mainframe versus Intel Xeon

[Dmitry67]

Кстати, Дмитрий, а что там с загонянием Oracle в VM? Я помню был период когда нам крайне не рекомендовали пихать БД в VM, но у нас был очень busy экземпляр. Вроде уже переросли эту проблему?

У нас эта проблема решилась сама - тот продукт, для которого был реален нужен оракл, сдулся.

[zVlad]

Погода ужасная. Приятного отдыха

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

Что в этом безсмысленного? Обьясни. Я не любитель гадать за других.

[Flash-04]

Что в этом безсмысленного? Обьясни. Я не любитель гадать за других.

а пожалуйста:

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

что ты хотел этим сказать? что у мейнфрейма всегда загрузка CPU - 100%, и I/O - 100%? если нет, то мейнфрем "не загружен"? Так что ли?

Виртуализация как раз и позволяет более эффективно использовать ресурсы hardware, вроде с этим трудно спорить. Конечно будут накладные расходы, но они есть везде. Учитывая что hardware виртуализация есть в x86/x64 (правда последние новости про meltdown и прочаа несколько подкосил), то не очень понятно против чего боремся?

[Flash-04]

Кстати, Дмитрий, а что там с загонянием Oracle в VM? Я помню был период когда нам крайне не рекомендовали пихать БД в VM, но у нас был очень busy экземпляр. Вроде уже переросли эту проблему?

У нас эта проблема решилась сама - тот продукт, для которого был реален нужен оракл, сдулся.

ну да, классика то есть проблема таки была? самое забавное что у нас именно так и решилось - вендор продукта отказался от Oracle и сделал своё БД ядро (правда на MySQL) которое было менее жадным до I/O.

[StrangerR]

Кстати, Дмитрий, а что там с загонянием Oracle в VM? Я помню был период когда нам крайне не рекомендовали пихать БД в VM, но у нас был очень busy экземпляр. Вроде уже переросли эту проблему?

Проблема была только с крабораком ой RAC кластером.

[zVlad]

Что в этом безсмысленного? Обьясни. Я не любитель гадать за других.

а пожалуйста:

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

что ты хотел этим сказать? что у мейнфрейма всегда загрузка CPU - 100%, и I/O - 100%? если нет, то мейнфрем "не загружен"? Так что ли?

...

В принципе я видел отчеты по загрузке мф с горизонтальной линией на уровне 100%. Этот мф считал электрические биллы тебе, мне и всем кто потребляет электроэнергию GTA, а может и всего Онтарио. Его мощность и объем работ так были подогнаны друг под друга, это был самый нижний уровень, модель z9 BC-А01. Процесс чисто пакетный, сеть заданий с условиями и временами выполнения.
Есть вариант capacity-on-demand, когда раз в 4 часа мощность мф меняется в зависимости от статистики нагрузки, т.е. подстраивается под необходимую.
Более реалистичным и эффективным я считаю ситуацию когда на мф дается комплексная нагрузка (смесь) разбитая грубо по партициями со своими смесями грубо дополняюшими друг друга: OLTP с несколькими уровнями SLA, разными степенями важности и параметрами целевых критериев, набор пакетных работ с разными целевыми параметрами времени завершения вплодь до остсутсивия таковых, т.е. без требований у времени завершения, или в терминах WLM discretionary goal. Эти партиции вяжутся в Sysplex с IDR, т.е. параметры партиций могут меняться в зависимости от достижения целей все service classes во всех партициях.
Вот таким только способом можно удерживать загрузку близко с 100% и не только мф но и на любых других платформах, но я знаю что средства о которых я сказал с той функциональностью что я имею в виду есть только на мф, только с z/OS и только в Parallel Sysplex. z/VM такими способностями обладает в гораздо меньшей степени.

[zVlad]

.....
Виртуализация как раз и позволяет более эффективно использовать ресурсы hardware, вроде с этим трудно спорить. Конечно будут накладные расходы, но они есть везде. Учитывая что hardware виртуализация есть в x86/x64 (правда последние новости про meltdown и прочаа несколько подкосил), то не очень понятно против чего боремся?

Я тоже так считал и был в этом уверен пока не изучил достаточно и не поработал с z/OS. Кстати это справедливо для любой платформы, не только мф и z/OS.
Дело в том что распределяя ресурсы между виртуальными машинами мы мало знаем о том что происходит с процессами управляемыми OS виртуальной машины. Т.е. сделать процесс управления адаптивным к состоянию и нуждам процессов внутри машины не возможно, нет информации. Другое дело когда пишится менеджер ресурсов на уровне управления конечных процессов, то в зависимости от заданых целей можно распорядиться ресурсами более эффективно и достичь поставленных целей управления. Для этого еще надо иметь развитую систему квалификации работ, показателей целей и уметь из измерять чтобы сравнивать с задаными. Все это пока есть только в z/OS. Поэтому у вас, на х86, приходится молиться виртуализации, а у нас достаточно грамотно прописать требования SLA в полиси WLM, и следить за PI - Performance Index - для классов сервиса. Значение PI = 1, означает что WLM достиг заданой цели, меньше единицы - перевыполнил, больше единицы - недовыполнил. На основании этого делается перенастройка сервис классов, увеличиваются/уменьшаются те или иные элементы мф: CPU, RAM, I/O Channels.

[Dmitry67]

Есть вариант capacity-on-demand, когда раз в 4 часа мощность мф меняется в зависимости от статистики нагрузки, т.е. подстраивается под необходимую.

Только сейчас я сообразил, какой же это абсурд.

То есть мы вначале хвастаемся, что реальная мощь МФ придушена и используется 1/10 (не помню сколько уже говорилось), потом хвастаемся что загрузка (у этого кусочка) 100% и нет "недогруза". Простите, у вас простой 9/10 машины!

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

[iDesperado]

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

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

[zVlad]

Есть вариант capacity-on-demand, когда раз в 4 часа мощность мф меняется в зависимости от статистики нагрузки, т.е. подстраивается под необходимую.

Только сейчас я сообразил, какой же это абсурд.

То есть мы вначале хвастаемся, что реальная мощь МФ придушена и используется 1/10 (не помню сколько уже говорилось), потом хвастаемся что загрузка (у этого кусочка) 100% и нет "недогруза". Простите, у вас простой 9/10 машины!

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

Никто ничем не хвастался. Я миллион раз говорил что говорю то что есть и если до некоторых долго доходит то я не виноват.
Ты, Дима, верно подметил то о чем я многократно говорил. Но не торопись называть неосознанное абсурдом.
Действительно количество оборудования в стойку мф вставляется гораздо более более крупными кусками (configuration models) чем имеетcя уровней мощности (performance models). В нашем мф с performance model A01 мощность составляет 1/20 одного кора. На самом деле там не менее 6 коров находится, и памяти там больше 32GB что мы можем использовать системами на нем. Это большая глупость, но не абсурд.
Цена за софт на мф с классической нагрузкой - z/OS определяется количеством активизированных MIPS. Наш А01 кроме того что это DR site для основного приложения используется под продакшн систему с базой данных CA-IDMS. Цена за эту бд определяется 50 MIPS-ми мф на котором она у нас используется. Мы могли бы выполнять эту бд на втором нашем мф с 1000 MIPS, но тогда цена за CA-IDMS была бы, условно, в 20 раз больше. Это тоже глупость, но уже вендора который не хочет принимать во внимание что их бд можно выполнять в партиции с 50 MIPS, на мф с 1000 MIPS.
Причем физические конфигурации обоих наших мф абсолютно одинаковые. Performance model на них могла бы быть максимально -Z06 c 4958 MIPS, памяти можно было бы активировать в разы больше (мы заплатили за активированную память), карт ввода-вывода и карт для криптографии (которых у нас нет) тоже можно было бы в разы больше напихать. Короче реальная мощность наших мф в десятки раз вышечем то что оплатили и говоря о 100% нагрузки, около которой мы болтаемся несколько пиковых часов в день, исключая выходные, это лишь про то что в наших мф активированно.

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

[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 её решил очень быстро. Так что не вижу причин жаловаться.