New z14 mainfraime family.

[Palych]

10-12 GBytes\sec нагрузка практически не заметна на общем фоне, единицы процентов. Больше мне пока неоткуда взять

Это общий фон единицы процентов, или нагрузка CPU связанная с I/O?

[mskmel]

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]

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

Какие метрики надо еще добавить помимо MIPS?

Те кто считают что МФ такой же сервер как "9100 Series", кто так подходят к задаче переноса работы либо с МФ на x86 либо наоборот с x86 на MF обязательно потерпят фиаско в первом случае будут вынуждены существенно увеличивать мощности "9100 Series" во втором случае их остановит price tag того что они насчитают должен бы быть МФ.

Скорее они просто не дойдут до IBM, потому что есть суеверия что МФ дороже, реальность нет специалистов и данных о производительности в открытом доступе.
Пока что я вижу, в каждом запросе на железки, есть специальная страничка с опросником "Если Вам нужен zOS, то объясните почему!".

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

[zVlad]

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

1. Какие метрики надо еще добавить помимо MIPS?

Те кто считают что МФ такой же сервер как "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]

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

53commites\sec это как бы мало очень. 43k Getpage\sec это где-то 1/5 одного х86 ядра.
Эта база может жить на VM c одним vCPU, ну два на всякий случай "потому что могу".

[iDesperado]

53commites\sec это как бы мало очень. 43k Getpage\sec это где-то 1/5 одного х86 ядра.
Эта база может жить на VM c одним vCPU, ну два на всякий случай "потому что могу".

помню мы уже ржали над "ERP" Влада viewtopic.php?p=5993679#p5993679
таких "ERP" мой ноутбук вытянет с десяток, тем более что памяти у меня в ноутбуке больше, плюс ио на SSD

[zVlad]

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]

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]

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

да какая разница, если у тебя пользователи работает с буферным пулом в 3.3Gb
BP Hit % - Random = 86.7%
BP Hit % - Sequential = 66.6%

т.е. пользователи долбят одни и те же данные, умещающиеся в 3.3 Gb. почти наверняка то не пользователи, а роботы счетчики электричества просто обновляют. реальных людей 3 бухгалтера, один CEO.
эту нагрузку мой рабочий ноутбук 4 ядра i5, 16Gb и SSD потянет несколько раз.

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

давай, это моя любимая байка ! ведь именно там после двух месяцев клоунады я все же вытянул аутпут с консоли и выяснилось, что переехали они на LPAR в 16 vcpu, т.е. половинку от процессора Power6. я целый год без смеха привет не мог открыть

[mskmel]

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

Если такая низкая нагрузка на БД, то и сервера приложений тоже не сильно нагружены, читай не делают ничего. Вот когда будет 700 пользователей, которые сейчас что-то выполняют, а не 700 обратившихся за последние 15 минут, тогда можно будет говорить о нагрузке и чесать затылок как с этим жить. Т.е. Вашим цифрам не хватает примерно два порядка

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

Если один в один перенести приложение ДБ2 -> Oracle, или в обратном направлении, или в MS SQL, то ожидаемо всё будет тормозить. Иногда проще с нуля всё написать.

Intel Xeon CPU E5-2650 v3 @ 2.3GHz, 2 sockets, 8 cores, 128 GB RAM.

Нет таких процессоров, извините. E5-2650V3 это 10 ядер на сокет. Какая загрузка ЦПУ на этом сервере?

[zVlad]

....

Тебе, 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! Честно скажу я сам поражен этими цифрами.

[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...)

[zVlad]

...

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

Если один в один перенести приложение ДБ2 -> Oracle, или в обратном направлении, или в MS SQL, то ожидаемо всё будет тормозить. Иногда проще с нуля всё написать.

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 присоединен. Смотрите сами. Что смутно вспоминается что не все цоры были намеренно активированны. Не буду ничего утверждать.

[mskmel]

И вообще, почему Вы так плохо думаете о людях?

'Think of how stupid the average person is, and realize half of them are stupider than that.'
Это утверждение абсолютно точно и этим оно пугает.

>Print screen из Task Manager
24% в пике на виртуалке. Ну не страшно ведь

[Dmitry67]

'Think of how stupid the average person is, and realize half of them are stupider than that.'
Это утверждение абсолютно точно и этим оно пугает.

А можно позанудствовать?
Фраза красивая, но ее автор перепутал среднее и медиану)