IBM PC

[Alexander Troyansky]

Response time: MF - 0.373 sec Power - 1.89 sec (У Мф результат лучше в почти 20 раз).

?

[mskmel]

Объясните, зачем так низко опускаться? Вы даже не смогли выбрать главное из двух предположений, а привели их оба хотя они разные. Вы даже сказали "возможно". Так что ж там по Вашему было на самом деле то? Старая storage или маленькая, по размеру, БД? Вы уж определитесь как нибудь.

Старый storage и маленькая, по размеру, БД. Маленькая - потому что старый медленный сторидж. Маленькая - потому что для тестирования эффективности работы новой версии БД надо убрать из расчётов старый сторидж, сгладить негативное влияние которого новая версия БД не может.

DB Response Time = IO Time + CPU Time. Если уменьшаем размер БД - уменьшаем IO Time, и получаем красивое DB Response Time. Ну ведь согласитесь смешно, 26ГБ размер БД для 19к пользователей У вас всего 2000 юзеров и "терабайты".

Основной показатель неэффективности МФ для приложений, способных работать на современном софте\железе - отсутствие публичных тестов МФ. Маркетологи бы такого шанса не упустили! IBM не стыдится публиковать тесты своих p-Series, но при этом скрывает те же самые тесты для z-Series, что не мешает заявлять маректологам о революции с z13 и "впаривать" десяток ядер и несколько гигов памяти за миллион долларов.

Железо, не только х86, но и Sparc\Power существенно подешевело за последние годы. Я помню закупки IBM p69Х\Sun Fire E1Хk\E2Хk\Fujitsu 2500 за миллионы долларов, сейчас же машинки с похожими характеристиками стоят примерно на порядок меньше, и видимо только МФ остались в том же ценовом диапозоне что и 10 лет назад.

[zVlad]

Response time: MF - 0.373 sec Power - 1.89 sec (У Мф результат лучше в почти 20 раз).

?

Да лействительно, обсчитался и намного. На самом деле где в 5 раз. Спасибо что обратили внимание.

[zVlad]

Объясните, зачем так низко опускаться? Вы даже не смогли выбрать главное из двух предположений, а привели их оба хотя они разные. Вы даже сказали "возможно". Так что ж там по Вашему было на самом деле то? Старая storage или маленькая, по размеру, БД? Вы уж определитесь как нибудь.

х

Старый storage и маленькая, по размеру, БД. Маленькая - потому что старый медленный сторидж. Маленькая - потому что для тестирования эффективности работы новой версии БД надо убрать из расчётов старый сторидж, сгладить негативное влияние которого новая версия БД не может.

DB Response Time = IO Time + CPU Time. Если уменьшаем размер БД - уменьшаем IO Time, и получаем красивое DB Response Time. Ну ведь согласитесь смешно, 26ГБ размер БД для 19к пользователей У вас всего 2000 юзеров и "терабайты".

Основной показатель неэффективности МФ для приложений, способных работать на современном софте\железе - отсутствие публичных тестов МФ. Маркетологи бы такого шанса не упустили! IBM не стыдится публиковать тесты своих p-Series, но при этом скрывает те же самые тесты для z-Series, что не мешает заявлять маректологам о революции с z13 и "впаривать" десяток ядер и несколько гигов памяти за миллион долларов.

Железо, не только х86, но и Sparc\Power существенно подешевело за последние годы. Я помню закупки IBM p69Х\Sun Fire E1Хk\E2Хk\Fujitsu 2500 за миллионы долларов, сейчас же машинки с похожими характеристиками стоят примерно на порядок меньше, и видимо только МФ остались в том же ценовом диапозоне что и 10 лет назад.

Вас все время волнуют только цены. Чтобы говорить о ценах нужно сначала понять предмет покупки. Вы когда покупаете себе авто Вы ведь не спрашиваете сколько у него двигателей или колес и не сетуете что колес не десять а всего четыре, а двигатель не 1000 лошадинных сил а всего, например, сто. Вам важно сможет ли авто выполнить то ради чего Вы его покупаете.

Теперь попорядку с начала. Вы не заметили я там слова написал такое: "индексы". Так наличие индексов, которые конечно тоже могут быть больше или меньше в зависимости от количества индексированных данных, снижает причем существенно количество операций ввода-вывода. Ваша формула времени выполнения запроса упрощена, но в общем верна. Согласно этой Вашей формуле, моих добавлений про индексы и замечаний в описании теста про устаревшую память можно сделать вывод что МФ мог бы показать и лучше результат с новой памятью. Но в тексте говорится также "The SD workload has munimal database I/O so using older DASD (Вы этого сокращения можетe не знать, но наверняка догадались что это диски: Direct Access Storage Device) ia adeguate for the I/O load". Но ясно что поразить высокой производительностью автора теста никого не собирались.

Я тут обшибся в математике и Вы тоже: посмотрите еще раз там не 26 GB, a как минимум 1 TB под базу было занято.

Еще одна поправка для точности. Вы написали что у меня 2000 пользователей. Да я называл такое число, но как количество добавленных недавно пользователей переведенных из SAP (т.е. с Юникса с Ораклом и соответственно нескольких серверов) на МФ при этом МФ остался тем же хотя на нем уже порядка 10000 пользователей было зарегистрированно.

ИБМ много лет назад объяснили технически почему они не участвуют с МФ в тестах для сервером другой природы. ИБМ тем не менее производит другие сервера и участвует с ними в тестах адекватных для них. Если коротко то признаные тесты для обычных серверов неадекватны МФ. Я тут не раз писал что на месте ИБМ поработал бы над тестом в котором, например, на одном МФ одновременно выполняется несколько тестов типа TPC-C (кстати тесты TPC изначально были придуманы в ИБМ давным давно, еще в 70-е, не все но некоторые) в нескольких LPAR. Или еще был бы интересен тест на базе SAP с двухуровневым исполнением, т.е. не только БД на испытуемом сервере, но и аппликэйшн сервера тоже на МФ. Именно такая схема у нас да и у многих других с МФ используется. Но тогда Вы бы сказали что мол так не честно, что вы разделяете все по многим серверам иначе работать вообще не будет. А на Мф будет да еще как будет. Будет и в варианте все под одним zOS и в варианте все аппсервера на виртуальных машинах в одном LPAR под zVM и Линукс, а БД DB2 в другом под zOS, и когда все под Линуксом - в LPAR-х или на виртуальных машинах по zVM. Так работает правительство Канады между прочим.
На не МФ такие возможности есть, но они используются очень ограниченно и тестов в таких конфигурациях я что то не видел. Покажите мне такие тесты на Power или на Intel и тогда можно будет говорить о тестах с МФ (это я как бы от стороны ИБМ говорю, хотя если бы у меня были ресурсы, работай я в ИБМ где-нибудь в вашингтонском их центре, то обязательно бы замутил такой тест и посрамил бы кого-нибудь, или говорил бы тогда, через губу, мол запихните все что я запихнул на МФ на один ваш сервер и покажите хотя бы что он работает).

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

Кроме того ИБМ имеет специальные цены для тех у кого нет workload для zOS для тех кто желает все выполнять под Линукс. Цены на процессора МФ тогда в разы меньше. Это уже не миллионы долларов, а десятки тысяч, начиная с.

Сам тест о котором мы копья ломаем сделан для тех пользователей которые используют МФ как сервер БД для SAP. Значит такие пользователи у ИБМ есть, верно? Причем заметьте использование DB2 на zOS так как это делает SAP это не самый эффективный способ использования. Но ИБМ постоянно что-нибудь подкручивает для SAP в DB2 и делает ее более привлекательной.

[mskmel]

Вас все время волнуют только цены. Чтобы говорить о ценах нужно сначала понять предмет покупки. Вы когда покупаете себе авто Вы ведь не спрашиваете сколько у него двигателей или колес и не сетуете что колес не десять а всего четыре, а двигатель не 1000 лошадинных сил а всего, например, сто. Вам важно сможет ли авто выполнить то ради чего Вы его покупаете.

Мощность двигателя и кол-во колес как раз и определяют что машина может сделать = сколько сможет везти\тянуть. Вобщем-то мне вполне уже понятно, 20к юзеров на железке стоимостью в миллион... При этом на МФ была только БД, серверы приложений на более традиционном железе запустили.

Плюс, как я смотрю память в МФ не ставят или стоит безумно дорого, что уменьшает кэширование = увеличивает требования к системе хранения = еще увеличивает стоимость железа.
Сервера приложений держать, которые кэшировуют десятки\сотни ГБ данных из БД тоже выйдет дорого.

Я тут обшибся в математике и Вы тоже: посмотрите еще раз там не 26 GB, a как минимум 1 TB под базу было занято.

Может быть не там прочитал...

Unless stated otherwise, all measurements were done with 26 GB of storage configured on the SAP
Database Server.

Или еще был бы интересен тест на базе SAP с двухуровневым исполнением, т.е. не только БД на испытуемом сервере, но и аппликэйшн сервера тоже на МФ.

У 2 tier нет серверов приложений, на то он и 2 tier

Но тогда Вы бы сказали что мол так не честно, что вы разделяете все по многим серверам иначе работать вообще не будет. А на Мф будет да еще как будет.

Уже 10+ лет как есть домены\Zones, nPar\vPar, LPAR, их используют и при этом очень всё работает. На IBM p-Series, без LPAR вообще нельзя.

Покажите мне такие тесты на Power или на Intel и тогда можно будет говорить о тестах с МФ

Не совсем Intel\Power, но

Oracle's SPARC M6-32 server, equipped with 32 3.6 GHz SPARC M6 processors and running Oracle Database 11g Release 2 on Oracle Solaris 11, set world records on Oracle's PeopleSoft Human Capital Management (HCM) 9.1 benchmark, PeopleSoft 9.1 Payroll (North America) benchmark, and Oracle E-Business Suite R12.1.3 Standard Extra-Large benchmark.. The SPARC M6-32 server is the first server to achieve this level of performance while running these three separate benchmarks simultaneously on a single system.

Кроме того ИБМ имеет специальные цены для тех у кого нет workload для zOS для тех кто желает все выполнять под Линукс.

Так они еще и будут указывать что на нём выполнять?!

Сам тест о котором мы копья ломаем сделан для тех пользователей которые используют МФ как сервер БД для SAP. Значит такие пользователи у ИБМ есть, верно?

Не у всех есть бюджет смигрировать SAP на новую платформу, такая миграция скорее всего дороже нового МФ. Не у всех достаточно силы воли и экспертизы ввязаться в миграцию (ведь можно же и обломаться!), проще ничего не менять и использовать МФ. Вот и продолжают платить IBM...

Лет 10 назад скептически говорили о миграции с больших Unix на Linux, сейчас же бегут аж пятки сверкают. Да, не всё так просто и хорошо, но однажды попробовав платить за железку вместо миллионов всего стотыщ, баблодающие мозг выклюют, но переехать заставят, чтобы через 3-5 лет платить не опять миллион, а всего 100тыщ. Я не говорю что мне это нравится, x86\Linux до взрослых машин по reliability, availability and serviceability еще очень далеко, но они просят меньше овса (дешевле) и везут не меньше дров.

Еще лет несколько, и IBM задолбается вливать деньги в МФ и выпустит эмулятор под x86\Power и будет весь МФ софт крутиться в LPAR. Не вливать деньги они не могут, госконторы и военные быстро голову открутят. VAX этот путь уже проделал.

[flip_flop]

Я не говорю что мне это нравится, x86\Linux до взрослых машин по reliability, availability and serviceability еще очень далеко, но они просят меньше овса (дешевле) и везут не меньше дров.

Не совсем согласен я. RAS в каждой новой версии Xeon E5 и, особенно, Xeon E7 добавляет новые возможности, в том числе для 24/7 nonstop и mission critical applications.

[mskmel]

Я не говорю что мне это нравится, x86\Linux до взрослых машин по reliability, availability and serviceability еще очень далеко, но они просят меньше овса (дешевле) и везут не меньше дров.

Не совсем согласен я. RAS в каждой новой версии Xeon E5 и, особенно, Xeon E7 добавляет новые возможности, в том числе для 24/7 nonstop и mission critical applications.

Процессор это еще не весь сервер

[zVlad]

Вас все время волнуют только цены. Чтобы говорить о ценах нужно сначала понять предмет покупки. Вы когда покупаете себе авто Вы ведь не спрашиваете сколько у него двигателей или колес и не сетуете что колес не десять а всего четыре, а двигатель не 1000 лошадинных сил а всего, например, сто. Вам важно сможет ли авто выполнить то ради чего Вы его покупаете.

Мощность двигателя и кол-во колес как раз и определяют что машина может сделать = сколько сможет везти\тянуть. Вобщем-то мне вполне уже понятно, 20к юзеров на железке стоимостью в миллион... При этом на МФ была только БД, серверы приложений на более традиционном железе запустили.

Плюс, как я смотрю память в МФ не ставят или стоит безумно дорого, что уменьшает кэширование = увеличивает требования к системе хранения = еще увеличивает стоимость железа.
Сервера приложений держать, которые кэшировуют десятки\сотни ГБ данных из БД тоже выйдет дорого.

Я тут обшибся в математике и Вы тоже: посмотрите еще раз там не 26 ГБ, а как минимум 1 ТБ под базу было занято.

Может быть не там прочитал...

Unless stated otherwise, all measurements were done with 26 GB of storage configured on the SAP
Database Server.

...

Это верно что "Мощность двигателя и кол-во колес как раз и определяют что машина может сделать = сколько сможет везти\тянуть.". Я призываю нас не забывать об этом в наших спорах. Но согласитесь что ездить в офис на траке конечно можно но это глупо. Гораздо мудрее купить школьный автобус или лухары, доубле деск, бус и возить весь люд в Вашем офисе. Это будет в целом гораздо дешевле чем каждому ездить на своей машике, на своем Мерседес, Acura, Инфинитi, или даже Cruze, Аccord, Carola. Колес в случае бус-а будет больше, но людей bus привезет в офис больше, на меньшем количестве колес, сумарной мощности двигателя, расходов на смену масла чем все машинки которые привозят тоже самое количество людей в тот же офис, и driver будет всего один, а не столько сколько людей в офисе. Вот этот bus и есть МФ, он дороже десятков машинок, но он економичней и т.д. Вы уже все поняли. И чем больше офис тем bus(МФ) будет экономичней.

"При этом на МФ была только БД, серверы приложений на более традиционном железе запустили. " Я Вам уже намекал, но Вы не обратили внимания на то что, во-первых, МФ с 14 CPU (General Purpose CPU, т.е. для zOS) будет стоить больше миллиона, но конечная цена за все: железо и софт будет определяться не количеством ЦПУ, а количеством MIPS, которых при одном и том же количестве ЦПУ может быть 26 уровней, от некоего минимального до некоего максимального.

Вы не "не там", а не про то прочитали. Storage это не диски, диски это DASD. 26 GB это если хотите memory, CPU memory. Так уж получилось что терминология несколько иная у ИБМ и других (все другие на самом деле появились позже (а те что появились вместе с IBM уже ушли), поэтому мoгли бы и учесть ИБМ терминологию, но это уже другая тема).

[zVlad]

....

Или еще был бы интересен тест на базе SAP с двухуровневым исполнением, т.е. не только БД на испытуемом сервере, но и аппликэйшн сервера тоже на МФ.

У 2 tier нет серверов приложений, на то он и 2 tier

Но тогда Вы бы сказали что мол так не честно, что вы разделяете все по многим серверам иначе работать вообще не будет. А на Мф будет да еще как будет.

Уже 10+ лет как есть домены\Zones, nPar\vPar, LPAR, их используют и при этом очень всё работает. На IBM p-Series, без LPAR вообще нельзя.

Покажите мне такие тесты на Power или на Intel и тогда можно будет говорить о тестах с МФ

Не совсем Intel\Power, но

Oracle's SPARC M6-32 server, equipped with 32 3.6 GHz SPARC M6 processors and running Oracle Database 11g Release 2 on Oracle Solaris 11, set world records on Oracle's PeopleSoft Human Capital Management (HCM) 9.1 benchmark, PeopleSoft 9.1 Payroll (North America) benchmark, and Oracle E-Business Suite R12.1.3 Standard Extra-Large benchmark.. The SPARC M6-32 server is the first server to achieve this level of performance while running these three separate benchmarks simultaneously on a single system.

Кроме того ИБМ имеет специальные цены для тех у кого нет workload для zOS для тех кто желает все выполнять под Линукс.

Так они еще и будут указывать что на нём выполнять?!

Сам тест о котором мы копья ломаем сделан для тех пользователей которые используют МФ как сервер БД для SAP. Значит такие пользователи у ИБМ есть, верно?

Не у всех есть бюджет смигрировать SAP на новую платформу, такая миграция скорее всего дороже нового МФ. Не у всех достаточно силы воли и экспертизы ввязаться в миграцию (ведь можно же и обломаться!), проще ничего не менять и использовать МФ. Вот и продолжают платить IBM...

Лет 10 назад скептически говорили о миграции с больших Unix на Linux, сейчас же бегут аж пятки сверкают. Да, не всё так просто и хорошо, но однажды попробовав платить за железку вместо миллионов всего стотыщ, баблодающие мозг выклюют, но переехать заставят, чтобы через 3-5 лет платить не опять миллион, а всего 100тыщ. Я не говорю что мне это нравится, x86\Linux до взрослых машин по reliability, availability and serviceability еще очень далеко, но они просят меньше овса (дешевле) и везут не меньше дров.

Еще лет несколько, и IBM задолбается вливать деньги в МФ и выпустит эмулятор под x86\Power и будет весь МФ софт крутиться в LPAR. Не вливать деньги они не могут, госконторы и военные быстро голову открутят. VAX этот путь уже проделал.

Tiers можно рассматривать как на логическоm так и на физическом уровне. Вы, на распределенных системах, видите это как физическое деление на уровни: DB, АS, client. Вот Вы привели пример с People Soft и выделили жирным "single system". А мне даже без ссылки на источник понятно что Оracle database которая была на "single system" это еще не все что надо клиенту, там еще должeн быть Application Server как таковой либо он размазан по "жирным" клиентам что уже не делается давно по известным причинам. Верно?

Так что "single system" выполняет только database, а я говорю о том что AS(WebSphere) и DB (DB2 fo zOS) в случае МФ могут и должы быть на одном МФ (или в одном Sysplex-e). И это будет самым дешевым вариантом в смысле ТCО, и самым лучшим в смысле RAS. Единственный негативный ефект в этом случае будет тоо что нашего брата IT-шника будет надо меньше чем в случае распределенных систем (Вы все время, кстати, забываете что в цену IT входят и зарплаты наши, а они не маленькие нынче и платятся каждый месяц, даже каждые полмесяца, а мне платят каждую неделю).

Почему IBM в тесте показал 3 tiers? Потому что такова распространенная практика пользователей SAP. Сам же ИБМ рекомендует 2 tiers, t.e. DB и AS в одной системе и называет это co-location. Иначе говоря тест мог бы состояться и без вспомогательных серверов, но это было бы не интересно, пока, пользователям SAP. A пользователи SAP слушают SAP больше чем IBM. Тоже самое в нашей конторе происходит, увы, но только пока количество юзеров не такое уж большое. Вот переведут всех на Java тогда посмотрим сколько им понадобится вспомогательных серверов и сколько это будет стоить. Цена, кстати, уважаемый москвич из Мельбурна, давно уже не фактор, особенно когда IT аутсорсается. Наоборот, чем дороже тем лучше. Визку конечно омного о необходимости сокращать расходы, но всерьез пока этим не занимаются. В основном пытаются выхеривать MF, что цену IT в целом только увеличивает, и людей, IT-шников.

LPAR говорите уже десять лет как используются. На МФ LPAR-у больше 20-ти лет. LPAR на МФ функционально сильно отличается от LPAR даже на Power, хотя это тоже IBM, и по практике использования тоже отличается. Если Вы работаете с Power то знаете HMC. HMC это тоже MF-ская штучка и на MF HMC, внешне очень похожий с Power потому что HMC было взято с МФ для Power, существенно иной.

Миграция с Unix на Linux совершенно понятна и скоро приведет к тому что Unix-ов не станет, а вместе сними не станет SPARC-ов и Power-ов. Останутся x86 и MF. IBM получает прибыль от МФ и видит их перспективу. Так что забудьте об эмуляторах МФ на x86/Power. Это уже было в 90-е и полностью отсутствует сегодня. SUN пытался эмулировать CICS - провал. Происходит другое движение: то что хорошо работает на x86/Power хорошо и достаточноо экономно работает на МФ. Не все это понимают, но это временно, это можноо изменить. Все серьезные серверные технологии и средства имеются на МФ тоже. Linux, а значит и все что может бежать под ним. Это как минимум. Java тоже помогает миграции. Одно и тоже приложение можно деплоить в WebSphere на любой платформе: Window, Linux, Unix, и zOS.