New z14 mainfraime family.

zVlad
Уже с Приветом
Posts: 16196
Joined: 30 Apr 2003 16:43

Re: New z14 mainfraime family.

Post by zVlad »

mskmel wrote: 26 Sep 2017 22:09.....
А как быть тем кто хочет избиваться от "ночного кошмара" тысяч jvm на сотнях прилично загруженных VMs с Линуксом внутри?
specjbb\specint_rate кстати тоже достаточно предсказуемо позволяют оценить производительность новых железок.
А вот это очень просто. Исходите из того что Вам не нужно будет, да это и не реально, перенести все сотни в один момент. Далее, Вы может очень грубо, приблизительно (в этом Вам могут помочь специалисты ИБМ без всяких тестов. Достаточно сообщить на каких мощностях Ваши сотни скачут сейчас) прикинуть мощность МФ. Берете модель в которую падает расчитаная мощность и просите активировать минимальную мощность. Начинаете переносить виртуальные машины, поодиночке или группами, отслеживая загрузку МФ и по мере надобности просите ИБМ активировать больше и больше ресурсов. Делается это на ходу без остановки процессов. Так постепенно дойдете до той мощности что необходима для всей Вашей нагрузки.
Возможны и другие сценарии. Т.е. как Вы поняли не обязательно даже организовывать тестирование чтобы выйти на нужную мощность. МФ весьма гибок в плане выбора мощности, а платить Вы будете за те ресурсы, которые будут использоваться, а не все что внутри есть.
mskmel
Уже с Приветом
Posts: 947
Joined: 24 Sep 2013 05:58
Location: US\GA

Re: New z14 mainfraime family.

Post by mskmel »

zVlad wrote: 27 Sep 2017 01:08 А вот это очень просто. Исходите из того что Вам не нужно будет, да это и не реально, перенести все сотни в один момент. Далее, Вы может очень грубо, приблизительно (в этом Вам могут помочь специалисты ИБМ без всяких тестов. Достаточно сообщить на каких мощностях Ваши сотни скачут сейчас) прикинуть мощность МФ. Берете модель в которую падает расчитаная мощность и просите активировать минимальную мощность. Начинаете переносить виртуальные машины, поодиночке или группами, отслеживая загрузку МФ и по мере надобности просите ИБМ активировать больше и больше ресурсов.
А что если, допустим, в процессе переноса выяснится, что надо еще один МФ "естественно с прайстэгом в миллионы долларов"? И что он не "тянет" то, что может сделать половинка рэка Oracle Exalogic c 704 cores стоимостью "всего" в $600к? Сдавать его назад в trade in, списав на безвозвратные потери труд инженеров?

Вот, пусть и старый, но вполне так научный документ: https://www.intel.com/content/dam/doc/w ... -paper.pdf

z13 топовый это 110,000MIPS, да можно поставить акселераторы, но они сами же себе в ногу выстрелили не сказав это производительность только CP или с ускорителями. Скорость самих ускорителей тоже не ясна.

"Performance tests of an 8-core x86 has shown in excess of 2150 mainframe MIPS equivalent rating.", стоит признать что дока очень старая, х86 за это время стал сильно быстрее. Но будем консервативны и ленивы, 3200MIPS per 8 cores or 400MIPS\core. Т.е. надо 287 ядер, в очень популярных сейчас 22 cores x 2 sockets это меньше 7 серверов. Т.е. надо даже не половинку рэка, а 1/4 с приличным запасом. Она вообще стоит 370к, при этом exalogic не самая оптимальная по цене на MIPS железка.

Если в терминах Cloud - 74 Instances х 4 cores\28GB RAM стоят ~15k\mo или 180к\год. Опять "миллионы долларов" не выходит. И все это без up-front затрат, надо - купил, не надо отдал. На сдачу чтобы протестировать своё приложение - даже звонить никому не надо.

Миф о том что Linux не работает при загрузке 90% - миф. Да, с ростом количества сокетов всё хуже и хуже (МФ не исключение), но на 2х сокетных машинках всё прилично. Да и надо их всего несколько юнитов, чтобы целый шкаф мейнфрейма заменить.
Palych
Уже с Приветом
Posts: 13976
Joined: 16 Jan 2001 10:01

Re: New z14 mainfraime family.

Post by Palych »

mskmel wrote: 27 Sep 2017 02:43 Миф о том что Linux не работает при загрузке 90% - миф.
Я думаю - это не миф, а трюк: в линуксе, в реальных приложениях рньше чем нагрузка дойдёт до 90% ляжет ввод/вывод.
А а нём к тому же CPU принимает гораздо более живое участие.
В МФ CPU - это только CPU, а остальным занимаются отдельные процессоры.
И софт написан соответственно.
Внутри МФ линукс помрёт ёщё быстрее и драматичнее.
User avatar
sfbaguy1
Уже с Приветом
Posts: 1444
Joined: 14 Nov 2004 12:51

Re: New z14 mainfraime family.

Post by sfbaguy1 »

flip_flop wrote: 26 Sep 2017 21:53
Последние чипы и у IBM MF и у интел Xeon построены на подобном техпроцессе (14 нм, ну раззница есть, конечно, но степень интеграции подобна), и там и там довольно много интересных нововведений, но область применения разная. Говорить об убийственном превосхосдстве одного чипа над другим просто глупо, что с одной, что с другой стороны. Оба великолепны, уникальны, но оптимизированы под разные применения.
Говорить о наличии неких вундерваффель в айбиэмовских серверных чипах, конечно же, неуместно. Сингл среад перформанс (CPU bound) у всех современных релевантных чипов одного класса не отличается более чем на 10%. Когда происходит прорыв по новым техпроцессам или архитектуре коров, это может нарушаться, но обычно ненадолго.

Так что да, специфика приминения - там идет война чиповых технологий.
жизнь она и проще и сложней
zVlad
Уже с Приветом
Posts: 16196
Joined: 30 Apr 2003 16:43

Re: New z14 mainfraime family.

Post by zVlad »

mskmel wrote: 27 Sep 2017 02:43 ...
z13 топовый это 110,000MIPS, да можно поставить акселераторы, но они сами же себе в ногу выстрелили не сказав это производительность только CP или с ускорителями. Скорость самих ускорителей тоже не ясна.

...
Просветите, пожалуйста, о каких "ускорителях/акселераторах" идет речь?
MIPS используются только для general purpose CPU, тех что для zOS.
mskmel
Уже с Приветом
Posts: 947
Joined: 24 Sep 2013 05:58
Location: US\GA

Re: New z14 mainfraime family.

Post by mskmel »

zVlad wrote: 27 Sep 2017 12:37 Просветите, пожалуйста, о каких "ускорителях/акселераторах" идет речь?
MIPS используются только для general purpose CPU, тех что для zOS.
zIIP.
mskmel
Уже с Приветом
Posts: 947
Joined: 24 Sep 2013 05:58
Location: US\GA

Re: New z14 mainfraime family.

Post by mskmel »

Palych wrote: 27 Sep 2017 04:55
mskmel wrote: 27 Sep 2017 02:43 Миф о том что Linux не работает при загрузке 90% - миф.
Я думаю - это не миф, а трюк: в линуксе, в реальных приложениях рньше чем нагрузка дойдёт до 90% ляжет ввод/вывод.
А а нём к тому же CPU принимает гораздо более живое участие.
1. Не все задачи IO bound.
2. Если используются не кривые драйвера для китайских SOHO HBA и следовать рекомендациям производителя по конфигурированию HBA\NUMA\OS, то 10-12 GBytes\sec нагрузка практически не заметна на общем фоне, единицы процентов. Больше мне пока неоткуда взять :)
zVlad
Уже с Приветом
Posts: 16196
Joined: 30 Apr 2003 16:43

Re: New z14 mainfraime family.

Post by zVlad »

mskmel wrote: 27 Sep 2017 02:43
zVlad wrote: 27 Sep 2017 01:08 А вот это очень просто. Исходите из того что Вам не нужно будет, да это и не реально, перенести все сотни в один момент. Далее, Вы может очень грубо, приблизительно (в этом Вам могут помочь специалисты ИБМ без всяких тестов. Достаточно сообщить на каких мощностях Ваши сотни скачут сейчас) прикинуть мощность МФ. Берете модель в которую падает расчитаная мощность и просите активировать минимальную мощность. Начинаете переносить виртуальные машины, поодиночке или группами, отслеживая загрузку МФ и по мере надобности просите ИБМ активировать больше и больше ресурсов.
А что если, допустим, в процессе переноса выяснится, что надо еще один МФ "естественно с прайстэгом в миллионы долларов"? И что он не "тянет" то, что может сделать половинка рэка Oracle Exalogic c 704 cores стоимостью "всего" в $600к? Сдавать его назад в trade in, списав на безвозвратные потери труд инженеров?

Вот, пусть и старый, но вполне так научный документ: https://www.intel.com/content/dam/doc/w ... -paper.pdf

z13 топовый это 110,000MIPS, да можно поставить акселераторы, но они сами же себе в ногу выстрелили не сказав это производительность только CP или с ускорителями. Скорость самих ускорителей тоже не ясна.

"Performance tests of an 8-core x86 has shown in excess of 2150 mainframe MIPS equivalent rating.", стоит признать что дока очень старая, х86 за это время стал сильно быстрее. Но будем консервативны и ленивы, 3200MIPS per 8 cores or 400MIPS\core. Т.е. надо 287 ядер, в очень популярных сейчас 22 cores x 2 sockets это меньше 7 серверов. Т.е. надо даже не половинку рэка, а 1/4 с приличным запасом. Она вообще стоит 370к, при этом exalogic не самая оптимальная по цене на MIPS железка.

Если в терминах Cloud - 74 Instances х 4 cores\28GB RAM стоят ~15k\mo или 180к\год. Опять "миллионы долларов" не выходит. И все это без up-front затрат, надо - купил, не надо отдал. На сдачу чтобы протестировать своё приложение - даже звонить никому не надо.

Миф о том что Linux не работает при загрузке 90% - миф. Да, с ростом количества сокетов всё хуже и хуже (МФ не исключение), но на 2х сокетных машинках всё прилично. Да и надо их всего несколько юнитов, чтобы целый шкаф мейнфрейма заменить.
Таких методичек что Вы приводите я прочитал десятки. Конкретно эту можно дальше "Executive summary" не читать потому что уже в нем даются ложные и ошибочные утверждения. Например, "inflexible mainframe servers", и "new processor-intensive workload on 1 or 2 processor z10 BC....".

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

Не вдаваясь в детали я поделюсь лишь одним впечатлением от этой и ей подобных методичек. Все они делают одну и ту же, принципиальную ошибку. Они смотрят на МФ теми же глазами какими смотрят на х86 сервер, и думают о МФ теми же мозгами какими думают о серверах на x86. А это не одно и тоже.
Опять же стараясь оставатся в разумных рамках обьема рассуждений, я хотел бы сегодня поделиться новой для меня мыслью - МФ это сервер серверов серверов (см. ниже в примере) или иначе - МФ это data center (последнее я уже здесь озвучивал не раз). MF не одиночный сервер, выполняющий одиночную нагрузку (методичкa о которой мы говорим явно не учитывало это обстоятельство, наоборот, исходит из того что МФ используется также как сакжем "1.6 GHz Intel Itanium Dual-Core processor 9100 Series").
Те кто считают что МФ такой же сервер как "9100 Series", кто так подходят к задаче переноса работы либо с МФ на x86 либо наоборот с x86 на MF обязательно потерпят фиаско в первом случае будут вынуждены существенно увеличивать мощности "9100 Series" во втором случае их остановит price tag того что они насчитают должен бы быть МФ.

Небольшое упражение с использованием примерa из методички применительно к конфигурации Мф у меня на работе. Из Example 1 в методичке следует что наш MF (~1000 MIPS) может быть заменен на HP Integrity rx86404p 8c.

Что мы имеем на этом нашем МФ:

- две партиции с zOS, DB2, CICS/Cobol и другое в каждой:

- первая партиция - это продакшн системa ERP class OLTP приложения одного из крупнейших производителей электроэнергии Северной Америки с примерно 10 000 employees. Это приложение состоит из серверов бизнес (не только DB) транзакций (5 серверов в одной zOS) и базы данных ~ 4TB, которaя реплицируется on-line со стороны этого МФ в MS SQL . Нагрузка с явными пиками в рабочие дни дневные часы, до обеда и после. В эти пики загрузка CPU доходит do 100%. Среднее время выполнения транзакций меньше 1 сек (это предмет контроля в SLA). Ночью и в выходные МФ практически простаивает. Пользователь работает в режиме 24*7, и любой не плановый останов системы это ЧП с пенальти для нас.

- во второй партиции полный набор Dev's, QA, Training, Sandbox экземпляров этого же ERP class приложения с базами данных (всего 7 БД такой же структуры как и Prod) обновляемыми по данным перодически полностью (QA) и частично (Dev, Training, Sandbox) из Prod DB. У каждого экземпляра приложения свой сервер бизнес транзакций (всего 7 серверов).

Кроме перечисленного этот МФ является DR site для второго нашего MФ(где другое приложение выполняется), т.е в случае потери второго МФ работа с него переносится на этот без изменения его конфигурации (CPU, RAM теже остаются).

Я спокойно поставлю свой дом (соседний сейчас продается за C$1 290 000) против собачей будки что "HP Integrity rx86404p 8c" с тем что делает наш МФ не справится, и пять таких HP не справятся тоже. Десять может быть и справятся, но это будет стоить дороже (если учесть все расходы, а не только цену одного HP помноженную на десять, как обычно поступают мои оппоненты здесь), особенно если учесть что наш МФ в целом загружен меньше чем на 40% и, следовательно, способен выполнять дополнительные работы, и не мало.
zVlad
Уже с Приветом
Posts: 16196
Joined: 30 Apr 2003 16:43

Re: New z14 mainfraime family.

Post by zVlad »

mskmel wrote: 27 Sep 2017 13:59
zVlad wrote: 27 Sep 2017 12:37 Просветите, пожалуйста, о каких "ускорителях/акселераторах" идет речь?
MIPS используются только для general purpose CPU, тех что для zOS.
zIIP.
zIIP ничего не акселeрирует и не ускоряет.. zIIP это отдельный CPU, такой же в точности как GP CPU MF, но используемый только для определенных нагрузок - Java, DB2 utilities, и других, и продающийся за в разы меньшие деньги. zIIP замедляет расходы на ресурсы МФ.
Last edited by zVlad on 27 Sep 2017 14:47, edited 1 time in total.
zVlad
Уже с Приветом
Posts: 16196
Joined: 30 Apr 2003 16:43

Re: New z14 mainfraime family.

Post by zVlad »

sfbaguy1 wrote: 27 Sep 2017 06:35
flip_flop wrote: 26 Sep 2017 21:53
Последние чипы и у IBM MF и у интел Xeon построены на подобном техпроцессе (14 нм, ну раззница есть, конечно, но степень интеграции подобна), и там и там довольно много интересных нововведений, но область применения разная. Говорить об убийственном превосхосдстве одного чипа над другим просто глупо, что с одной, что с другой стороны. Оба великолепны, уникальны, но оптимизированы под разные применения.
Говорить о наличии неких вундерваффель в айбиэмовских серверных чипах, конечно же, неуместно. Сингл среад перформанс (CPU bound) у всех современных релевантных чипов одного класса не отличается более чем на 10%. Когда происходит прорыв по новым техпроцессам или архитектуре коров, это может нарушаться, но обычно ненадолго.

Так что да, специфика приминения - там идет война чиповых технологий.
Из недавнего изучения системного программирования на х86 у меня сложилось впечатление что в нем много лишнего и что он переусложнен. По сравнению с МФ CPU, конечно. Это должно выливаться в неэффективное использование вентилей, что, кмк, и просматривается в размерах кэшей на чипе в сопоставлении с количеством коров и поддержек. В z14 коров стало 10, итак большие кэши увеличились в полтора раза по сравнению с предыдущим z13, у каждого кора появилась своя поддержка криптования, добавились инструкции и другое.
Было бы интересно сопоставить параметры и возможности чипов со сравнимыми количествами вентилей.
Palych
Уже с Приветом
Posts: 13976
Joined: 16 Jan 2001 10:01

Re: New z14 mainfraime family.

Post by Palych »

mskmel wrote: 27 Sep 2017 14:24 10-12 GBytes\sec нагрузка практически не заметна на общем фоне, единицы процентов. Больше мне пока неоткуда взять :)
Это общий фон единицы процентов, или нагрузка CPU связанная с I/O?
mskmel
Уже с Приветом
Posts: 947
Joined: 24 Sep 2013 05:58
Location: US\GA

Re: New z14 mainfraime family.

Post by mskmel »

Palych wrote: 27 Sep 2017 14:48
mskmel wrote: 27 Sep 2017 14:24 10-12 GBytes\sec нагрузка практически не заметна на общем фоне, единицы процентов. Больше мне пока неоткуда взять :)
Это общий фон единицы процентов, или нагрузка CPU связанная с I/O?
нагрузка CPU связанная с I/O
Вот ребята берут 20ГБ\сек и 20MIOPS с одной ноды: https://www.flashgrid.io/2017/02/09/ora ... at-55-gbs/
Я не уверен, что даже 0.1% серверов имеют доступ к такой быстрой подсистеме ввода\вывода.
mskmel
Уже с Приветом
Posts: 947
Joined: 24 Sep 2013 05:58
Location: US\GA

Re: New z14 mainfraime family.

Post by mskmel »

zVlad wrote: 27 Sep 2017 14:26Использование только одного показателя производительности МФ - MIPS это настолько приближенные результаты может дать что воспользовавшийся такой методой пользователь скорее всего попадет пальцем в небо.
Какие метрики надо еще добавить помимо MIPS?
zVlad wrote: 27 Sep 2017 14:26Те кто считают что МФ такой же сервер как "9100 Series", кто так подходят к задаче переноса работы либо с МФ на x86 либо наоборот с x86 на MF обязательно потерпят фиаско в первом случае будут вынуждены существенно увеличивать мощности "9100 Series" во втором случае их остановит price tag того что они насчитают должен бы быть МФ.
Скорее они просто не дойдут до IBM, потому что есть суеверия что МФ дороже, реальность нет специалистов и данных о производительности в открытом доступе.
Пока что я вижу, в каждом запросе на железки, есть специальная страничка с опросником "Если Вам нужен zOS, то объясните почему!".

Говорить о вашей нагрузке не готов ибо количество партиций (а может они не делают ничего) и хранимых ТБ (может быть они не нужны никому) это совсем не надёжные метрики, так же, как и выяснилось, MIPS. OLTP БД о 10ТБ+ с десятками тысяч живых подключенных сотрудников при этом реально используется 5-6 ядер х86 я видел\вижу.
zVlad
Уже с Приветом
Posts: 16196
Joined: 30 Apr 2003 16:43

Re: New z14 mainfraime family.

Post by zVlad »

mskmel wrote: 27 Sep 2017 16:03
zVlad wrote: 27 Sep 2017 14:26Использование только одного показателя производительности МФ - MIPS это настолько приближенные результаты может дать что воспользовавшийся такой методой пользователь скорее всего попадет пальцем в небо.
1. Какие метрики надо еще добавить помимо MIPS?
zVlad wrote: 27 Sep 2017 14:26Те кто считают что МФ такой же сервер как "9100 Series", кто так подходят к задаче переноса работы либо с МФ на x86 либо наоборот с x86 на MF обязательно потерпят фиаско в первом случае будут вынуждены существенно увеличивать мощности "9100 Series" во втором случае их остановит price tag того что они насчитают должен бы быть МФ.
Скорее они просто не дойдут до IBM, потому что есть суеверия что МФ дороже, реальность нет специалистов и данных о производительности в открытом доступе.
2. Пока что я вижу, в каждом запросе на железки, есть специальная страничка с опросником "Если Вам нужен zOS, то объясните почему!".

3. Говорить о вашей нагрузке не готов ибо количество партиций (а может они не делают ничего) и хранимых ТБ (может быть они не нужны никому) это совсем не надёжные метрики, так же, как и выяснилось, MIPS. OLTP БД о 10ТБ+ с десятками тысяч живых подключенных сотрудников при этом реально используется 5-6 ядер х86 я видел\вижу.


1. RAM, IO, количество CPU - одни и те же MIPS можно достичь разным количеством CPU. Какая OS используется - zOS, zVM, zLinux. Есрть и другие ОС заточенные под низкие накладные расходы и высокую производительность на транзакциях.

2. И что в тех опросниках? Я таких не разу не видел, что не удивительно, учитывая чем я занимаюсь. О каких железках речь?

3. Вот буквально сиюминутная статистика с монитора Prod DB2 (если не все сокращения понятны - спрашивайте):

Количество пользователей что-нибудь делавших в течение 15 минутного интервала равно ~ 700.

Code: Select all

>                          THREAD HISTORY BY REPORT INTERVAL
 HARP
+ Report Interval:  15 mins                     Start:   09/27 10:30:00.000000
+ Report Filtered:       NO                       End:   09/27 11:29:59.999999
+
+                                  Dlk/  In-DB2  In-DB2  In-DB2           GetP/
+   Time  Thrds Commit Abort DML   TOut  Elap Tm CPU Tm  Wait Tm  Getpage RIO
+   ----- ----- ------ ----- ----- ----  ------- ------- -------  ------- -----
: _ 11:15 48676  48053   679   33M    2      N/A     N/A     N/A   43708K  .1K
: _ 11:00 46205  45503   770   34M    3      N/A     N/A     N/A   49008K  .1K
: _ 10:45 36828  36179   704   32M    2      N/A     N/A     N/A   39589K 67.5
: _ 10:30 34090  33504   646   31M    6      N/A     N/A     N/A   48759K  .1K
mskmel
Уже с Приветом
Posts: 947
Joined: 24 Sep 2013 05:58
Location: US\GA

Re: New z14 mainfraime family.

Post by mskmel »

zVlad wrote: 27 Sep 2017 16:36 3. Вот буквально сиюминутная статистика с монитора Prod DB2 (если не все сокращения понятны - спрашивайте):
53commites\sec это как бы мало очень. 43k Getpage\sec это где-то 1/5 одного х86 ядра.
Эта база может жить на VM c одним vCPU, ну два на всякий случай "потому что могу".
iDesperado
Уже с Приветом
Posts: 1422
Joined: 28 Nov 2008 17:50

Re: New z14 mainfraime family.

Post by iDesperado »

mskmel wrote: 27 Sep 2017 16:55 53commites\sec это как бы мало очень. 43k Getpage\sec это где-то 1/5 одного х86 ядра.
Эта база может жить на VM c одним vCPU, ну два на всякий случай "потому что могу".
помню мы уже ржали над "ERP" Влада viewtopic.php?p=5993679#p5993679
таких "ERP" мой ноутбук вытянет с десяток, тем более что памяти у меня в ноутбуке больше, плюс ио на SSD
zVlad
Уже с Приветом
Posts: 16196
Joined: 30 Apr 2003 16:43

Re: New z14 mainfraime family.

Post by zVlad »

mskmel wrote: 27 Sep 2017 16:55
zVlad wrote: 27 Sep 2017 16:36 3. Вот буквально сиюминутная статистика с монитора Prod DB2 (если не все сокращения понятны - спрашивайте):
53commites\sec это как бы мало очень. 43k Getpage\sec это где-то 1/5 одного х86 ядра.
Эта база может жить на VM c одним vCPU, ну два на всякий случай "потому что могу".
Я не стану с Вами спорить. Моя цель была показать Вам что система эта используется.

Кроме того Вы явно поняли мою статистику как статистику обо всей совершаемой работе этим МФ, а это далеко не все, не все даже в Prod LPAR, там еще сервера аппликаций работают, которые, как правило, в случае х86 живут на отдельных серверах.

Никакими двумя vCPU на одной VM Вы эту работу не выполните, даже не мечтайте. У нас был пользователь с этим приложением, но раз в несколько меньшим обьемом данных и транзакций. Он ушел на платформу Unix/Oracle и мне известно с каким количеством CPU и RAM они в конце концов смогли выполнять их нагрузку, которая выполнялась на, можно сказать, микроскопическом МФ. Я об этом много рассказывал подробно здесь, Вы вероятно этого не читали.

База данных эта реплицируется на MS SQL server, on-line реплицируется, со стороны MF. Сервер для MS SQL имеет следущие параметры (ничего кроме этой MS SQL на нем больше не стоит): Intel Xeon CPU E5-2650 v3 @ 2.3GHz, 2 sockets, 8 cores, 128 GB RAM. A MF наш с двумя LPAR это 4 "зажатых" CPU (эквивалент одного CPU MF zBC12 на 100% мощности, по MIPS - 1064 MIPS), т.е. фактически наш МФ имеет 1 CPU, и 24 GB RAM в Production LPAR, плюс 8 GB Development LPAR со всеm остальнyм хозяйством этого приложения - итого 32 GB RAM и 1 CPU вот и весь наш MF. 16 каналов ввода-вывода правда надо добавить для полной картины, из которых только 4 используются для дисков.

Я Вам советую взвешивать Ваши торопливые выводы, не к лицу это, уверен, технически грамотному человеку как Вы. Лучше попытайтесь узнать больше о неизвестной Вам технологии. Это только пойдет Вам на пользу.
zVlad
Уже с Приветом
Posts: 16196
Joined: 30 Apr 2003 16:43

Re: New z14 mainfraime family.

Post by zVlad »

iDesperado wrote: 27 Sep 2017 17:41
mskmel wrote: 27 Sep 2017 16:55 53commites\sec это как бы мало очень. 43k Getpage\sec это где-то 1/5 одного х86 ядра.
Эта база может жить на VM c одним vCPU, ну два на всякий случай "потому что могу".
помню мы уже ржали над "ERP" Влада viewtopic.php?p=5993679#p5993679
таких "ERP" мой ноутбук вытянет с десяток, тем более что памяти у меня в ноутбуке больше, плюс ио на SSD
Смех без причины ...сами знаете что. Кстати, спасибо тебе, не поленился дал возможность сравнить что было три года назад и сейчас. Правда там другой диапазон дня показан, но тоже в пиковое время и похоже нагрузка выросла за три года.

Тебе, iDesperado, не лень копаться в прошлых записях, найди, пожалуйста, для mskmel про сервера на которые ушел наш клиент с микроскопического МФ. Там они Unix/Oracle стали использовать вместо zOS/DB2, помнишь? Посмеемся все вместе. А?
iDesperado
Уже с Приветом
Posts: 1422
Joined: 28 Nov 2008 17:50

Re: New z14 mainfraime family.

Post by iDesperado »

zVlad wrote: 27 Sep 2017 17:55 Смех без причины ...сами знаете что. Кстати, спасибо тебе, не поленился дал возможность сравнить что было три года назад и сейчас. Правда там другой диапазон дня показан, но тоже в пиковое время и похоже нагрузка выросла за три года.
да какая разница, если у тебя пользователи работает с буферным пулом в 3.3Gb
BP Hit % - Random = 86.7%
BP Hit % - Sequential = 66.6%

т.е. пользователи долбят одни и те же данные, умещающиеся в 3.3 Gb. почти наверняка то не пользователи, а роботы счетчики электричества просто обновляют. реальных людей 3 бухгалтера, один CEO.
эту нагрузку мой рабочий ноутбук 4 ядра i5, 16Gb и SSD потянет несколько раз.
zVlad wrote: 27 Sep 2017 17:55 Тебе, iDesperado, не лень копаться в прошлых записях, найди, пожалуйста, для mskmel про сервера на которые ушел наш клиент с микроскопического МФ. Там они Unix/Oracle стали использовать вместо zOS/DB2, помнишь? Посмеемся все вместе. А?
давай, это моя любимая байка ! ведь именно там после двух месяцев клоунады я все же вытянул аутпут с консоли и выяснилось, что переехали они на LPAR в 16 vcpu, т.е. половинку от процессора Power6. я целый год без смеха привет не мог открыть
Last edited by iDesperado on 27 Sep 2017 18:20, edited 1 time in total.
mskmel
Уже с Приветом
Posts: 947
Joined: 24 Sep 2013 05:58
Location: US\GA

Re: New z14 mainfraime family.

Post by mskmel »

zVlad wrote: 27 Sep 2017 17:47 Кроме того Вы явно поняли мою статистику как статистику обо всей совершаемой работе этим МФ, а это далеко не все, не все даже в Prod LPAR, там еще сервера аппликаций работают, которые, как правило, в случае х86 живут на отдельных серверах.
Если такая низкая нагрузка на БД, то и сервера приложений тоже не сильно нагружены, читай не делают ничего. Вот когда будет 700 пользователей, которые сейчас что-то выполняют, а не 700 обратившихся за последние 15 минут, тогда можно будет говорить о нагрузке и чесать затылок как с этим жить. Т.е. Вашим цифрам не хватает примерно два порядка :oops:
zVlad wrote: 27 Sep 2017 17:47Он ушел на платформу Unix/Oracle и мне известно с каким количеством CPU и RAM они в конце концов смогли выполнять их нагрузку, которая выполнялась на, можно сказать, микроскопическом МФ. Я об этом много рассказывал подробно здесь, Вы вероятно этого не читали.
Если один в один перенести приложение ДБ2 -> Oracle, или в обратном направлении, или в MS SQL, то ожидаемо всё будет тормозить. Иногда проще с нуля всё написать.
zVlad wrote: 27 Sep 2017 17:47 Intel Xeon CPU E5-2650 v3 @ 2.3GHz, 2 sockets, 8 cores, 128 GB RAM.
Нет таких процессоров, извините. E5-2650V3 это 10 ядер на сокет. Какая загрузка ЦПУ на этом сервере?
zVlad
Уже с Приветом
Posts: 16196
Joined: 30 Apr 2003 16:43

Re: New z14 mainfraime family.

Post by zVlad »

iDesperado wrote: 27 Sep 2017 18:07 ....
zVlad wrote: 27 Sep 2017 17:55 Тебе, iDesperado, не лень копаться в прошлых записях, найди, пожалуйста, для mskmel про сервера на которые ушел наш клиент с микроскопического МФ. Там они Unix/Oracle стали использовать вместо zOS/DB2, помнишь? Посмеемся все вместе. А?
давай, это моя любимая байка ! ведь именно там после двух месяцев клоунады я все же вытянул аутпут с консоли и выяснилось, что переехали они на LPAR в 16 vcpu, т.е. половинку от процессора Power6. я целый год без смеха привет не мог открыть
Нет, это не то. Это про web морду к ERP приложению, а то было именно перевод самого ERP приложения.

P.S. Вот параметры той истории ухода с МФ на Unix/Oracle, нашел (в десять больше CPU на более высокой частоте и в 64 раза RAM - см. ниже):
Так вот изначально клиент работал на МФ с двуми процессорами. МФ был разбит на два LPAR с 500 MIPS тотал, LPAR клиента гарантировано имел 340 МИПС если второй LPAR использует свои 160 MIPS, но мах MIPS могло быть до 500 MIPS - ночью как правило, когда не очень то они были нужны). RAM - 2 GB central storage, и 5 GB extended storage для данных DB2 в памяти . Всего около 7 GB. Каналы ввода-вывода само собой и сетевые карты в ассортименте, но мы здесь об этом обычно забываем когда сравниваем МФ с не-МФ. Диски клиента обьемом 2.0 TB. Это в основном БД и два ежедневных бэкапа были.
А теперь давайте посмотрим на чем этот клиент сидит сейчас. Повторяю - приложение тоже самое, от того же вендора что было на МФ. Уникальный случай на самом деле, как правило сравнивать приходится яблоки с апельсинами, а здесь такая удача можно сравнивать яблоки и там и здесь. Так вот сидит клиент, как я уже писал выше, на двух "Unix" серверах (везде речь идет только о продакшн, кстати, хотя во времена МФ клиент делил один МФ с девелопмент системой другого клиента, во втором LPAR см. выше) каждый с 10 CPU 3.5 GHz 128 GB. На обоих стоит и бизнес логика и Оракл (кластер видимо). Два процессора с тактовой частотой ~1 GHz в одном случае (MF) и 10*2 с 3.5 GHz в другом! 7GB РАМ i 256 GB! Честно скажу я сам поражен этими цифрами.
Last edited by zVlad on 27 Sep 2017 19:27, edited 2 times in total.
zVlad
Уже с Приветом
Posts: 16196
Joined: 30 Apr 2003 16:43

Re: New z14 mainfraime family.

Post by zVlad »

Тут звучали заявления о том что надо бы выбросить zOS и написать новую систему для МФ с нуля. На вопрос что в новой системе должно быть "нового" предлагались длинные имена, большая микроядерность:
более микроядерная чем линукс (убрать драйвера из ядра), более реалтаймовая, но главное что-то с решением проблемы RPM/DLL hell.
...про новые языки и рюшечки говорилось.

Заявлю и я что Windows, Linux как серверные системы должны быть убиты как несoответствующие своему назначению - серверная система, и переписаны с учетом следующих требований (читать эту цитату надо медленно, внимательно и думать. MVS - это главная компонента zOS):
MVS took a major step forward in fault-tolerance, built on the earlier STAE facility, that IBM called software recovery. IBM decided to do this after years of practical real-world experience with MVT in the business world. System failures were now having major impacts on customer businesses, and IBM decided to take a major design jump, to assume that despite the very best software development and testing techniques, that 'problems WILL occur.' This profound assumption was pivotal in adding great percentages of fault-tolerance code to the system and likely contributed to the system's success in tolerating software and hardware failures. Statistical information is hard to come by to prove the value of these design features (how can you measure 'prevented' or 'recovered' problems?), but IBM has, in many dimensions, enhanced these fault-tolerant software recovery and rapid problem resolution features, over time.

This design specified a hierarchy of error-handling programs, in system (kernel/'privileged') mode, called Functional Recovery Routines, and in user ('task' or 'problem program') mode, called "ESTAE" (Extended Specified Task Abnormal Exit routines) that were invoked in case the system detected an error (actually, hardware processor or storage error, or software error). Each recovery routine made the 'mainline' function reinvokable, captured error diagnostic data sufficient to debug the causing problem, and either 'retried' (reinvoke the mainline) or 'percolated' (escalated error processing to the next recovery routine in the hierarchy).

Thus, with each error the system captured diagnostic data, and attempted to perform a repair and keep the system up. The worst thing possible was to take down a user address space (a 'job') in the case of unrepaired errors. Though it was an initial design point, it was not until the most recent MVS version (z/OS), that recovery program was not only guaranteed its own recovery routine, but each recovery routine now has its own recovery routine. This recovery structure was embedded in the basic MVS control program, and programming facilities are available and used by application program developers and 3rd party developers.

Practically, the MVS software recovery made problem debugging both easier and more difficult. Software recovery requires that programs leave 'tracks' of where they are and what they are doing, thus facilitating debugging—but the fact that processing progresses despite an error can overwrite the tracks. Early date capture at the time of the error maximizes debugging, and facilities exist for the recovery routines (task and system mode, both) to do this.

IBM included additional criteria for a major software problem that required IBM service. If a mainline component failed to initiate software recovery, that was considered a valid reportable failure. Also, if a recovery routine failed to collect significant diagnostic data such that the original problem was solvable by data collected by that recovery routine, IBM standards dictated that this fault was reportable and required repair. Thus, IBM standards, when rigorously applied, encouraged continuous improvement.
С этим в mainstream серверных платформах полная oпа. Я работаю близко с командиром нашей Wintel группы и мы время от времени обсуждаем его проблемы. Всегда все упирается в недостаточную диагностику и следование гадание нa кофейной гуще - основном спосoбе решения проблем как в Windows, так и в Linux (check disk, registry, viruses, etc...)
Last edited by zVlad on 27 Sep 2017 22:26, edited 3 times in total.
zVlad
Уже с Приветом
Posts: 16196
Joined: 30 Apr 2003 16:43

Re: New z14 mainfraime family.

Post by zVlad »

mskmel wrote: 27 Sep 2017 18:13 ...
zVlad wrote: 27 Sep 2017 17:47Он ушел на платформу Unix/Oracle и мне известно с каким количеством CPU и RAM они в конце концов смогли выполнять их нагрузку, которая выполнялась на, можно сказать, микроскопическом МФ. Я об этом много рассказывал подробно здесь, Вы вероятно этого не читали.
Если один в один перенести приложение ДБ2 -> Oracle, или в обратном направлении, или в MS SQL, то ожидаемо всё будет тормозить. Иногда проще с нуля всё написать.
zVlad wrote: 27 Sep 2017 17:47 Intel Xeon CPU E5-2650 v3 @ 2.3GHz, 2 sockets, 8 cores, 128 GB RAM.
Нет таких процессоров, извините. E5-2650V3 это 10 ядер на сокет. Какая загрузка ЦПУ на этом сервере?
Они не сами переводили приложение. Вендор этого приложения разрабатывает его на платформе Unix/Oracle и как опция пакетируюет для zOS. Т.е. это скорее на zOS перенесенное приложение, а не с zOS.

И вообще, почему Вы так плохо думаете о людях? Вы думаете Вы один знаете о болезнях переноса с одной платформы на другую?

Print screen из Task Manager присоединен. Смотрите сами. Что смутно вспоминается что не все цоры были намеренно активированны. Не буду ничего утверждать.
You do not have the required permissions to view the files attached to this post.
mskmel
Уже с Приветом
Posts: 947
Joined: 24 Sep 2013 05:58
Location: US\GA

Re: New z14 mainfraime family.

Post by mskmel »

zVlad wrote: 27 Sep 2017 19:10И вообще, почему Вы так плохо думаете о людях?
'Think of how stupid the average person is, and realize half of them are stupider than that.'
Это утверждение абсолютно точно и этим оно пугает.

>Print screen из Task Manager
24% в пике на виртуалке. Ну не страшно ведь ;)
User avatar
Dmitry67
Уже с Приветом
Posts: 28283
Joined: 29 Aug 2000 09:01
Location: SPB --> Gloucester, MA, US --> SPB --> Paris

Re: New z14 mainfraime family.

Post by Dmitry67 »

mskmel wrote: 27 Sep 2017 20:15 'Think of how stupid the average person is, and realize half of them are stupider than that.'
Это утверждение абсолютно точно и этим оно пугает.
А можно позанудствовать?
Фраза красивая, но ее автор перепутал среднее и медиану)
Зарегистрированный нацпредатель, удостоверение N 19719876044787 от 22.09.2014

Return to “Вопросы и новости IT”