Computing power comparison: mainframe versus Intel Xeon

[Dmitry67]

Я не дистанцировался, просто выходные

Я хотел напомнить про статью c хабра, которую привел. Ребята взяли макбук, раааз, десяток баз сравнили. Наверняка за неделю макс. Теперь мы им говорим - все отлично, но вы забыли про МФ и Экзадату. И вот тут ребята почешут затылок. Экзадата кстати есть в облаке? Наверняка за неделю тестов ее стоимость будет как 10 макбуков. С МФ вообще все плохо.

С тем же MS SQL я могу чуть забашлять Амазону и через полчаса получить машинку на поиграться. Где я могу поиграться с МФ? Вот вы бы хотели раскрыть студентам прелести МФ, соблазнить их так сказать))). И знаете как это придется делать? Мелом на доске. Как в моем далеком студенчестве, когда я был от 30ки между 9 и 10 классом на практике в университете. Мы писали на Паскале не в редакторе, а мелом на доске две недели. А машинное время нам так и не дали)))

[zVlad]

Я не дистанцировался, просто выходные

Я хотел напомнить про статью c хабра, которую привел. Ребята взяли макбук, раааз, десяток баз сравнили. Наверняка за неделю макс. Теперь мы им говорим - все отлично, но вы забыли про МФ и Экзадату. И вот тут ребята почешут затылок. Экзадата кстати есть в облаке? Наверняка за неделю тестов ее стоимость будет как 10 макбуков. С МФ вообще все плохо.

С тем же MS SQL я могу чуть забашлять Амазону и через полчаса получить машинку на поиграться. Где я могу поиграться с МФ?

Дима, но мы же с flip_flop обсуждаем уже проделанную работу по сравнению разных платформ. Нам не надо самим добывать мф, добывать х86 сервера, писать одинаковые транзакции на одинаковые по структуре и, я надеюсь, объемы баз данных, замерять результаты. Все это за нас сделали. Теперь мы может все что было сделано и сведено в отчет обсудить.
По сути конечно обсудить отчет и то как устроители организовали свои испытания, но это же тоже основа для научного анализа. Физики вон строят гигантские коллайдеры, гоняют там потоки частиц ждут когда они соударятся и им удастся что-нибудь увидеть и померять и им удается делать открытия которых никто не знал.
В нашем то случае все намного проще. Все параметры известны и есть результаты одинаковых нагрузок. Что нам не хватает кроме этого и критического мышления чтобы увидеть где мухи а где котлеты?

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

P.S. Физики почему то не просят матушку-природу выполнять процессы помедленнее, и чтобы частицы были покрупнее, а то их трудно изучать.
У нас то все рукотворное, сами мы, люди, все это придумали и сделали. А мы здесь на форуме никак не можем понять почему золото дороже железа в то время как и то и другое металы. Парадокс!

[mskmel]

Я хотел напомнить про статью c хабра, которую привел. Ребята взяли макбук, раааз, десяток баз сравнили. Наверняка за неделю макс. Теперь мы им говорим - все отлично, но вы забыли про МФ и Экзадату. И вот тут ребята почешут затылок. Экзадата кстати есть в облаке? Наверняка за неделю тестов ее стоимость будет как 10 макбуков. С МФ вообще все плохо.

У них данных 800МБ, там не экзадату или МФ, а то что именно они сделали - кастомный продукт на C\C++
Индивидуально запиленный инструмент всегда победит generic решение.

[Dmitry67]

Я хотел напомнить про статью c хабра, которую привел. Ребята взяли макбук, раааз, десяток баз сравнили. Наверняка за неделю макс. Теперь мы им говорим - все отлично, но вы забыли про МФ и Экзадату. И вот тут ребята почешут затылок. Экзадата кстати есть в облаке? Наверняка за неделю тестов ее стоимость будет как 10 макбуков. С МФ вообще все плохо.

У них данных 800МБ, там не экзадату или МФ, а то что именно они сделали - кастомный продукт на C\C++
Индивидуально запиленный инструмент всегда победит generic решение.

Ну тестировали они на маленьком примере
Но поинт то не в том
Как мне пожамкать руками exadata или МФ?

[zVlad]

Я хотел напомнить про статью c хабра, которую привел. Ребята взяли макбук, раааз, десяток баз сравнили. Наверняка за неделю макс. Теперь мы им говорим - все отлично, но вы забыли про МФ и Экзадату. И вот тут ребята почешут затылок. Экзадата кстати есть в облаке? Наверняка за неделю тестов ее стоимость будет как 10 макбуков. С МФ вообще все плохо.

У них данных 800МБ, там не экзадату или МФ, а то что именно они сделали - кастомный продукт на C\C++
Индивидуально запиленный инструмент всегда победит generic решение.

Ну тестировали они на маленьком примере
Но поинт то не в том
Как мне пожамкать руками exadata или МФ?

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

Ты замутил эту дискуссию (драку) и сам же спрятался в кустах. Не солидно поступаешь.

[mskmel]

Но поинт то не в том
Как мне пожамкать руками exadata или МФ?

https://cloud.oracle.com/en_US/cost-estimator
Data Management
Oracle Database Exadata Express Cloud Service
поиграться с ценой. Судя по всему в несколько сотен в год вложиться можно с чем то очень маленьким Только не понятен смысл "пожмакать". Без storage server это обычный 2х сокетный сервер, с ожидаемой производительность. Storage server на минимальных 20ГБ даты смысла великого не имеет.
В теории можно поднять storage server у самого себя, понятно что скорости будут не те, но на "пожмакать" хватит.

[Dmitry67]

Прочти внимательно то что приводил flip_flop в начале тобой же открытой темы и взяв референс на документ упоминавшийся в тобой же приведенной ссылке. Там пишут о том как они жамкали МФ, какой МФ, чем жамкали - там все есть, правда это надо критически анализировать потому что приемы их умозаключений не чистые и не корректные.

Вы серьезно предлагаете мне ДОКУМЕНТ вместо реального доступа к машине?
Это все равно что предложить журнал с картинками вместо реальной девушки)
Конечно, и с журналом кое чего можно достичь, но это не то чего хочется

[zVlad]

Прочти внимательно то что приводил flip_flop в начале тобой же открытой темы и взяв референс на документ упоминавшийся в тобой же приведенной ссылке. Там пишут о том как они жамкали МФ, какой МФ, чем жамкали - там все есть, правда это надо критически анализировать потому что приемы их умозаключений не чистые и не корректные.

Вы серьезно предлагаете мне ДОКУМЕНТ вместо реального доступа к машине?
Это все равно что предложить журнал с картинками вместо реальной девушки)
Конечно, и с журналом кое чего можно достичь, но это не то чего хочется

Не, Дима, тут совсем другое. Ну дадут тебе МФ и что ты с ним делать то будешь? Эту девушку тебе все равно не станцевать.
Так что читай журнал если конечно всерьез хочешь что-то понять и обсудить, а не для разговора ни о чем.

[Dmitry67]

Не, Дима, тут совсем другое. Ну дадут тебе МФ и что ты с ним делать то будешь? Эту девушку тебе все равно не станцевать.
Так что читай журнал если конечно всерьез хочешь что-то понять и обсудить, а не для разговора ни о чем.

То есть вы ходите сказать, что те ребята, которые играючи подцепили под свою задачу 10 разных баз для сравнения, с МФ не справятся или залипнут на месяцы? Кому нужна система с таким большин уровнем вхождения....

[Boriskin]

По поводу процессоров и их скорости - не стоит принижать ни современные процессоры для z14 МФ ("бегут очень медленно") ни современные х86 процессоры ("застой где-то с 201х года"). Ни то, ни другое не отражает действительности. Я могу очень детально привести аргументы с точки зрения микроэлектроники и немного с точки зрения низкоуровневой архитектуры, но боюсь никому не будет интересны такие детали.

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

[mskmel]

А там что под лозунгом "так принято" ввод-вывод зажали до 2 Gb/sec против 8 Gb/sec.
...
Ну и ты не будешь спорить ведь что в 1TB помещается в 128 раз больше данных чем в 8 GB и если данные запрашиваются повторно и их еще не прекрыли новые данные

Узким местом каналы к дискам, и вообще производительность БД, там не были, пруфы:
- рост латентности транзакции на Z при достижении 95% CPU - 7 страница первый абзац и график на 11
- почти вся нагрузка от app server - page 9
- несущественное увеличение TPS когда БД убрали с DL980 на другой сервер - табличка на стр 10

[zVlad]

Не, Дима, тут совсем другое. Ну дадут тебе МФ и что ты с ним делать то будешь? Эту девушку тебе все равно не станцевать.
Так что читай журнал если конечно всерьез хочешь что-то понять и обсудить, а не для разговора ни о чем.

То есть вы ходите сказать, что те ребята, которые играючи подцепили под свою задачу 10 разных баз для сравнения, с МФ не справятся или залипнут на месяцы? Кому нужна система с таким большин уровнем вхождения....

Те ребята (я их не знаю конечно и могу ошибаться) счастливы тем что они знают и умеют. На предложение освоить что-нибудь по МФ они ничего кроме круглых глаз предявить не смогут. Заниматься надо тем что нужно. Вот и тебе совершенно не хочется читать готовый материал по теме которую ты (все таки ты, не я и не flip_flop) зачем то открыл.

Но те же самые ребята (или даже ты) попав в определенную среду и обстоятельства легко изучат и будут работать не только на МФ, но и например на балалaйке, или самосвале. Люди не рождаются для чего-то одного, например, для Маков.

Я только что созванивался с твоим коллегой - MS SQL DBA, работающим у нас и поддерживающим реплику с моего DB2. Хотел обсудить с ним один маловажный вопрос связанный с той аппликухой, которая стоит на его сервере и занимается репликацией и с которой я работаю с легкой руки моей предшественницы ушедшей на пенсию, которая из любопытства перетянула эту работу в нашу группу, и которую я скоро буду передавать тому MS SQL DBA.
Его звать Сергей и он, как обычно, сказал что ужасно занят и перезвонит после обеда. Но знаю что он не перезвонит и поэтому сказал ему не беспокоится и забыть.
Я знаю почему таким ребятам нравится работать не на МФ - им нравится быть все время "занятыми". А вот у меня масса свободного времени в офисе. В то же время я уже с утра два запроса выполнил.

[zVlad]

А там что под лозунгом "так принято" ввод-вывод зажали до 2 Gb/sec против 8 Gb/sec.
...
Ну и ты не будешь спорить ведь что в 1TB помещается в 128 раз больше данных чем в 8 GB и если данные запрашиваются повторно и их еще не прекрыли новые данные

Узким местом каналы к дискам, и вообще производительность БД, там не были, пруфы:
- рост латентности транзакции на Z при достижении 95% CPU - 7 страница первый абзац и график на 11
- почти вся нагрузка от app server - page 9
- несущественное увеличение TPS когда БД убрали с DL980 на другой сервер - табличка на стр 10

Ну наконец то хоть что-то внятное и по делу. Дождался.

Старница 7 про транзакции (OLTP), а странице 9 про batch, который кстати в этой работе для z представлен прогoнами одного задания zRefBR, и двух заданий zRefBU - на МФ никогда так не делают. Даже если МФ имеет только пакетную загрузку то это спроектираванно так чтобы CPU byl 100% busy 24 hours. У нас был такой mainframe, я правда на нем не работал - соседский. У нас же пакетные задания выполняются 24*7 по schedule тогда когда это надо, некоторые запускаются, скажем, каждые 10 минит другие 15 минут и т.д. И все это в параллель с 24*7 OLTP.

Вернемся, однако, к OLTP на странице 7. Как раз то что latency стал расти не достигнув 100% CPU busy и говорит, с очевидностью, о том что начался bottleneck где то в вводе-выводе или памяти (или и там и там). Нам не показали ни страничного обмена, который идет на те же самые диски по тем же самым каналам (других нет) где и БД находится, ни загрузки ввода-вывода. Мне бы очень хотелось хотя бы увидеть вот этот параметр:

Code: Select all

_______Field_______          __Value__
Unreferenced Intvl Cnt           22188

Насколько бы увеличился TPS если бы они сумели нагрузить CPU do 100% - а это вполне нормально для z/OS - устранением bottleneck сказать невозможно, но я бы ожидал приличного роста, именно либо от увеличения RAM, либо от подключения дисков хотя бы не через switch-и, что в работе отнесено как обычной практике, но я с этим категорически не согласен - обычно диски подключают напрямую к FICON.
Резюме: МФ даже в том для чего тест делали - сравнить MIPS-ы CPU - не был нагружен и причина была не в CPU. Вот в чем беда этого теста.
И я еще раз повторю именно 95% CPU показывает наличие проблемы в другом, не CPU, месте. Вы с этим согласны?

[Flash-04]

У тебя интересные конечно возражения. Я помню как в свое время воевал за то чтобы получить к приложению жадному до I/O (с Oracle внутри) специальный SSD сторидж на 4 Tb с подключением через fiber channel. Приложение ессно бегало на x86 и задыхалось под нагрузкой. В итоге денег на сторидж не дали, приложение мигрировали на более мощный сервер и к тому времени у нас уже появились shared EMC2 SSD сториджи, и стало бегать существенно бодрее. Затык был именно в системе ввода-вывода потому что из диагностики было хорошо видно что процессоры простаивпют в ожидании и когда закончатся операции чтения-записи.
К чему это я? А к тому что получается x86 ни причём, а причём обвязка из внешних систем. Собсно Влад, твои аргументы выглядят примерно так же - "вам не нравятся кошки, потому что вы их не умеете готовить"

Я знаю людей который ту же самую систему с Ораклом ставили на спец железо от Оракла и получали просто фантастическую производительность. И заметьте, без мейнфрейма.

[zVlad]

....
К чему это я? А к тому что получается x86 ни причём, а причём обвязка из внешних систем. Собсно Влад, твои аргументы выглядят примерно так же - "вам не нравятся кошки, потому что вы их не умеете готовить"

Я знаю людей который ту же самую систему с Ораклом ставили на спец железо от Оракла и получали просто фантастическую производительность. И заметьте, без мейнфрейма.

Нет у меня таких аргументов. Я четко указал на причины почему по моему (а у меня в этом большой опыт) МФ в этом тесте выглядит ниже своих возможностей, используя общепринятые и понятные обяснения (я не говорил про не умение готовить кошек). То что ты привел из своего опыта это один в один то о чем я говорю только кроме ввода-вывода в этом случае еще и с размером RAM явно погоречились. Причем я не говорил даже оо выравнивании параметров используемог х86 с аналогичными на МФ. Память в 32 GB и прямое, без switches, подключение дисков к FICON могут изменить картину в разы с тем же LPAR что в HP test достигнуто. Я сказал что-нибудь о кошках, или о не умении их готовить?
x86 пока не причем. В тесте HP использованны на то время реально супермощные сервера. МФ же был взят махонький да еще и с зажатыми параметрами.
Фантастической производительности не бывает, бывает та которую можно достичь на оборудовании определенной производительности. МФ могут быть малехонькие и реально гигантские (фантастические). И их результаты соответственно тоже будут разными. Никому не нужна абстрактная фантастическая производительность. Нужна та что удовлетворяет потребности. Это довольно не простая задача - right sizing. Да, за ней, из-за дешевизны, на х86 не гоняются, но это временно.
На мой взгляд как раз в клаудах начнется понимание что выстаивание рядов стоек с тысячами х86 серверов и их недогруз не есть хорошо. A поскольку пользователям нужны сервисы, а не сервера x86, то и подменить сервера будет не сложно - никто не заплачет если вместо х86 результат им даст тот или иной МФ, или что вероятней гибридная установка из МФ и x86 (Xeon) блэйдс - zBX: https://www.theregister.co.uk/2011/01/1 ... bx_update/ Этой истории уже больше 7 лет..