Комментарии 43
1. Используете систему виртуализации
2. Linux поставлена в неравные условия, ведь фактически запускается и работает на 2-х 10-ти ядерных машинах, а не на одной 20-ти ядерной, следовательно, не может пользоваться вычислительной мощностью сполна.
3. SUSE linux, как и любой бинарный дистрибутив будет значительно проигрывать по скорости операционке, которая не только под вендора заточена, но еще и под конкретное железо
4. DB2 так же имеет заточку под вендора.
Так что связка z/OS+DB2 по-любому работает быстрей, а вот то, что НАСТОЛЬКО, это действительно открытие.
2. Linux поставлена в неравные условия, ведь фактически запускается и работает на 2-х 10-ти ядерных машинах, а не на одной 20-ти ядерной, следовательно, не может пользоваться вычислительной мощностью сполна.
3. SUSE linux, как и любой бинарный дистрибутив будет значительно проигрывать по скорости операционке, которая не только под вендора заточена, но еще и под конкретное железо
4. DB2 так же имеет заточку под вендора.
Так что связка z/OS+DB2 по-любому работает быстрей, а вот то, что НАСТОЛЬКО, это действительно открытие.
С тем же успехом можно было написать 10 и 110 крат.
Вместо анализа производительности содержание какого-то маркетингового буклета. Начальные условия систем (наполнение, исторические фрагментации и т.д.) неизвестны. Анализ запросов к БД отсутствует. ПО отличается судя по названиям. «После подготовки и настройки каждого тестового стенда были выполнены серии тренировочных тестов и тюнинг развернутых приложений.» — вообще прекрасно.
Вместо анализа производительности содержание какого-то маркетингового буклета. Начальные условия систем (наполнение, исторические фрагментации и т.д.) неизвестны. Анализ запросов к БД отсутствует. ПО отличается судя по названиям. «После подготовки и настройки каждого тестового стенда были выполнены серии тренировочных тестов и тюнинг развернутых приложений.» — вообще прекрасно.
LPAR B и C взаимодействуют по сети? Входящие запросы тоже через этот же сетевой интерфейс валились? А решение на z/OS ходит в базу DB2 локально.
Этож блог компании IBM, естественно тут будет такой маркетинг без доказательств)
Поставили Oracle и Linux на мейнфрейм, в котором для Linux предусмотрена прослойка zLinux и померили, по сути, насколько тормозит zLinux.
Вы же сами и написали в самом начале — «мейнфреймы – это очень надежная, но уступающая по производительности привычным решениям на основе процессоров Intel и операционной системе Linux платформа».
Давайте по-честному, поставьте Oracle и Linux на железо с Intel и сравните показатели. Ставлю пиво, что Linux с Intel выиграют.
Вы же сами и написали в самом начале — «мейнфреймы – это очень надежная, но уступающая по производительности привычным решениям на основе процессоров Intel и операционной системе Linux платформа».
Давайте по-честному, поставьте Oracle и Linux на железо с Intel и сравните показатели. Ставлю пиво, что Linux с Intel выиграют.
Чтобы совсем по-честному, надо на Solaris Sparc.
Вне контекста данного теста, а «правды для».
Linux for z — это нативная версия Linux, скомпилированная под архитектуру System z, никакой отдельной «прослойки» (zLinux) там нет. Все бинарные пакеты, включая Oracle, также скомпилированы под эту архитектуру.
Linux for z, как и любая ОС на архитектуре System z может исполняться и в «железном» режиме, и под управлением гипервизора z/VM.
Linux for z — это нативная версия Linux, скомпилированная под архитектуру System z, никакой отдельной «прослойки» (zLinux) там нет. Все бинарные пакеты, включая Oracle, также скомпилированы под эту архитектуру.
Linux for z, как и любая ОС на архитектуре System z может исполняться и в «железном» режиме, и под управлением гипервизора z/VM.
> Помимо уникального по своим характеристикам планировщика задач в состав z/OS входят т.н. cross-memory services – технология,
> позволяющая передать управление из адресного пространства одной подсистемы напрямую адресному пространству другой
DOS вроде такое уже умел.
> позволяющая передать управление из адресного пространства одной подсистемы напрямую адресному пространству другой
DOS вроде такое уже умел.
DOS — это который MS-DOS или этот?
гавно, а не анализ. Я бы даже сказал, что анализа нету. Потому что не показано, во что именно упирается каждый из бенчмарков.
Разное железо, непонятные юзкейсы, непонятная методика подсчета.
<тут было совсем грубо, но я убрал>
Разное железо, непонятные юзкейсы, непонятная методика подсчета.
<тут было совсем грубо, но я убрал>
Как единственный пока представитель нашей небольшой 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 же разрабатывается сообществом как кроссплатформенное решение. В этом его сила, и… слабость. В данной статье эта слабость наглядно продемонстрирована.
Во-первых, отвечу на претензии вида «разное железо». В тестах использовалось два идентичных по параметрам мейнфрейма, количество ресурсов, выделямых на каждый вариант развертывания приложения, определялось организаторами тестирования. Как видите в варианте с 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 же разрабатывается сообществом как кроссплатформенное решение. В этом его сила, и… слабость. В данной статье эта слабость наглядно продемонстрирована.
> Возможно сравнение с вариантом «все подсистемы в рамках одного образа Linux» было бы интереснее с технической точки зрения, но это был бы синтетический тест.
Почему синтетический?
Задача тестов, обычно, на практике определить лучшую конфигурацию по какому либо критерию, а Вы таким заявлением отсекаете конфигурацию, которая потенциально могла работать лучше (или хуже) других основываясь на субъективном утверждении «так решения для промышленной эксплуатации не разворачивают».
Даже если сейчас не разворачивают, то может быть результаты такого тестирования показали бы преимущества такого подхода по сравнению с разносом всего по разным образам? Или наоборот, не показали бы.
Почему синтетический?
Задача тестов, обычно, на практике определить лучшую конфигурацию по какому либо критерию, а Вы таким заявлением отсекаете конфигурацию, которая потенциально могла работать лучше (или хуже) других основываясь на субъективном утверждении «так решения для промышленной эксплуатации не разворачивают».
Даже если сейчас не разворачивают, то может быть результаты такого тестирования показали бы преимущества такого подхода по сравнению с разносом всего по разным образам? Или наоборот, не показали бы.
Я с вами согласен, но на принятие решение о выборе конфигурации влияет множество факторов, не только скорость работы. Тестирование — процесс не бесплатный, а довольно затратный. Тестируется не просто сферический конь в вакууме, а конфигурация, которая может удовлетворить заказчика. Заказчик естественно выбирает исходя из имеющихся лучших практик. В мире линукс такой лучшей практикой является разнесение компонентов стека по разным образам операционной системы.
Для меня, как технического специалиста, архитектора, безусловно интересны все варианты, но к сожалению возможности не безграничны. Сам был бы рад и надеюсь мы еще сможем протестировать и DB2 + Linux vs DB2 + z/OS, и другие варианты, ну и конечно же поделиться ими с сообществом.
Для меня, как технического специалиста, архитектора, безусловно интересны все варианты, но к сожалению возможности не безграничны. Сам был бы рад и надеюсь мы еще сможем протестировать и DB2 + Linux vs DB2 + z/OS, и другие варианты, ну и конечно же поделиться ими с сообществом.
а где сравнение Linux+DB2 и Linux+Oracle?
Я согласен, данное сравнение было бы интересно, но мы — авторы статьи — занимаемся мейнфреймами, может быть коллеги, занимающиеся распределенными системами, порадуют читателей таким материалом.
ну тогда где сравнение z/OS+DB2 и Linux+DB2?
вы, пардон, рекламой занимаетесь.
Лет пять назад, если мне не изменяет память, я точно так же хейтил Microsoft и тролил их евангелистов, ну как тролил, искренне считал, что искрометно тролю. Потом вырос.
Я понимаю, что данная статья задевает чувства многих людей, которые искренне любят Линукс и открытые исходники, но числа есть числа, с другой стороны — только невнятные предположения. При этом ненавидеть IBM линукс-сообществу наверное не стоит, корпорация вкладывает миллиарды долларов в развитие данной операционной системы.
Я понимаю, что данная статья задевает чувства многих людей, которые искренне любят Линукс и открытые исходники, но числа есть числа, с другой стороны — только невнятные предположения. При этом ненавидеть IBM линукс-сообществу наверное не стоит, корпорация вкладывает миллиарды долларов в развитие данной операционной системы.
мне наплевать и на линукс и на зэтос и на что угодно.
Претензия к автору у меня простая: я анализа в посте не вижу. Поэтому я делаю вывод, что бенчмарки сделаны хз как, а их результаты приведены в рекламных целях.
Претензия к автору у меня простая: я анализа в посте не вижу. Поэтому я делаю вывод, что бенчмарки сделаны хз как, а их результаты приведены в рекламных целях.
Всеми данными, которыми можно было поделиться мы поделились. Начинать публиковать планы выполнения запросов нам никто не позволит, да и если честно, не думаю, что это так важно, т.к. очень специфичная для конкретного приложения информация. А вот архитектурно значимые вещи: выбор операционной системы, СУБД, топологии развертывания и их влияние на работу приложения определенного класса — OLTP — продемонстрированы. Первый комментатор правильно отметил, что использование родной для платформы операционной системы вместе с таковой же СУБД очевидно даст лучшие результаты по производительности, это всем понятный факт. Но вот настолько лучшие, думаю, для многих оказалось сюрпризом. Можно конечно от этого отмахнуться и списать на «вы все врети», но это какой-то не инженерный подход.
Представим на секунду такую ситуацию: вы нашли сценарий, в котором вы втрое уделываете Linux+Oracle и написали о нем. При этом вы позиционируете, что ваше решение втрое быстрее конкурента.
При этом проблема может быть:
Без анализа это все гроша ломаного не стоит. Вопросов миллион.
Например, по методике. Совершенно непонятно, на каком уровне загрузки системы вы меряете ваше время отклика. Насколько были утилизированы диск, память, проц?
При этом проблема может быть:
- в планах выполнения запросов
- в любой настройке проигравшей конфигурации
- в методике
- в чем угодно еще
Без анализа это все гроша ломаного не стоит. Вопросов миллион.
Например, по методике. Совершенно непонятно, на каком уровне загрузки системы вы меряете ваше время отклика. Насколько были утилизированы диск, память, проц?
Очень важно, что мы и хотим донести до аудитории — мы не нашли кейс, нам принесли реальное бизнес-приложение, решающее реальную бизнес-задачу — банковскую платежную систему. Данная система до этого разрабатывалась исключительно на Oracle и Linux. С нашей помощью была осуществлена миграция данной системы на z/OS + DB2, после чего были проведены сравнительные испытания, результатом которых мы и делимся.
Все данные телеметрии, собранные при проведении тестов у нас имеются (больше сотни страниц), есть все необходимые графики. По понятным причинам мы не можем выложить это в публичный доступ. Если вам или кому-нибудь другому данная информация действительно интересна, то прошу написать мне личное сообщение, в котором указать, какую компанию вы представляете, после чего можем встретиться в нашем офисе и пообщаться.
Все данные телеметрии, собранные при проведении тестов у нас имеются (больше сотни страниц), есть все необходимые графики. По понятным причинам мы не можем выложить это в публичный доступ. Если вам или кому-нибудь другому данная информация действительно интересна, то прошу написать мне личное сообщение, в котором указать, какую компанию вы представляете, после чего можем встретиться в нашем офисе и пообщаться.
Ладно фиг с ними с данными телеметрии. Интересуют конфигурации ПО. Например, в том же Oracle как было сконфигурировано использование памяти AMM или в ручную, если в ручную то как именно? Использовались ли Large Pages? В том же hibernate, про DB2 сказано, что был использован org.hibernate.dialect.DB2390Dialect, а что было для Oracle? и т.д. Есть гарантия, что в обоих случаях над конфигурациями сидели DBA, а не в одном случае была установка по-умолчанию, а в другом тонкий тюнинг от DBA?
А какая виртуальная машина Java использовалась в обоих случаях? Извините, если пропустил.
IBM JDK под соответствующую ОС.
вот и ещё одно «горлышко»
В чем же оно заключается?
вы уверены, что реализация IBM JDK одинаково производительна на разных ОС?
Если вы имеете ввиду, что IBM добавляет какие-то закладки в свою JDK на Linux, чтобы та тормозила, то уверен, что такого нет. Верить в такие закладки — это все равно, что верить в слив данных Интелом в АНБ о том, какой код выполняется на их процессорах и что он делает.
Конечно коллеги, разрабатывающие Java для z/OS по максимуму используют возможности аппаратуры. Я как-то писал об этом в личном блоге большую статью. По сути быстрая Java — это одно из конкурентных преимуществ платформы, а не «узкое место».
Конечно коллеги, разрабатывающие Java для z/OS по максимуму используют возможности аппаратуры. Я как-то писал об этом в личном блоге большую статью. По сути быстрая Java — это одно из конкурентных преимуществ платформы, а не «узкое место».
Если вы имеете ввиду, что IBM добавляет какие-то закладки в свою JDK на Linux, чтобы та тормозила
а что, производительность может отличаться только когда целенаправленно «закладки» делают?
По сути быстрая Java — это одно из конкурентных преимуществ платформы, а не «узкое место»
но и про это в статье ни слова нет
Цитата из статьи:
Следует обратить внимание на время выполнения многостороннего взаимозачета без учета работы с СУБД, т.е. время выполнения только расчетной части. На z/OS данное время оказалось на 25% меньше, чем на Linux. Это веский аргумент в пику имеющемуся среди специалистов по информационным технологиям убеждению, что Java плохо работает на z/OS и что не следует использовать данную операционную систему для запуска Java-приложений.
Следует обратить внимание на время выполнения многостороннего взаимозачета без учета работы с СУБД, т.е. время выполнения только расчетной части. На z/OS данное время оказалось на 25% меньше, чем на Linux. Это веский аргумент в пику имеющемуся среди специалистов по информационным технологиям убеждению, что Java плохо работает на z/OS и что не следует использовать данную операционную систему для запуска Java-приложений.
Коллеги, кто действительно заинтересовался темой, приходите на семинар 26 и 27 марта z13 Technical Enablement Roadshow, где мы расскажем про новый мейнфрейм. Семинар будет исключительно технический, приедут коллеги из Монпелье, Франция. В кулуарах можно будет обсудить и Linux vs z/OS, а так же другие темы.
«А газету в кислоту» ©
Без учёта СУБД Оракл — единственный достоверный показатель. Как раз по нему и отличия не грандиозные.
А DB2 оттуда тоже выкинута?
Без учёта СУБД Оракл — единственный достоверный показатель. Как раз по нему и отличия не грандиозные.
А DB2 оттуда тоже выкинута?
Еще не очень понял, все таки Suse Linux или zLinux?
www-03.ibm.com/systems/z/os/linux/getstarted.html
Самые популярные дистрибутивы — SUSE и RedHat, специальные сборки под процессор мейнфрейма, обычно именуются s390. Выше Евгений Хабаров хорошо расписал этот момент.
Самые популярные дистрибутивы — SUSE и RedHat, специальные сборки под процессор мейнфрейма, обычно именуются s390. Выше Евгений Хабаров хорошо расписал этот момент.
В данном случае использовался SUSE Linux Enterprise Server for System z
zLinux — это «жаргонное» название Linux-дистрибутивов, скомпилированных для платформы System z, т.к. полное официальное название не очень удобно для повседневного использования.
zLinux — это «жаргонное» название Linux-дистрибутивов, скомпилированных для платформы System z, т.к. полное официальное название не очень удобно для повседневного использования.
Del
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Правильная платформа для Java EE приложений: как z/OS + DB2 оказались в 3 раза быстрее Linux + Oracle