What System z can do that Intel® can’t

[zVlad]

Рекомендую посмотреть вот эту презентацию с того же евента о котором я говорил с самом начале. Туту много технических моментов и есть данные о тестах на разных платформах.
Не торопипесь относить к коммерческому бреду, попробуйте отнестись обективно. А может вам повезет конструктивно опровергнуть эти тесты и выкладки. Это было бы интересно.


ftp://public.dhe.ibm.com/software/os/sy ... ics_v4.pdf

[zVlad]

кстати, Влад, вспомните мой разбор тестов Зибель на МФ, там были бач тесты. с ростом нагрузки никакой магии не произошло. я разбирал детально.
не зибель, а peoplesoft viewtopic.php?p=4677137#p4677137

Я обязательно посмотрю это и дам мой комент (мне надо отлучится), а пока рекомендую пролистать страницы 16-28 вот этой презентации (это имеет отношение к тому что Вы говорите):

ftp://public.dhe.ibm.com/software/os/sy ... n_t_v5.pdf

[zVlad]

....зВлад, я прекрасно понимаю разницу между суперкомпютерами и МФ. Приведенный пример отдельного сервера всего лишь иллюстрировал возможности отдельных серверов архитектуры на Хеонах на Санди Бридже. Потому что сравнивать шкаф МФ с по сути десктопным вариантом сервера (маленький ящичек) не корректно. Давайте сравнивать сопоставимое - шкаф со шкафом. Какие конкретно шкафы используется в системах дебита-кредита на практике сейчас - не знаю, не буду спорить. Могу лишь порассуждать о тенденциях будущих шкафов на Хеонах и трендах сближения суперкомпютеров и серверов больших данных. Если конечно, интересно кому либо.

Вообще говоря IBM утверждает что их МФ надо сравнивать не с отдельным шкафом, а с группой серверов несущих на себе некое приложение в виде продакшн и сопутствующих инстанс - Dev, QA, Training, DR. И я, по своему опыту работы склонен с ними сиглашаться. У нас так и есть - на одном весьма скромном по сравнению с самими же МФ стоят все истансы довольно важного приложения довольно крупной компании. Я говорил недавно о Клиенте3 ушедшего с МФ на неизвестно пока что. Там МФ вообще были игрушечные я бы сказал - один z10 E10-A01 с 26 MIPS Dev, QA и все остальное и z10 E10-N02 - 319 MIPS продакшн. У нас второе приложение, которое используется в моей терминологии Клиентом1 и Клиентом2, со всеми инстансами плус корпоративная batch scheduling system которая все batch jobs запускает на всех наших Юникс и Wintel серверах плус системный sandbox все это стоит на z10 A03 с 69 MIPS-ами. И этот же MF - DR site для первого приложения.

Вот мы приводим разные цифры характеризующие разные шкафы, и цифры эти большие и порой в шакафах на Xenonax они больше чем в шкафах МФ, но мы редко говорим что на каждой плате Ficon два RISC процессора и они тоже ведь что там делают, но их не учитывают, смотрят на 100 коров CPU и думaют что это все что имеет МФ. А еще есть OSA карты которые на самом деле не просто сетевые карты - это рутеры, свитчи - сетевая архитектура, с софтом z/OS обеспечивают все сетевые сервисы какие только можно представить. У меня есть диапазоны IP адресов в нашей локальной сети и я их по своему усмотрению использую в разных приложениях выполняющихся в одной и той же системе, кроме того мои системы в рамках одного МФ обединены во внутреннюю сеть, которя использует память для связи разных LPAR, т.е. скорость в ней в несколько раз выше чем во "внешней" многогигабитной сети. Есть и криптография и аппаратное сжатие данных. Это все в любом МФ есть даже если это МФ с одним CPU.

Что касаемо "шкафов на Хеонах " то я думаю что им надо хорошую развитую OS, типа z/OS, но это гораздо сложнее чем напихать в шкaф много микросхем. Ни Windows ни Linux к этому не готовы. VMWare частично решает проблему использования мощей этих шкафов, но тоже не так эффективно потомучто с виртуальными машинами количество не всегда переходит в качество. У Оракл есть теперь свое железо. MS SQl такие мощи не нужны. Путь MS SQL - это сотни мелких инстанцев. У DB2 for LUW тоже есть свое железо. Так что перспективы не такие уж и радужные с этим, как я понимаю - суперкомпютер для узкого класса задач.

[iDesperado]

Я обязательно посмотрю это и дам мой комент (мне надо отлучится)

лучше прокомментируйте соседний тест
http://www.oracle.com/us/solutions/benc ... 166099.pdf

почему конкретно в этом тесте никакой магии не произошло ? почему при 500 пользователях Weighted avg response 1.873, а при 1426 уже 2.557. транзакция quick create company почти в двое стала медленнее идти по сравнению с single user тестом.

[iDesperado]

Смысл такой конструкции имеется именно на МФ. МФ никогда не используется на 100% физической мощности. Имеется в виду что сконфигурировананая мощность практически всегда ниже потенциальной мощности. В этом есть большой финансовый смысл потому что плата за лизензию на ключевой софт (да и на хард тоже) зависит о сконфигурированной мощности МФ.
Конкретно унас два МФ сконфиурированы следущим образом:

- MF1 - 5 CPU, 1000 MIPS
- MF2 - 3 CPU, 76 MIPS

В принципе оба МФ одинаковы с одинаковой начинкой. Они имеют наверное 12 CPU из которых 5 могут быть сконфигурированы как general purpose CPU и еще 5 как specialty engines.
В случае ДР, например потери МФ1 (а МФ1 и МФ2 баходятся в километрах друг от друга). Мощность МФ2 увеличивается до 1500 MIPS. Увеличивается несколькими кликами v Web морде хоть у меня дома с того лаптопа на котором я пишу этот текст.

так это же экономически не оправданно. 5 цпу влазит в модель z114. эта модель почти в 2 раза дешевле, чем ЕС12 с 12 цпу. полностью набитый z114 с пятью цпу - $2.5 млн, а такой же по мощности EC12 уже $3.5 млн

[zVlad]

кстати, Влад, вспомните мой разбор тестов Зибель на МФ, там были бач тесты. с ростом нагрузки никакой магии не произошло. я разбирал детально.
не зибель, а peoplesoft viewtopic.php?p=4677137#p4677137

После этого Вашего поста мы с вами обменялись множеством постов. Вы что хотите их снова повторить в этой теме? Или может доберетесь до конца той дискусии самостоятельно.

Кстати я удосужился почитать дальше, там много было не ясностей и я обращался даже в ИБМ за разяснениями. Вот один из их ответов который Вы явно пропистили мимо ушей:

Kроме Майка, который ничего еще так и не ответил, на меня вышли три человека из ИБМ. Только что обменялись письмами. Один из них поведал:

Vlad:

A comparison of just hardware costs will almost always show the mainframe as higher cost, however it is the total costs which really matter. I did a sizing just yesterday to migrate an Oracle environment running on Sun Solaris (three T6320 blades and four M8000 servers with a total of 68 cores and 768 GB of memory) to System z. The System z sizing was 13 z196 IFLs and 300 GB of memory. The big difference here is the Oracle licenses costs at 78 licenses (after applying the core factor) on Solaris vs 13 on System z. When all the items are added up, System z is lower cost just on TCA and only gets better if you look at TCO.

Вот еще интересная инфа:

Это ровным счетом ни о чем не говорит. Современные крупные компании любят посщекотать нервы другим конкурирующим компаниям сообщениями о сотрудничестве и кооперировании. На самом деле все может быть по разному в каждом конкретном случае. По нашему конкретному случаю вот что мне только что ответили из ИБМ:

хи-хи, по вашему оракл темной ночью выкрал МФ у IBM и создал фиктивный центр и путем угроз заставил IBM написать о том, что в этом центре 10 тысяч IBM-спецов ? если это так, то чо делал в этом центре Mike Curtis в январе 2010 ?

...

МФ Оракл купил у ИБМ для собственных нужд. Оракл осуществляет свои разработки и саппорт для МФ на этом МФ. В этом центре точно нет 10 000 специалистов, их вообще столько нет ни у Оракла ни у ИБМ по этой теме.
Mike Curtis работает не в IBM Oracle ICC, а чисто в Оракл. По крайней мере так следует из его подписи в e-mail. И, насколько я понимаю, работает там (начиная в PeopleSoft) уже 13 лет.
Ответ из ИБМ я привел без редактирования, так что спрашивать меня не надо. Они сказали то что Вы прочитали - один из главных специалистов по DB2 не в курсе этих тестов вообще, не в курсе даже что они имели место состояться. Мое впечатление по переписке, что и другие парни из ИБМ тоже не в курсах были (ни одного ответа на свои технические вопросы я пока не получил по крайней мере).

А вот чем видимо закончилась та нaша дискуссия:

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

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

Это и без документов абсолютно очевидно что по МФ никакого сайзинга не проводилось. Был взят тот МФ который (единственный) был у Оракл. Тест проводили так как если это был не МФ а SPARC или какой другой х86. Результат получился такой какой получился. Анализировать и делать выводы никто не взялся. Я уверен Вы, iDesperado, единственный в мире человек который сравнил два результата, а я единственный в мире человек который попытался разобраться и объяснить результат на МФ. ИБМ поступил мудро много лет назад, когда прекратил участвовать в нерелевантных для МФ тестах типа ТРС, но запретить другим (Оракл) ИБМ не может, сказать что Оракл ничего не понимает в МФ они тоже не могут. Но к общей радости никто, кроме нас с Вами, всерьез ничего этого не воспринимают и не используют нигде в жизни. Люди живут совсем другим на самом деле.

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

[zVlad]

Смысл такой конструкции имеется именно на МФ. МФ никогда не используется на 100% физической мощности. Имеется в виду что сконфигурировананая мощность практически всегда ниже потенциальной мощности. В этом есть большой финансовый смысл потому что плата за лизензию на ключевой софт (да и на хард тоже) зависит о сконфигурированной мощности МФ.
Конкретно унас два МФ сконфиурированы следущим образом:

- MF1 - 5 CPU, 1000 MIPS
- MF2 - 3 CPU, 76 MIPS

В принципе оба МФ одинаковы с одинаковой начинкой. Они имеют наверное 12 CPU из которых 5 могут быть сконфигурированы как general purpose CPU и еще 5 как specialty engines.
В случае ДР, например потери МФ1 (а МФ1 и МФ2 баходятся в километрах друг от друга). Мощность МФ2 увеличивается до 1500 MIPS. Увеличивается несколькими кликами v Web морде хоть у меня дома с того лаптопа на котором я пишу этот текст.

так это же экономически не оправданно. 5 цпу влазит в модель z114. эта модель почти в 2 раза дешевле, чем ЕС12 с 12 цпу. полностью набитый z114 с пятью цпу - $2.5 млн, а такой же по мощности EC12 уже $3.5 млн

Я Вас не понял. Что именно экономически не оправдано? У нас как раз z114 и есть.
Если я правильно Вас понял Вы сравниваете EC12 c 12 CPU c z114 c 5 CPU для одного и того же значения MIPS? Но EC12 это совсем другой конструктив позволяющеий наращивать мощность до предела, до 78 000 MIPS на 100 CPU, a z114 - это максимум 5 CPU и 5 specialty engines. Если вы видите что укладываетесь в z114 вам нет никакой надобности покупать EC12. Есть еще вариант начать с EC12 c 5 CPU который выдаст те же MIPS-ы что и z114 c 5 CPU, но будет дешевле чем EC12 c 12 CPU.

[flip_flop]

Что касаемо "шкафов на Хеонах " то я думаю что им надо хорошую развитую OS, типа z/OS, но это гораздо сложнее чем напихать в шкaф много микросхем. Ни Windows ни Linux к этому не готовы.

Линуксы (по крайней мере энтерпрайз линукс RHEL, SLES) с таким железом и справляются - приведенный сервер от SGI (UV-2000) как раз находится на пределах Линукса (4096 thread, OS - one instance), как отмеченно в документации. Сей сервер предназначен не столько для суперкомпьютеров сколько для больших данных и аналитики. Отличительной особенностью является большой обьем общей глобальной памяти (global shared memory) - 64 ТБ (рекордный показатель), что делает возможным использование больших данных целиком в памяти. Появились, кстати, разные Hadoop и HANA, специально для ширпотреба и больших данных. В одной из ваших ссылок как раз приведен обзор МФ для больших данных, обзор для подхода SGI тоже имеется. Было бы интересно посмотреть на результаты тестов систем больших данных, когда они будут готовы. Но только, я умоляю, не от IBM по сравнению MF с десктопом или от IBM по сравнению MF с неким анонимным конкурентом, а нечто типа tpc-c или spec.org.

[zVlad]

Я обязательно посмотрю это и дам мой комент (мне надо отлучится)

лучше прокомментируйте соседний тест
http://www.oracle.com/us/solutions/benc ... 166099.pdf

почему конкретно в этом тесте никакой магии не произошло ? почему при 500 пользователях Weighted avg response 1.873, а при 1426 уже 2.557. транзакция quick create company почти в двое стала медленнее идти по сравнению с single user тестом.

Это tree-tier (в тексте говорится four-tier, но я обычно клиентскую часть не считаю). Какой из трех вносил ту составляющюю в response time которая росла с ростов количества юзеров там не сказано. Больше всего был загружен по CPU App server (82%), меньше всего Web server (24%), и по середине DB server(64% - смешная загрузка для МФ).
Вот если бы все это стояло на одном МФ тогда было бы интересно и имело бы отношение к нашей дискусии, а так нет, не имеет никакого отношения и не интересно. Интересно только сопоставление количеств CPU и памяти всех трех уровней. Самые меньшие цифры мы видим у МФ. 16 CPU Web and App c 17 GB memory грузили 5 CPU DB c 2 GB memory.

Мой ответ App server сдох раньше всех, вот и выросла response time. A App server стоял не на МФ.

P.S. Кстати, z990 2003-го года имел чуть меньше 2000 MIPS на 5 CPU и это был Enterprise Class. Современный z114 - Business Class - с 3 CPU (model Z03) имеет чуть больше 2000 MIPS.

[flip_flop]

У DB2 for LUW тоже есть свое железо. Так что перспективы не такие уж и радужные с этим, как я понимаю - суперкомпютер для узкого класса задач.

Интрига состоит в том, что ИБМ также обявила об акселераторах для Db2+Hadoop , то есть серверы на ширпотребе они тоже будут ускорять и продвигать.

[zVlad]

У DB2 for LUW тоже есть свое железо. Так что перспективы не такие уж и радужные с этим, как я понимаю - суперкомпютер для узкого класса задач.

Интрига состоит в том, что ИБМ также обявила об акселераторах для Db2+Hadoop , то есть серверы на ширпотребе они тоже будут ускорять и продвигать.

Как акселератор у меня нет сомнений - это будет что доктор прописал. Вы тоже увидели как ИБМ грамотно поженили МФ с не-МФ-ами?

[zVlad]

Что касаемо "шкафов на Хеонах " то я думаю что им надо хорошую развитую OS, типа z/OS, но это гораздо сложнее чем напихать в шкaф много микросхем. Ни Windows ни Linux к этому не готовы.

Линуксы (по крайней мере энтерпрайз линукс RHEL, SLES) с таким железом и справляются - приведенный сервер от SGI (UV-2000) как раз находится на пределах Линукса (4096 thread, OS - one instance), как отмеченно в документации. Сей сервер предназначен не столько для суперкомпьютеров сколько для больших данных и аналитики. Отличительной особенностью является большой обьем общей глобальной памяти (global shared memory) - 64 ТБ (рекордный показатель), что делает возможным использование больших данных целиком в памяти. Появились, кстати, разные Hadoop и HANA, специально для ширпотреба и больших данных. В одной из ваших ссылок как раз приведен обзор МФ для больших данных, обзор для подхода SGI тоже имеется. Было бы интересно посмотреть на результаты тестов систем больших данных, когда они будут готовы. Но только, я умоляю, не от IBM по сравнению MF с десктопом или от IBM по сравнению MF с неким анонимным конкурентом, а нечто типа tpc-c или spec.org.

Данные в памяти ето палка о двух концах. Приложения где используют МФ нуждаются в DR, т.е. в репликации всех изменений на DR site. Сейчас это делают дисковые подсистемы автономно. А как это делать с данными в памяти? Как они материлизоваться будут?

[flip_flop]

У DB2 for LUW тоже есть свое железо. Так что перспективы не такие уж и радужные с этим, как я понимаю - суперкомпютер для узкого класса задач.

Интрига состоит в том, что ИБМ также обявила об акселераторах для Db2+Hadoop , то есть серверы на ширпотребе они тоже будут ускорять и продвигать.

Как акселератор у меня нет сомнений - это будет что доктор прописал. Вы тоже увидели как ИБМ грамотно поженили МФ с не-МФ-ами?

В данном случае рассматривалось применение акселлераторов на основе ПЛИС (FPGA) для серверов на ширпотребе, аналогично применению акселлераторов на основе тех же ПЛИС для МФ. Не то что Вы подумали.

[iDesperado]

Если я правильно Вас понял Вы сравниваете EC12 c 12 CPU c z114 c 5 CPU для одного и того же значения MIPS? Но EC12 это совсем другой конструктив позволяющеий наращивать мощность до предела, до 78 000 MIPS на 100 CPU, a z114 - это максимум 5 CPU и 5 specialty engines. Если вы видите что укладываетесь в z114 вам нет никакой надобности покупать EC12. Есть еще вариант начать с EC12 c 5 CPU который выдаст те же MIPS-ы что и z114 c 5 CPU, но будет дешевле чем EC12 c 12 CPU.

так я же именно об этом и говорю, ваша схема с 12 CPU из которых 7 и 9 CPU в запасе под DR не имеет экономического смыла.

- MF1 - 5 CPU, 1000 MIPS
- MF2 - 3 CPU, 76 MIPS

В принципе оба МФ одинаковы с одинаковой начинкой. Они имеют наверное 12 CPU из которых 5 могут быть сконфигурированы как general purpose CPU и еще 5 как specialty engines.

вы для нагрузки, которую тянет z114 предлагаете брать EC12, что привете к лишним тратам в миллионы. три отдельных z114 из которых один запасной для первых двух обойдется гораздо дешевле.

[flip_flop]

Данные в памяти ето палка о двух концах. Приложения где используют МФ нуждаются в DR, т.е. в репликации всех изменений на DR site. Сейчас это делают дисковые подсистемы автономно. А как это делать с данными в памяти? Как они материлизоваться будут?

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

[iDesperado]

Кстати я удосужился почитать дальше, там много было не ясностей и я обращался даже в ИБМ за разяснениями. Вот один из их ответов который Вы явно пропистили мимо ушей:

это не правда, я сразу написал, что подозреваю этого человека употреблении наркотиков, если он на 68 ядер получает 78 оракловых лицензий.
viewtopic.php?p=4681551#p4681551

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

объясняю. как только мы берем реальные тесты, а не выдуманные, мы видим диаметрально противоположную вашим рассказам картину. мы видим, что в реальной жизни, когда серьезные специалисты на МФ запустили ту же задачу, что на SPARC сервере, МФ затратил больше времени на обработку данных. множество ваших сообщений на эту тему этот факт никак не опровергли, а скорее добавили подробностей.


в продолжение к этому тесту я нашел еще один
http://www.oracle.com/us/solutions/benc ... 166414.pdf
http://www.oracle.com/us/solutions/benc ... 166419.pdf

тут запустили совсем идентичный batch тест. на обоих машинах запускали Large model, на обоих Large model с 14 потоков. т.е. условия тестирования были идентичны. писюк обрабатывал 298,507 строк в минуту, МФ с тем же кол-вом процессоров лишь 113,207 в минуту.

[Интеррапт]

Не совсем в тему.... Но XBox отказался от айбиэмовской PowerPC архитектуры и следующий XBox будет x86-64.

[zVlad]

Если я правильно Вас понял Вы сравниваете EC12 c 12 CPU c z114 c 5 CPU для одного и того же значения MIPS? Но EC12 это совсем другой конструктив позволяющеий наращивать мощность до предела, до 78 000 MIPS на 100 CPU, a z114 - это максимум 5 CPU и 5 specialty engines. Если вы видите что укладываетесь в z114 вам нет никакой надобности покупать EC12. Есть еще вариант начать с EC12 c 5 CPU который выдаст те же MIPS-ы что и z114 c 5 CPU, но будет дешевле чем EC12 c 12 CPU.

так я же именно об этом и говорю, ваша схема с 12 CPU из которых 7 и 9 CPU в запасе под DR не имеет экономического смыла.

- MF1 - 5 CPU, 1000 MIPS
- MF2 - 3 CPU, 76 MIPS

В принципе оба МФ одинаковы с одинаковой начинкой. Они имеют наверное 12 CPU из которых 5 могут быть сконфигурированы как general purpose CPU и еще 5 как specialty engines.

вы для нагрузки, которую тянет z114 предлагаете брать EC12, что привете к лишним тратам в миллионы. три отдельных z114 из которых один запасной для первых двух обойдется гораздо дешевле.

Ничего подобного я не предлагал. В моем пример DR количество ЦПУ остается не изменным в случае DR, мощность увеличивается на том же количестве ЦПУ.

[zVlad]

Данные в памяти ето палка о двух концах. Приложения где используют МФ нуждаются в DR, т.е. в репликации всех изменений на DR site. Сейчас это делают дисковые подсистемы автономно. А как это делать с данными в памяти? Как они материлизоваться будут?

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

Можно, но это неизбежно удорожит проект. Кроме того данные в БД как правило очень разные по частоте обращения к ним. К некоторым данным, и их может быть достаточно много, обращений вообще не бывает, это фактически архивные данные. Такая БД у нашего клиента, например. И зачем всю такую БД держать в памяти? Не лучше ли иметь мощный ввод-вывод?

[zVlad]

Не совсем в тему.... Но XBox отказался от айбиэмовской PowerPC архитектуры и следующий XBox будет x86-64.

Я бы даже сказал - совсем не в тему.

[iDesperado]

Ничего подобного я не предлагал. В моем пример DR количество ЦПУ остается не изменным в случае DR, мощность увеличивается на том же количестве ЦПУ.

вы снова за старое
вы же поняли о чем я говорю, к чему этот спектакль ?
что бы была возможность увеличить мощность, нужно иметь модель МФ, в которой будет установлено 5 процессоров на первую задачу и 3 процессора на вторую. т.е. более дорогая модель в расчете на один MIPS мощности, чем z114.

[zVlad]

.....в продолжение к этому тесту я нашел еще один
http://www.oracle.com/us/solutions/benc ... 166414.pdf
http://www.oracle.com/us/solutions/benc ... 166419.pdf

тут запустили совсем идентичный batch тест. на обоих машинах запускали Large model, на обоих Large model с 14 потоков. т.е. условия тестирования были идентичны. писюк обрабатывал 298,507 строк в минуту, МФ с тем же кол-вом процессоров лишь 113,207 в минуту.

8-ми процессорный RISC сервер никак не писюк, не надо утрировать.
Вы наверное думаете что раз оба сервера имеют по 8 CPU то это значит что тестируется нечто одинаковое.
На самом деле:

- в моделе 116 CPU "зажаты". MIPS-ы этой модели примерно равны MIPS-ам незажатого МФ с 12 CPU. Речь идет естественно о z900. В отчете говорится о 1612 MIPS для 8 CPU LPAR. Арифметика говорит что все 16 ЦПУ должны бы дать 3200 MIPS, но из других источников (нескольких разных) следует что модел 116 имеет 2700 MIPS, 3200 MIPS имеет модел 216. Таким образом получается что в тесте использовались 6 ЦПУ на максимольной их скорости, а не 8.

- в тесте на LARGE моделе МФ был загружен всего на 60%. RISC server na 90%. Следовательно мы сравниваем результат работы 3.6 CPU MF c 7.2 CPU RISC server (если конечно РИСЦ сервер мог бы быть нагружен на 100%, МФ точно мог бы).

- память у RISC servera - 32 GB, y MF - 10 GB или в три раза меньше.

- отчет не говорит какие и сколько каналов ввода-вывода использовалось на МФ.А с этим связано несколько возможностей дающих разную производительность. У нас были такие диски о которых говорит отчет и онии были подключены через ESCON и не использовались на продакш, а только на тестовой системе. Shark была неудачной дисковой подсистемой.

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

[zVlad]

Ничего подобного я не предлагал. В моем пример DR количество ЦПУ остается не изменным в случае DR, мощность увеличивается на том же количестве ЦПУ.

вы снова за старое
вы же поняли о чем я говорю, к чему этот спектакль ?
что бы была возможность увеличить мощность, нужно иметь модель МФ, в которой будет установлено 5 процессоров на первую задачу и 3 процессора на вторую. т.е. более дорогая модель в расчете на один MIPS мощности, чем z114.

Это не я а Вы спектакль тут разыгриваете. Я уже говорил, но видимо придется еще раз повторить - не нужны 3 процессора для второго МФ на первом. Теже 5 CPU (model Q05 992 MIPS) конвертированные в модел Z05 (найдите сами сколько это будет MIPS, я так полагаю будет больше 2000) прекрасно осправятся с сумарной нагрузкой. Более того приложение с первого МФ прекрасно ложится на три процессора второго конвертированного из A03 (76 MIPS) в Z03 (1500 MIPS). Обе машины у нас - одна z114, вторая z10 BC.

Так кто здесь спектакли разыгривает?

[zVlad]

.....в продолжение к этому тесту я нашел еще один
http://www.oracle.com/us/solutions/benc ... 166414.pdf
http://www.oracle.com/us/solutions/benc ... 166419.pdf

тут запустили совсем идентичный batch тест. на обоих машинах запускали Large model, на обоих Large model с 14 потоков. т.е. условия тестирования были идентичны. писюк обрабатывал 298,507 строк в минуту, МФ с тем же кол-вом процессоров лишь 113,207 в минуту.

В дополнении к сказанному выше меня очень смущает и настораживает вот это из списка используемого софта для МФ:
- Merant Server Express (COBOL) 2.0

Я не знаю что это за зверь, но похоже этот зверь юнисксовского происхождения и ничего хорошeго для производительности я от этого не ожидал бы.
Для z/OS есть нормальный COBOL от ИБМ и именно он должен использоваться с z/OS в тестах производительности. Я знаю что ИБМ-ский кoмпилятор затачивается на архитектуру MF. Заточен ли Mertant nobody knows.

[iDesperado]

8-ми процессорный RISC сервер никак не писюк, не надо утрировать.

да, наверно воркстейшен правильней называть. я не утрирую, просто нужен термин на unix/linux/windows платформы.

Вы наверное думаете что раз оба сервера имеют по 8 CPU то это значит что тестируется нечто одинаковое.

нет, я так не думаю, потому как знаю, что там разные архитектуры.
суть в том, что мы имеем бенчмарк, сделанный профессионалами, с привлечением спецов IBM c одной стороны и басню с другой:

Сегодня говорил с колегами по команде которые работают на другого клиента - крупная фирма по распределению электоэнергии. Клиент этот переводит приложение с МФ на Юникс/Оракл. МФ был двухпроцессорным z9 N02 s 214 MIPS-ами под production i z9 A01 s 26 MIPS-ами под ДР и development.
Спрашиваю на какие сервера переходят. Отвечают, не знаем, нам не говорят, но проект дилжен был закончится в октябре 2012 и по ходу тестирования выяснелось что начальные параметры серверов были занижены и пришлось их докупать. Было сказано что вместо 110 активных юсеров на тех серверах могли потынуть только 10. Предположение теам леад-а который хорошо знает клиента это 6-8 многопроцессорных AIX серверов

видите какая несостыковочка выходит. когда тестирует IBM, у них МФ 1612 MIPS не очень то здорово смотрится на фоне UNIX. а вы нам рассказываете, что замена на порядок менее мощного МФ z9 N02 s 214 MIPS потребовала табун UNIX серверов, каждый из которых в 2012 году в сотни раз мощнее того сервера 8xPA-RISC, что использовался в тесте peoplesoft.