Я так понял, Oracle запрещает запускать TCK для любых реализаций JVM, кроме HotSpot, что похоже и стало причиной фрагментации проекта AdoptOpenJDK. Дело в том, что лет 9 назад IBM открыл в Open Source свою JVM и назвал ее Eclipse (кто бы сомневался) OpenJ9. В итоге в рамках проекта AdoptOpenJDK поставлялись две JVM на базе одной и той же библиотеки классов из OpenJDK, но с разной реализацией рантайма: HotSpot и Eclipse OpenJ9. Последняя в свою очередьпострена на базе проекта Eclipse OMR: набора компонентов для разработки виртуальных машин, включающего в себя различные GC, JIT-компилятор (и должен быть AOT-, потому что IBM JVM поддерживала AOT компиляцию классов ещё в лохматом 14м году, а то и раньше) с набором оптимизаций и генератором машинного кода, слой абстракции от ОС и утилиты. Теперь этот блудный проект OpenJ9 вернулся в родной дом IBM и поставляется под названием IBM Semeru Runtimes (не стоит путать с прозвучавшим в статье Temurin), но разработка продолжается на GitHub.
Основным преимуществом OpenJ9 считается существенно меньшее потребление памяти за счёт снижения пропускной способности и увеличения времени отклика приложений, что делает его интересным кандидатом на использование в облачных средах. Насколько существенное снижение потребления памяти и каким именно снижением производительности придется заплатить зависит от конкретных приложений, здесь придется тестировать.
www-03.ibm.com/systems/z/os/linux/getstarted.html
Самые популярные дистрибутивы — SUSE и RedHat, специальные сборки под процессор мейнфрейма, обычно именуются s390. Выше Евгений Хабаров хорошо расписал этот момент.
Очень важно, что мы и хотим донести до аудитории — мы не нашли кейс, нам принесли реальное бизнес-приложение, решающее реальную бизнес-задачу — банковскую платежную систему. Данная система до этого разрабатывалась исключительно на Oracle и Linux. С нашей помощью была осуществлена миграция данной системы на z/OS + DB2, после чего были проведены сравнительные испытания, результатом которых мы и делимся.
Все данные телеметрии, собранные при проведении тестов у нас имеются (больше сотни страниц), есть все необходимые графики. По понятным причинам мы не можем выложить это в публичный доступ. Если вам или кому-нибудь другому данная информация действительно интересна, то прошу написать мне личное сообщение, в котором указать, какую компанию вы представляете, после чего можем встретиться в нашем офисе и пообщаться.
Коллеги, кто действительно заинтересовался темой, приходите на семинар 26 и 27 марта z13 Technical Enablement Roadshow, где мы расскажем про новый мейнфрейм. Семинар будет исключительно технический, приедут коллеги из Монпелье, Франция. В кулуарах можно будет обсудить и Linux vs z/OS, а так же другие темы.
Следует обратить внимание на время выполнения многостороннего взаимозачета без учета работы с СУБД, т.е. время выполнения только расчетной части. На z/OS данное время оказалось на 25% меньше, чем на Linux. Это веский аргумент в пику имеющемуся среди специалистов по информационным технологиям убеждению, что Java плохо работает на z/OS и что не следует использовать данную операционную систему для запуска Java-приложений.
Если вы имеете ввиду, что IBM добавляет какие-то закладки в свою JDK на Linux, чтобы та тормозила, то уверен, что такого нет. Верить в такие закладки — это все равно, что верить в слив данных Интелом в АНБ о том, какой код выполняется на их процессорах и что он делает.
Конечно коллеги, разрабатывающие Java для z/OS по максимуму используют возможности аппаратуры. Я как-то писал об этом в личном блоге большую статью. По сути быстрая Java — это одно из конкурентных преимуществ платформы, а не «узкое место».
MS-DOS — это однозадачная операционная система, речь же идет о коммуникации двух одновременно работающих приложений (у каждого свое адресное пространство, в мире мейнфреймов именно этот термин обычно и используется).
Всеми данными, которыми можно было поделиться мы поделились. Начинать публиковать планы выполнения запросов нам никто не позволит, да и если честно, не думаю, что это так важно, т.к. очень специфичная для конкретного приложения информация. А вот архитектурно значимые вещи: выбор операционной системы, СУБД, топологии развертывания и их влияние на работу приложения определенного класса — OLTP — продемонстрированы. Первый комментатор правильно отметил, что использование родной для платформы операционной системы вместе с таковой же СУБД очевидно даст лучшие результаты по производительности, это всем понятный факт. Но вот настолько лучшие, думаю, для многих оказалось сюрпризом. Можно конечно от этого отмахнуться и списать на «вы все врети», но это какой-то не инженерный подход.
Я с вами согласен, но на принятие решение о выборе конфигурации влияет множество факторов, не только скорость работы. Тестирование — процесс не бесплатный, а довольно затратный. Тестируется не просто сферический конь в вакууме, а конфигурация, которая может удовлетворить заказчика. Заказчик естественно выбирает исходя из имеющихся лучших практик. В мире линукс такой лучшей практикой является разнесение компонентов стека по разным образам операционной системы.
Для меня, как технического специалиста, архитектора, безусловно интересны все варианты, но к сожалению возможности не безграничны. Сам был бы рад и надеюсь мы еще сможем протестировать и DB2 + Linux vs DB2 + z/OS, и другие варианты, ну и конечно же поделиться ими с сообществом.
Лет пять назад, если мне не изменяет память, я точно так же хейтил Microsoft и тролил их евангелистов, ну как тролил, искренне считал, что искрометно тролю. Потом вырос.
Я понимаю, что данная статья задевает чувства многих людей, которые искренне любят Линукс и открытые исходники, но числа есть числа, с другой стороны — только невнятные предположения. При этом ненавидеть IBM линукс-сообществу наверное не стоит, корпорация вкладывает миллиарды долларов в развитие данной операционной системы.
Я согласен, данное сравнение было бы интересно, но мы — авторы статьи — занимаемся мейнфреймами, может быть коллеги, занимающиеся распределенными системами, порадуют читателей таким материалом.
Как единственный пока представитель нашей небольшой z-команды на Хабре постараюсь ответить на все комментарии.
Во-первых, отвечу на претензии вида «разное железо». В тестах использовалось два идентичных по параметрам мейнфрейма, количество ресурсов, выделямых на каждый вариант развертывания приложения, определялось организаторами тестирования. Как видите в варианте с Oracle'ом памяти выделено даже больше, совокупное число процессоров было одинаковым.
Во-вторых, отвечу на претензии вида «разные названия ПО». Если честно претензия непонятна, естественно СУБД использовались разные, от разных производителей. Сервер приложений был одним и тем же — WebSphere Application Server 8.5.5, просто версия под распределенные системы называется «Network Deployment», а версия для z/OS — «for z/OS». Тестировалось одно и то же прикладное решение, основанное на платформе Java EE.
В-третьих, хотя пассаж про «прослойку zLinux» уже прокомментировали, немного дополню. И Linux, и z/OS работали под управлением аппаратно-микропрограммного гипервизова Processor Resource and System Manager (PR/SM). Никакой дополнительной виртуализации для Linux не использовалось.
Самое существенное высказанное замечание — в случае z/OS использовалась ее сила — colocation, а в случае Linux — СУБД и сервер приложений были разнесены на разные LPAR'ы и взаимодействовали по сети (в тесте использовалась реальная сеть 10 Gb). Возможно сравнение с вариантом «все подсистемы в рамках одного образа Linux» было бы интереснее с технической точки зрения, но это был бы синтетический тест. Почему-то на практике специалисты по Linux так решения для промышленной эксплуатации не разворачивают. Они стараются разносить СУБД, сервер приложений, а был бы еще и MQ, то и его, по разным образам операционной системы. Почему они так делают я сказать не могу.
По поводу сравнения разных дистрибутивов Linux. Дело не в дистрибутиве, а в том, что при любом дистрибутиве Linux остается Linux'ом со всеми его плюсами и минусами. z/OS как проприентарная (я все же употребил это страшное слово!) система адресно затачивается под железо. Упрекать за это — все равно, что причитать: «ага, ваш боксер победил, потому что тренировался, а наш — нет!» Linux же разрабатывается сообществом как кроссплатформенное решение. В этом его сила, и… слабость. В данной статье эта слабость наглядно продемонстрирована.
Мы описали это в статье: «Многосторонний взаимозачет выполняется в один поток (т.е. он в принципе не масштабируется, так написано приложение). Время его проведения в кластерном режиме увеличивается из-за необходимости пересылки блокировок DB2 в CF при выполнении массовых операций DML.»
Я так понял, Oracle запрещает запускать TCK для любых реализаций JVM, кроме HotSpot, что похоже и стало причиной фрагментации проекта AdoptOpenJDK. Дело в том, что лет 9 назад IBM открыл в Open Source свою JVM и назвал ее Eclipse (кто бы сомневался) OpenJ9. В итоге в рамках проекта AdoptOpenJDK поставлялись две JVM на базе одной и той же библиотеки классов из OpenJDK, но с разной реализацией рантайма: HotSpot и Eclipse OpenJ9. Последняя в свою очередьпострена на базе проекта Eclipse OMR: набора компонентов для разработки виртуальных машин, включающего в себя различные GC, JIT-компилятор (и должен быть AOT-, потому что IBM JVM поддерживала AOT компиляцию классов ещё в лохматом 14м году, а то и раньше) с набором оптимизаций и генератором машинного кода, слой абстракции от ОС и утилиты. Теперь этот блудный проект OpenJ9 вернулся в родной дом IBM и поставляется под названием IBM Semeru Runtimes (не стоит путать с прозвучавшим в статье Temurin), но разработка продолжается на GitHub.
Основным преимуществом OpenJ9 считается существенно меньшее потребление памяти за счёт снижения пропускной способности и увеличения времени отклика приложений, что делает его интересным кандидатом на использование в облачных средах. Насколько существенное снижение потребления памяти и каким именно снижением производительности придется заплатить зависит от конкретных приложений, здесь придется тестировать.
В определении
AlsoTrueConceptточно нет опечатки? Чтобы всегда былоtrueнужен оператор||, а не&&.Самые популярные дистрибутивы — SUSE и RedHat, специальные сборки под процессор мейнфрейма, обычно именуются s390. Выше Евгений Хабаров хорошо расписал этот момент.
Все данные телеметрии, собранные при проведении тестов у нас имеются (больше сотни страниц), есть все необходимые графики. По понятным причинам мы не можем выложить это в публичный доступ. Если вам или кому-нибудь другому данная информация действительно интересна, то прошу написать мне личное сообщение, в котором указать, какую компанию вы представляете, после чего можем встретиться в нашем офисе и пообщаться.
Следует обратить внимание на время выполнения многостороннего взаимозачета без учета работы с СУБД, т.е. время выполнения только расчетной части. На z/OS данное время оказалось на 25% меньше, чем на Linux. Это веский аргумент в пику имеющемуся среди специалистов по информационным технологиям убеждению, что Java плохо работает на z/OS и что не следует использовать данную операционную систему для запуска Java-приложений.
Конечно коллеги, разрабатывающие Java для z/OS по максимуму используют возможности аппаратуры. Я как-то писал об этом в личном блоге большую статью. По сути быстрая Java — это одно из конкурентных преимуществ платформы, а не «узкое место».
Для меня, как технического специалиста, архитектора, безусловно интересны все варианты, но к сожалению возможности не безграничны. Сам был бы рад и надеюсь мы еще сможем протестировать и DB2 + Linux vs DB2 + z/OS, и другие варианты, ну и конечно же поделиться ими с сообществом.
Я понимаю, что данная статья задевает чувства многих людей, которые искренне любят Линукс и открытые исходники, но числа есть числа, с другой стороны — только невнятные предположения. При этом ненавидеть IBM линукс-сообществу наверное не стоит, корпорация вкладывает миллиарды долларов в развитие данной операционной системы.
Во-первых, отвечу на претензии вида «разное железо». В тестах использовалось два идентичных по параметрам мейнфрейма, количество ресурсов, выделямых на каждый вариант развертывания приложения, определялось организаторами тестирования. Как видите в варианте с Oracle'ом памяти выделено даже больше, совокупное число процессоров было одинаковым.
Во-вторых, отвечу на претензии вида «разные названия ПО». Если честно претензия непонятна, естественно СУБД использовались разные, от разных производителей. Сервер приложений был одним и тем же — WebSphere Application Server 8.5.5, просто версия под распределенные системы называется «Network Deployment», а версия для z/OS — «for z/OS». Тестировалось одно и то же прикладное решение, основанное на платформе Java EE.
В-третьих, хотя пассаж про «прослойку zLinux» уже прокомментировали, немного дополню. И Linux, и z/OS работали под управлением аппаратно-микропрограммного гипервизова Processor Resource and System Manager (PR/SM). Никакой дополнительной виртуализации для Linux не использовалось.
Самое существенное высказанное замечание — в случае z/OS использовалась ее сила — colocation, а в случае Linux — СУБД и сервер приложений были разнесены на разные LPAR'ы и взаимодействовали по сети (в тесте использовалась реальная сеть 10 Gb). Возможно сравнение с вариантом «все подсистемы в рамках одного образа Linux» было бы интереснее с технической точки зрения, но это был бы синтетический тест. Почему-то на практике специалисты по Linux так решения для промышленной эксплуатации не разворачивают. Они стараются разносить СУБД, сервер приложений, а был бы еще и MQ, то и его, по разным образам операционной системы. Почему они так делают я сказать не могу.
По поводу сравнения разных дистрибутивов Linux. Дело не в дистрибутиве, а в том, что при любом дистрибутиве Linux остается Linux'ом со всеми его плюсами и минусами. z/OS как проприентарная (я все же употребил это страшное слово!) система адресно затачивается под железо. Упрекать за это — все равно, что причитать: «ага, ваш боксер победил, потому что тренировался, а наш — нет!» Linux же разрабатывается сообществом как кроссплатформенное решение. В этом его сила, и… слабость. В данной статье эта слабость наглядно продемонстрирована.