Sabre: пример для изучения, переход с МФ.

[Мальчик-Одуванчик]

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

И как, не удалась очередная попытка?

Жалкое зрелище, душераздирающее... Кошмар!

[Сабина]

Жалкое зрелище, душераздирающее... Кошмар!

Да, я работала на проекте - webapp на мейнфрейме 2011-2012. Зрелище очень жалкое, даже по сравнению с простым лаптопом/десктопом, что уж говорить за имплементации BigData или облака - подтверждаю. Чахоточная память, OOM, и частые crashes из-за перегрузки CPU от апликейшена с которым запросто справляется девелоперский лаптоп на 8GB. Доп.память стоит какие то нереальные цифры, как 10 новых лаптопов.

[zVlad]

Жалкое зрелище, душераздирающее... Кошмар!

Да, я работала на проекте - webapp на мейнфрейме 2011-2012. Зрелище очень жалкое, даже по сравнению с простым лаптопом/десктопом, что уж говорить за имплементации BigData или облака - подтверждаю. Чахоточная память, OOM, и частые crashes из-за перегрузки CPU от апликейшена с которым запросто справляется девелоперский лаптоп на 8GB. Доп.память стоит какие то нереальные цифры, как 10 новых лаптопов.

Что за ОС там была на МФ? zOS или Linux. Это был WebSphere?

[Сабина]

Что за ОС там была на МФ? zOS или Linux. Это был WebSphere?

zOS /JBoss

[zVlad]

Что за ОС там была на МФ? zOS или Linux. Это был WebSphere?

zOS /JBoss

Первая реакция была воскликнуть "JBoss не существует в zOS. JBoss должен в Линукс на ВМ выполняться на МФ. Но съел в Гугл и на тебе, оказывается может, как впрочем любое Юникс приложение.
Увы ничего сказать про это не могу кроме того что проблемы у Вас были не от zOS. Подробнее я отвечу на то сообщение где Вы приводите некоторые симптомы и предположения.

[Сабина]

Увы ничего сказать про это не могу кроме того что проблемы у Вас были не от zOS.

Безусловно, все из-за отсуствия идей. Можете не тратить время на длинные описания "чудесных" мейнфреймов, нам "безидейным" все равно не постичь, а с этой кучей хлама намучались по самое нехочу, даже весьма талантливые архитекторы.

http://www.redbooks.ibm.com/redbooks/pdfs/sg247291.pdf

8.1 Typical Java problems. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
8.1.1 OutOfMemory problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130 Contents v
8.1.2 Hang or deadlock problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
8.1.3 Crash problems. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
8.1.4 High CPU or performance problems . . . . . . . . . . . . . . . . . . . . . . . . 135

[flip_flop]

Эвона как страсти мордасти разгорелись.

Безотносительно облаков, интересно было бы поговорить о масштабируемости вверх, а не на сторону. Scale up vs scale out. Целостная машина вместо кластера. Одна ОС вместо кучи экземпляров (instances) ОС. Симметричная память, разделяемая всеми процессорами вместо распределённой по узлам кластера памяти. Один узел вместо сотен/тысяч узлов. OpenMP вместо OpenMPI. МФ вместо кластера.

И такие машинки (на Xeon) есть на сегодняшний день. В суперкомпьютерах уже упомянутые ранее SGI UV 2000. Но "ни слова о драконах" Однако та же SGI выпустила вариацию SGI UV 300 - меньше сокетов (32 вместо 256, 480 коров вместо нескольких тысяч) но больше памяти (24 димма на сокет, всего 24 ТБ с агрегированной передачей данных в 2.7 ТБ/сек) и более быстрое IO (2 слота NVMe по PCIe Gen3 на один сокет, всего 128 ТБ, с агрегированной скоростью чтения 200 ГБ/сек и с темпом операций записи/чтения 4К данных в 30 миллионов(!) IOPS). В результате получился зверь по IO и лакомый кусок для "in memory analytics SAP/HANA". Но ведь и для обычных БОЛЬШИХ датацентров может пригодиться, нет?

Если же это будет отторжено как "не МФ", то второй пример – HP Superdome X и NonStop (для МФ уровня RAS) series. Это уж точно дебит/кредит, банки/шманки, финансы и прочий enterprise. Не так амбициозно, но очень похоже – scale up (vs scale out) до 16 сокетов (пока что), 12 TB памяти, приличный интерконнект.

Ну и PRIMEQUEST, с "всего" 8-ю сокетами, но 12 ТБ памяти, интересной архитектурой и превосходной надёжностью и избыточностью.

Это я к тому, что монолитные, надёжные, и, что самое главное - масштабируемые в рамках монолита SMP high end серверы на XEON E7 v2 имеют место быть, в дополнение к кластерам на ширпотребе. Не совсем МФ, но всё-таки

[zVlad]

Жалкое зрелище, душераздирающее... Кошмар!

Да, я работала на проекте - webapp на мейнфрейме 2011-2012. Зрелище очень жалкое, даже по сравнению с простым лаптопом/десктопом, что уж говорить за имплементации BigData или облака - подтверждаю. Чахоточная память, OOM, и частые crashes из-за перегрузки CPU от апликейшена с которым запросто справляется девелоперский лаптоп на 8GB. Доп.память стоит какие то нереальные цифры, как 10 новых лаптопов.

1. Чахоточная память. Юникс приложения, как и любые другие в zOS, выполняются в виртуальных адресных пространствах, размеры которых могут быть в зависимости от архитектуры МФ и версии ОС либо 2GB (архитектура XA - 31 бит адресация) до практически неограниченного размера (архитектура zArchitecture - 64 бит адресация).
Вы не сказали какой там дым МФ и какая версия zOS. Но можно сказать что нужно было проверить значение параметра ASSIZEMAX в OMVS segment того юзер профайла под которым у вас выполнялся JBOSS. Кроме того версия Java могла играть роль и способность её выполняться в 64 Битовой адресации. Этого Вы тоже не сказали.
2. Что такое ООМ?
3. Крашей из-за перегрузки CPU быть тоже не могло если параметр CPUTIMEMAX правильно назначен.
4. Дополнительная реальная реальная память могла бы понадобиться если на том МФ было совсем мало памяти или точнее если вам дали систему в LPAR с очень маленькой Мемори. Но это уже определяется тем для кого Вы делали эту работу и его отношением к этой работе.

Давайте будет аккуратно делать выводы там где Вашей компетенции недостаточно для анализа причин и решения проблем. Спасибо.

[zVlad]

Увы ничего сказать про это не могу кроме того что проблемы у Вас были не от zOS.

Безусловно, все из-за отсуствия идей. Можете не тратить время на длинные описания "чудесных" мейнфреймов, нам "безидейным" все равно не постичь, а с этой кучей хлама намучались по самое нехочу, даже весьма талантливые архитекторы.

...

Ваши эмоции совершенно не уместны и беспричинны. По конкретной ситуации на МФ в zOS я могу Вам предоставить полный анализ и дать всю раскладку.

[flip_flop]

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

Сабина, я помню Ван нравилось на МФ вначале, не то что всем известный ширпотреб типа Оракла, индийцев не было и вообще круто. А теперь чего так? Мне просто интересен "глас народа"

[zVlad]

Увы ничего сказать про это не могу кроме того что проблемы у Вас были не от zOS.

http://www.redbooks.ibm.com/redbooks/pdfs/sg247291.pdf

8.1 Typical Java problems. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
8.1.1 OutOfMemory problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130 Contents v
8.1.2 Hang or deadlock problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
8.1.3 Crash problems. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
8.1.4 High CPU or performance problems . . . . . . . . . . . . . . . . . . . . . . . . 135

Вы привели фрагмент оглавления красной книги. А Вы прочитали о чем в ней по поводу типичных проблем Явы написано? Там есть хоть одно объяснение со ссылкой на тот или иной недостаток zOS? Я почитал и не нашел ни одного такого объяснения.

Спрашивается к чему Вы привели этот фрагмент оглавления? Что Вы хотели этим показать? Извините если слишком много вопросов задаю. Мне просто действительно хочется понять.

[Сабина]

Мне просто действительно хочется понять.

Что тут еще нужно понимать когда один и тот же набор программ на лаптопе бегает как по маслу, а на базовой МФ крашиться постоянно от нехватки памяти и соотвественно high CPU, а апгрейд до нужной памяти и перехода на 64 битную версию стоит десяток новых лаптопов ?

[iDesperado]

http://www.redbooks.ibm.com/redbooks/pdfs/sg247291.pdf

понравился раздел The guidelines to consider when using 31-bit or 64-bit Java are as follows
и это в 21 веке ...

[krids]

Сумарная загрузка всех 5-ти CPU - 100%. Я попробую приаттачить что-нибудь посмотреть.

В результате мы болтаемся на пределе SLA и даже иногда его не выполняем.
На этот MF, без его upgrade, должны с нового года придти 3500 новых юзеров. Придти с некоторого количества серверов ранящих SAP/Oracle.

И что будете делать когда эти 3500 юзеров начнуть давать нагрузку на и так уже CPU-bound систему ?

[krids]

Виртуализаций много, но они все мало пригодны для реальной загрузки и Production и довольно редко используются для этого. Development куда ни шло, a Production редко.

:facepalm:
Вы бы почитали что-нибудь о том как нынче дела обстоят в мире виртуализации (отличной от System z) тяжелых enterprise applications (для затравки EMC IT’S VIRTUAL ORACLE DEPLOYMENT FRAMEWORK)
О том как "довольно редко используют" production-виртуализацию в PowerVM, SPARC LDOM/containers, etc даже говорить не буду.

[Dmitry67]

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

Для того чтобы Вам доказать это нужно чтобы Вы поработали с zOS. Поработайте и доказывать ничего не надо будет.

К сожалению мне это не светит за почти полным отсутствием вымирающего класса
Но может этот personal experience сойдет за знакомство?

Что тут еще нужно понимать когда один и тот же набор программ на лаптопе бегает как по маслу, а на базовой МФ крашиться постоянно от нехватки памяти и соотвественно high CPU, а апгрейд до нужной памяти и перехода на 64 битную версию стоит десяток новых лаптопов ?

[zVlad]

Сумарная загрузка всех 5-ти CPU - 100%. Я попробую приаттачить что-нибудь посмотреть.

В результате мы болтаемся на пределе SLA и даже иногда его не выполняем.
На этот MF, без его upgrade, должны с нового года придти 3500 новых юзеров. Придти с некоторого количества серверов ранящих SAP/Oracle.

И что будете делать когда эти 3500 юзеров начнуть давать нагрузку на и так уже CPU-bound систему ?

На этот счёт есть два сценария. По первому, ничего не делать. Поскольку активность в девелопмент LPAR сократится практически до нуля, то это будет означать прибавку капасити на до 20% и этого может быть достаточно для новых юзеров - не все 3500 одновременно начнут работать - это промышленное приложение и люди работают шифтами, болеют и в отпусках.
Кроме этого идет подготовка к динамическому повышению мощности МФ процентов на 20-30. Если все для этого есть то делается это на раз-два-три без остановки систем.
Я же ожидаю что поскольку будут задействованы новые программы написанные криворукими программерами (мы их знаем уже по другим делам) то придется на лету что менять в ДВ2 в зависимости от что они наделали. Плюс ожидаем ботле-нек на стороне WebSphere под АIX который будет использоваться для новых юзеров как фронтэнд. Отзывы уже, в тесте, тревожные.

[zVlad]

Мне просто действительно хочется понять.

Что тут еще нужно понимать когда один и тот же набор программ на лаптопе бегает как по маслу, а на базовой МФ крашиться постоянно от нехватки памяти и соотвественно high CPU, а апгрейд до нужной памяти и перехода на 64 битную версию стоит десяток новых лаптопов ?

Сабина, Вы прочитали что я написал выше на этой странице o виртуальной памяти и CPU time?

МФ никогда не используется для чего-нибудь одного. Тот МФ где Вы игрались с JBoss наверняка, 100%, имел несколько LPAR и этих LPAR шла какая-нибудь работа. Очень даже вероятно что Вы не имели своегоо отдельно LPAR для JBoss и Вам лишь дали Unix сессию на чем-нибудь еще загруженном zOS. Не знаю какова была Ваша роль и кто еще с Вами работал, но не чуствуется что у Вас была нормальная поддержка со стороны системного программиста zOS. Короче говоря если бы Вы ко мне пришли ничего подобного Вам потом говорить не пришлось.

А теперь обратимся к фактам.

Java в zOS поставляется всегда начиная с v5 (не позже 2006-го года) и в 31-битовой и в 64-битовой комплектации:

http://www-03.ibm.com/systems/z/os/zos/tools/java/

иными словами ничего специально покупать не надо - у вас либо есть Java 31-bit и 64-bit, либо Java нет. Третьего не дано.

Виртуальную память тоже покупать не надо, ее надо лишь правильно сконфигурировать (см. ниже). Показанием для увеличения реальной памяти, которую да надо покупать, может быть только недостаточная производительность связанная с интенсивным страничным обменом. Вы о такой ситуации ничего не говорили и мне не понятно зачем вдруг понадобилось Вам говорить о покупке памяти.

Вот Вам дополнительная информация о Ваших страстях по памяти, CPU и 64-битам в Java на МФ (источник датирован Августом 2011, но все это уже было минимум с 2006-года):

http://www-03.ibm.com/systems/z/os/zos/ ... vafaq.html

Examples First Time Using 64 bit Java

To be able to run 64 bit Java, the memory limit or memlimit for memory above the bar must be sufficient to run the 64 bit application. Before attempting to use 64 bit Java for the first time on z/OS, check that the memlimit "memory above the 2 Gigabyte bar" is not zero by using the ulimit command as shown below. In this example the memory above the bar is 1000 megabytes. Your configuration may be different.

> ulimit -a
core file 8192b
cpu time unlimited
data size unlimited
file size unlimited
stack size unlimited
file descriptors 1500
address space unlimited
memory above bar 1000m

The following 64 bit Java command is invoked to display the java version. The following command displays "s390x-64" , which means the 64 Bit Java is being run.

> java -version
java version "1.6.0"
Java(TM) SE Runtime Environment (build pmz6460sr5-20090604_01(SR5))
IBM J9 VM (build 2.4, J2RE 1.6.0 IBM J9 2.4 z/OS s390x-64
jvmmz6460sr5-20090519_35743 (JIT enabled, AOT enabled
J9VM - 20090519_035743_BHdSMr
JIT - r9_20090518_2017
GC - 20090417_AA)
JCL - 20090529_01

Next example will use -verbose:gc java command option to display the default Java heap size values. In this example maxHeapSize value is 0x20000000 or 512 megabytes.

> java -verbose:gc -version

<initialized>
<attribute name="gcPolicy" value="-Xgcpolicy:optthruput" />
<attribute name="maxHeapSize" value="0x20000000" />
<attribute name="initialHeapSize" value="0x400000" />
<attribute name="compressedRefs" value="false" />
<attribute name="pageSize" value="0x1000" />
<attribute name="requestedPageSize" value="0x1000" />
</initialized>

The next examples demonstrates changing the memlimit for above the bar storage from 1000 megabytes to 200 megabytes using the ulimit -M option. After setting 200 megabyte above the bar storage, the 64 bit java command is invoked with default heap size of 200 megabytes. As expected the java command fails. Note this example requires access to a Java HelloWorld program.

> ulimit -M 200

> ulimit -a
core file 8192b
cpu time unlimited
data size unlimited
file size unlimited
stack size unlimited
file descriptors 1500
address space unlimited
memory above bar 200m

[zVlad]

http://www.redbooks.ibm.com/redbooks/pdfs/sg247291.pdf

понравился раздел The guidelines to consider when using 31-bit or 64-bit Java are as follows
и это в 21 веке ...

Юноша, поинтересуйтесь годом выпуска этой книги и вспомните когда Вы сами впервые погрузились в 64-битовую среду.

[iDesperado]

Юноша, поинтересуйтесь годом выпуска этой книги и вспомните когда Вы сами впервые погрузились в 64-битовую среду.

в середине 90х sparc и оракл у нас был уже 64-бит, книга минимум на десятилетие старше ...
sun v20z на интеле (x86-64) у нас в районе 2005 появились.

[zVlad]

Юноша, поинтересуйтесь годом выпуска этой книги и вспомните когда Вы сами впервые погрузились в 64-битовую среду.

в середине 90х sparc и оракл у нас был уже 64-бит, книга минимум на десятилетие старше ...
sun v20z на интеле (x86-64) у нас в районе 2005 появились.

Да это так судя по Wiki. Были и более ранние имплементации 64-bit архитектуры. IBM MF с 64-bit был аннонсирован в 2000-ом. Заговорили же мы здесь, на форуме, об этой архитектуре несколькими годами позже. Я не смог найти когда Java 64-bit появилась. А мы именно о Java говорим.

У нас МФ 64-bit появился в 2001 году но до 2005-го мы работатли с 31-битовой OC - OS/390.

[flip_flop]

Я прочитал об аннонсировании х86 64 бит (тогда блистательной АМД) ещё на исторической родине, в 1999 году. По приезду в страну победившего капитализма, в том же 1999 году, начал работать на 64 битных спарках, вначале на HP, затем на популярной тогда Sun Solaris. Технологии 20-го века.

P.S. Что подтверждает факт реактивности МФ (в целом, как правило), новейшие технологии появляются как правило на других платформах. Есть и некоторые исключения, конечно.

[Palych]

Мне парили Саны и Альфы в 1998 году.
По-моему они были 64 битовые...

Посмотрел - Solaris 7, 1998: The first 64-bit UltraSPARC release.

[zVlad]

Я прочитал об аннонсировании х86 64 бит (тогда блистательной АМД) ещё на исторической родине, в 1999 году. По приезду в страну победившего капитализма, в том же 1999 году, начал работать на 64 битных спарках, вначале на HP, затем на популярной тогда Sun Solaris. Технологии 20-го века.

А что собственно в этой технологии революционного? Первые компьютеры с 64-bit архитектурой появились в 70-е.

[flip_flop]

Я прочитал об аннонсировании х86 64 бит (тогда блистательной АМД) ещё на исторической родине, в 1999 году. По приезду в страну победившего капитализма, в том же 1999 году, начал работать на 64 битных спарках, вначале на HP, затем на популярной тогда Sun Solaris. Технологии 20-го века.

А что собственно в этой технологии революционного? Первые компьютеры с 64-bit архитектурой появились в 70-е.

Революционного - ничего. А вот доступность для масс - великое дело.

P.S. К тому же залог более революционных технологий сейчас, типа "in memory database, in memory analytics" Переход количественных изменений в качественные