Ваш покорный слуга написал еще одну статью на Хабрахабр - Правильная платформа для Java EE приложений: как z/OS + DB2 оказались в 3 раза быстрее Linux + Oracle.
Краткое резюме: очень быстро мигрировали Java EE приложение, использующее Hibernate, на мейнфрейм и провели сравнительное тестирование, с одной стороны данное приложение на zLinux + Oracle (2 LPAR), с другой - оно же на z/OS + DB2 (1 LPAR). Вариант на z/OS + DB2 работал быстрее в 3 раза. Конфигурация выбрана исходя из требований заказчика, для которого выполняли тестирование, но в принципе соответствует реальным практикам, почему-то именно так и разворачивают - на Linux стараются вынести каждую подсистему на свою виртуальную машину, на z/OS - весь стек разворачивается вместе, тем самым используются примущества операционной системы, в частности Cross-Memory Services - механизм, позволяющий из одного адресного пространства (WebSphere Application Server) обратиться к другому (DB2) с помощью нескольких машинных команд, минуя планировщик ОС. Преимущества подхода перед типичным кодом межпроцессной коммуникации (IPC), содержащем сотни, а то и тысячи машинных инструкций, да к тому же выполняющем обращения к ядру, очевидны любому инженеру, знакомому с операционными системами чуть глубже, нежели на уровне "интерфейс унылый/интерфейс неунылый".
Отдельно отмечу, что исключительно расчетная часть на Java под z/OS выполнялась быстрее на 25%, что является отдельным приветом сторонникам мнения "Java на мейнфрейме тормозит и вообще".
P.S. Очень распространенное заблуждение, что zLinux выполняется только на z/VM. В данном случае и z/OS и zLinux выполнялись на LPAR'ах, VM в тесте не участвовала.
UPD: Хабраэксперты не подкачали, адекватные комментарии и претензии затерялись в ворохе: "Мы веруем в Линуха святого, а вы говорите, что он в чем-то хуже? Вы все врети, вы - сурковскаяпропаганда!!!" Грамотность аудитории оставляет желать лучшего, но это - уже наша недоработка. Основная претензия - разнесение подсистем на линуксе по разным LPAR'ам, но кто виноват, что линуксоиды так деплоят. В целом интерес к теме прослеживается и это не может не радовать.
UPD2: С нетерпением жду реакции анонимных аналитиков с ЛОРа.
Понравилось сообщение - подпишитесь на блог
Краткое резюме: очень быстро мигрировали Java EE приложение, использующее Hibernate, на мейнфрейм и провели сравнительное тестирование, с одной стороны данное приложение на zLinux + Oracle (2 LPAR), с другой - оно же на z/OS + DB2 (1 LPAR). Вариант на z/OS + DB2 работал быстрее в 3 раза. Конфигурация выбрана исходя из требований заказчика, для которого выполняли тестирование, но в принципе соответствует реальным практикам, почему-то именно так и разворачивают - на Linux стараются вынести каждую подсистему на свою виртуальную машину, на z/OS - весь стек разворачивается вместе, тем самым используются примущества операционной системы, в частности Cross-Memory Services - механизм, позволяющий из одного адресного пространства (WebSphere Application Server) обратиться к другому (DB2) с помощью нескольких машинных команд, минуя планировщик ОС. Преимущества подхода перед типичным кодом межпроцессной коммуникации (IPC), содержащем сотни, а то и тысячи машинных инструкций, да к тому же выполняющем обращения к ядру, очевидны любому инженеру, знакомому с операционными системами чуть глубже, нежели на уровне "интерфейс унылый/интерфейс неунылый".
Отдельно отмечу, что исключительно расчетная часть на Java под z/OS выполнялась быстрее на 25%, что является отдельным приветом сторонникам мнения "Java на мейнфрейме тормозит и вообще".
P.S. Очень распространенное заблуждение, что zLinux выполняется только на z/VM. В данном случае и z/OS и zLinux выполнялись на LPAR'ах, VM в тесте не участвовала.
UPD: Хабраэксперты не подкачали, адекватные комментарии и претензии затерялись в ворохе: "Мы веруем в Линуха святого, а вы говорите, что он в чем-то хуже? Вы все врети, вы - сурковскаяпропаганда!!!" Грамотность аудитории оставляет желать лучшего, но это - уже наша недоработка. Основная претензия - разнесение подсистем на линуксе по разным LPAR'ам, но кто виноват, что линуксоиды так деплоят. В целом интерес к теме прослеживается и это не может не радовать.
UPD2: С нетерпением жду реакции анонимных аналитиков с ЛОРа.
Понравилось сообщение - подпишитесь на блог
8 комментариев:
Можно вопросов пару ?
Почему такая разница по памяти (Oracle/WAS - (158+25) GB RAM, DB2/WAS - 32 GB) ?
Cколько было выделено под SGA у Oracle и буфферпулы у DB2 ?
Cеть между Oracle LPAR и zLinux LPAR нативная или гиперсокеты ?
Что по "шпинделям" было у обеих БД на DS8870 ?
Oracle тоже вы тюнили ? :)
Ресурсы выделялись согласно требованиям организаторов тестирования. Сеть между zLinux-LPAR'ами была нативная, гиперсокеты не использовались, с чем это связано трудно сказать, может быть желание проверить "а как это будет на распределенных системах". На вопросы, касающиеся СУБД я ответить не могу - не специалист, еще что-нибудь напутаю, некрасиво выйдет. Оракл тюнили другие люди, не наша команда.
Любопытно.
Интуитивно понятно, что обмен данными между приложениями внутри одной ВМ намного быстрее, чем между приложениями, которые на разных ВМ.
Тем не менее должны быть средства, которые частично исправляют ситуацию.
Например, в Xen можно использовать для обмена между приложениями, которые на разных ВМ, общую память.
Многое RDMA-оборудование умеет аппаратно копировать данные между приложениями на разных ВМ.
Похоже, что Cross-Memory Services локальный аналог RDMA. Как бы криво это ни звучало ;-)
Есть ли IBM zEnterprise EC12 RDMA-оборудование (наивный вопрос - оно там просто обязано быть)?
Если я правильно понял то, о чем вы говорите, то это - HiperSocket'ы. Да, конечно на мейнфрейме они есть, но в данном тесте не участвовали.
HiperSocket's - для коммуникации между ВМ. Наверное JVM их может прозрачно использовать.
А если нужно соединить два мейнфрейма, то что используется?
В обычных серверах часто используется железяка с RDMA, например, InfiniBand какой-нибудь.
На мейнфреймах аналогично - InfiniBand.
А вы можете дать такие цифры: цена за RedHat support for Enterprise Linux против IBM support for z/OS? Может, это что-то решает.
Цифр дать не могу. Понятно, что нужно считать комплексно: IFL vs CP, количество тех и других, стоимость ПО, стоимость специалистов на рынке, но главное - не забыть посчитать стоимость минуты простоя внедряемой информационной системы и потери данных, которая вполне может перевесить все остальные соображения.
З.Ы. А еще так бывает, что специалисты по Linux не могут выдать работающее решение, а по z/OS - могут...
Отправить комментарий
Любой Ваш комментарий важен для меня, однако, помните, что действует предмодерация. Давайте уважать друг друга!