Здесь http://www.zdnet.ru/?ID=302013

>Тем не менее он, например, показывает, что Виндовс сервер и SQL масштабируется на 64 процесссора и 512 Gb памяти. А вот про линукс молчит тест :)

Ну и что это доказывает ?

Что вин как серверная платформа лучше лялиха ?

Проект COSMOS

SGI Linux64 работает на 128 Itan.2 с 6 Тb дисковой

подсистемой.

"А любой тест позволяет только прикинуть :)"

Только с разной степенью достоверности...

"Ну положим не все. Повторюсь ТРС-С - универсальный тест. Он позволяет прикинуть производительность самых разных платформ. Если вы знаете его особенности, а также хорошо представляете то приложение, которое собираетесь внедрять, то можно сделать кое-какие выводы. "

Всегда приятно общаться с оптимистами. Вот только если узнать особенности, так тогда сразу и становится понятно, что какие-то полезные выводы из этого теста не сделать. В лучшем случае можно понять (оценив тест для новой модели техники той же архитектуры, что у вас есть), во сколько примерно новая модель быстрее старой (и то с оговорками, так как новое - не пропорционально ускоренное старое). Сравнивать же разные архитектуры этим тестом еще более проблематично (несмотря на всю рекламу). Поскольку разные архитектуры принципиально дают слишком разные возможности по накручиванию конкретно взятого теста. Напомню еще раз про пример с TPF, о котором написано на сайте TPC. К тому же набор типовых транзакций согласно TPC-C имеет крайне малый шанс быть похожим на настоящие транзакции, на чем бы они не выполнялись.

"ИБМ осознает все комичность данного теста для серьезных систем, и поэтому прогоняет эти тесты только для своих игрушечных линеек" 32-процессорный IBM eServer pSeries 690 для вас из игрушечной линейки ??? Я пас :)"

А вы почитайте доку про 990-й zSeries (или даже про младшие модели), и про сисплексы из них, и сравните. И, к слову, число центральных процессоров тут далеко не главное. Почему все в этом треде так и талдычат о процессорах? :) Мы, кажется, не уравнения тут решаем.

"Пилотные внедрения очень полезны, никто не спорит. Но они уж очень дороги и сложны. Перед ними неплохо бы по некой общей шкале прикинуть производительность и масштабируемость разных линеек железа и прогр. обеспечения."

Такая шкала есть. Нормальные менеджеры должны уметь искать инфу о происшедших в реальной жизни миграциях, а не основываться в своих решениях как на подобных тестах. Умение пользоваться такой шкалой (а не общедоступными циферками и статейками) и есть показатель класса менеджера.

"Ну все, купили мейнфрейм и сто лет будут сидеть на мейнфрейме и приложения на Коболе писать. Что хорошего в том, что сложно перейти с одной платформы на другую ?"

А что плохого в том, чтобы сидеть на мэйнфрейме? Сложность же перехода, несомненно, полезна - она осаживает не в меру ретивых пионеров, для которых важно иметь не работающую, а самую модную систему. =)

"Не надо все сводить к мейнфреймам :) Ладно, сойдемся на том, что для мейнфреймов тест ТРС-С плохой."

А я и не свожу. Просто TPC-C плох для любых мощных серверов (если мы ставим задачей не цифирь получать, а действительно тестировать).

"Частично согласен, но поскольку все участники в равных условиях, СРАВНИВАТЬ разные результаты вполне корректно. "

Да, но какие ж тут равные условия? :) Нету их. Это как в ралли "Париж-Дакар" - что не запрещено, то разрешено. Вот только из того, что первыми приходят всегда до предела накрученные Камазы, никак не следует, что именно серийно доступный Камаз - оптимальный грузовик для дальнобойщиков. Так и здесь. =) И даже если бы условия были действительно равными: слишком уж непохож ТПЦшный ворклоад на реальные. Поэтому результаты такого теста все равно не более чем условны.

"Ну а какой тест может нагрузку кучи разных приложений на одном железе ? Если говорите, что что-то плохо, предлагайте что-нибудь получше."

Моя ссылка дает вполне исчерпывающий ответ на этот вопрос.

"Ну ораклового друга между прочим 50 серверов, а не один мейнфрейм :) Почему вы уверены, что часть задач не может выполняться на MS SQL, он кстати дешевле ? Только из-за религиозного windows must-die ?"

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

>>Почему вы уверены, что часть задач не может выполняться на MS SQL, он >>кстати дешевле ? Интересно почему я уверен что если сервак рухнет мы все попадем на бабки ?! :)))

2 anonymous (*) (2003-06-09 17:05:52.155112)

В принципе все, что вы сказали можно на любой тест производительности перенести и опустить его по самое нехочу :) Ибо все тесты, даже почти все пилотные внедрения, только некая модель реальности :)

Я не совсем понимаю фразу "Просто TPC-C плох для любых мощных серверов (если мы ставим задачей не цифирь получать, а действительно тестировать)." А что есть тестирование производительности, как не получение цифирь ?

"Моя ссылка дает вполне исчерпывающий ответ на этот вопрос"

Вот эта ? http://www-ti.informatik.uni-tuebingen.de/os390/os390/perform/perform4.pdf Ничего исчерпывающего я там не наблюдаю. Система тестирования S/390 причем там же написано, что IBM использует это As an interim solution.

"Такая шкала есть. Нормальные менеджеры должны уметь искать инфу о происшедших в реальной жизни миграциях, а не основываться в своих решениях как на подобных тестах. Умение пользоваться такой шкалой (а не общедоступными циферками и статейками) и есть показатель класса менеджера."

Не совсем понимаю, что имелось в виду. На сайтах Microsoft, Orаcle, IBM куча таких успешных миграций, одна успешней другой и ни одного провала :) Информация об миграциях, конечно, полезна, но как исходя из нее оценить именно производительность ? Может я не лучший менеджер :), подскажите пути оценки производительности моего OLTP приложения на, скажем, 5000 пользователей исходя из каких-то результатов миграций.

2 Sun-ch "Ну и что это доказывает ? Что вин как серверная платформа лучше лялиха ? "

Ну не так однозначно, но масштабируется лучше.

"Проект COSMOS SGI Linux64 работает на 128 Itan.2 с 6 Тb дисковой подсистемой."

Ну и как будем оценивать производительность этого решения ? 1,500,000 транзакций в минуту у HP Superdome под Виндами - это реальность, а ваше утверждении, типа SGI Linux64 всех порвет по производительности - это сотрясение воздуха.

Распаралеливание

Я конечно недостаточно разбираюсь в многопроцессорных системах чтобы соперничать с местными экспертами ,но насколько я знаю каждая задача имеет свою сложность распаралеливания ,как для для алгоритмов .Например задача численного интегрирования имеет сложность O(n^0), тобеш линейный рост производительности от числа процессоров .

Ну не так однозначно, но масштабируется лучше.

Откуда это следует ???

Я уже писал, что SGI лялих масштабируется на несколько сот CPU

и террабайты ОЗУ

>>Почему вы уверены, что часть задач не может выполняться на MS SQL, он >>кстати дешевле ?

На сайте www.oracle.com можно закачать Oracle бесплатно, знаю админа, который бухгалтерию на Linux+Oracle с WEB-интерфейсом 2 года уже гоняет (в г.Самара).

2 Sun-ch "Ну не так однозначно, но масштабируется лучше. Откуда это следует ??? Я уже писал, что SGI лялих масштабируется на несколько сот CPU и террабайты ОЗУ"

Масштабируемость - это не количество процессоров, а производительность на полезной нагрузке. Где результаты замеров производительности ? Не обязательно ТРС-С, хоть какие-то. На какой-нибудь более-менее реальной задаче: СУБД, Вэб-сервер...Если есть объективные сравнения, показывающие преимущества Линукс, извинюсь без проблем. Кстати, сколько это дело стоит, если оно вообще продается ? Оракл на нем пойдет ? C поддержкой естественно

"На сайте www.oracle.com можно закачать Oracle бесплатно, знаю админа, который бухгалтерию на Linux+Oracle с WEB-интерфейсом 2 года уже гоняет (в г.Самара)."

Ну пиратский SQL сервер тоже можно достать. Я просто не в России, у нас за такие номера натягивают иногда :)

>Кстати, сколько это дело стоит, если оно вообще продается ?

Можно купить 1 узел с 4 процами, а можно 8 узлов, а можно 64

>Оракл на нем пойдет ? C поддержкой естественно

А это проблемы Оракл.

Портируют его на SGI Linux64 и начнут продавать - значит будет работать.

2 Sun-ch Никаких сравнений производительности я стало быть не дождусь. Ну и ладно...

"А это проблемы Оракл. Портируют его на SGI Linux64 и начнут продавать - значит будет работать"

Т.е. нет. А что вообще на нем идет ? Зачем нужна 128-проц. железяка, кроме как для сервера СУБД ? Все остальное легко разбить на меньшие задачи и распределять нагрузки по меньшим серверам.

"Т.е. нет. А что вообще на нем идет ? Зачем нужна 128-проц. железяка, кроме как для сервера СУБД ? Все остальное легко разбить на меньшие задачи и распределять нагрузки по меньшим серверам."

Абаржацца. =)

Где, еще, кроме ЛОРа, можно процесть такой бред? Если только на форуме компьютерры, да и то не каждый день. =)

2 anonymous (*) (2003-06-09 18:32:27.925503) А вы предлагаете 128-процовую железку в качестве файлопомойки использовать ?

>Все остальное легко разбить на меньшие задачи и распределять нагрузки по меньшим серверам.

И какая при этом нужна производительность сети ?

На SGI гарантируют доступ к любому узлу кластера за 50 наносекунд.

В проекте COSMOS

размер хранилища 6 Тб (данные о космологических исследованиях),

возможно, что там тоже используется СУБД.

"А вы предлагаете 128-процовую железку в качестве файлопомойки использовать ? "

Я всего лишь предлагаю форуму прекратить бредить о числе процессоров и наконец осознать, о чем тред и что именно меряется.

И вообще, надо читать не желтую прессу, а нормальные новостные сайты.

Например, вот:

http://www.esj.com/News/article.asp?EditorialsID=550

И вот:

http://www.esj.com/News/article.asp?EditorialsID=544

Сколько раз не сравнивал icc 7.1 c vcc 7.1 везде vcc генерил лучший код.

"Сколько раз не сравнивал icc 7.1 c vcc 7.1 везде vcc генерил лучший код."

Ох уж эти сказочки, ох уж эти сказочники...

Это не сказки %)

из первых пришедших на ум косяков: icc упорно продолжает рефрешить регистр с адресом несмотря на restrict qualifier указателя .. про jc он тоже не знает и заменяет его двумя jmp ами подряд ну и т.д. я уже задолбался отсылать косяки интелу - хоть бы лицензию подарили что ли ... %)

Дмитрий С.

Ну блин ехпертов набролось ж) .....
Ну и у меня несколько поинтов.
Интелу пофигу на чем Linux иль winoze будет ранаться их железо, главное, чтоб не UltraSparc. По сему, тк Линукс hot для замены UNIX, то и тест на линуксе провели, хотя здается мне, что под виндусом результаты были бы крайне слабенькие. Твиканье OS/DB давольно важно не только для тестов, но и в реальной жизни, а виндус особо не твикнешь. Для примера, подобного твикания, где в некоторлх случаях performance влзрастает up to 1000%, рекомендую посмотреть:
http://www.linuxjournal.com/article.php?sid=5840
http://www.linuxjournal.com/article.php?sid=5841
Продолжаем разговор, все, пожалуй кроме Sun и в какойто степени IBM, стратегически с мелкософтом повязанны, по сему Linux vs. Windowz сравнение они делать не будут, а будут говорить: "A если нужно , то вот у нас виндус есть, бииистрий такой, а, что не хотите, ну тогда во глядите и линукс у на бииистрый", у IBM свой интерес и платформа стратегическая, ну а у Sun подавно.
Ну а для меня сейчас очевидно, что сегодняшний Sun V880 сервак DB, который у нас в проекте исполтзуеться, будет рано или поздно заменен на intel/Linux и даст это примерно вдое большую производителтность, чем intel/windoze, при условии, что DBA/SA будут с головой :)
Ну и последнее, виндус эксперты по HPC вы хоть сами акромя простой PC c виндус использовали? Лично я очень много жалоб об 4+CPU виндус серверах слышал ..... хотя сам подобное г... к счастию не использую

Вот придурок. Я понимаю, тяжело в это поверить, но самые лучшие результаты (по цене, производительности и отношению цена/производительность) по tpc-c у виндовса, и было так с тех пор как вышел SQL 2000. Если кто хочет оспорить результаты тестов и считает что пупок не развяжется - go ahead, сделайте свой тест на том же железе с люлихом, убедитесь еще раз что пиздеть - не мешки ворочать.

2 gopakita: дурилка ты картонная. Я гоняю win на 2-х, 4-х и 8 процессорных компаках (обычных) и на 2-х и 4-процессорных компаках с hyperthreading (что делает их 4 и 8 соотвественно). Винда прет как танк, а asp.net рвет jsp в лоскуты. Ну про W2K3 и IIS6 с http.sys я вообще молчу. Ждем'с пока кто-нибудь линуксоидам устроит разрыв промежности в особо тяжкой форме.

Точнее те что с хайпертредингом уже HP. Сорри.

Вот все люликсойты такие!!!
Сами виндус ни используют, а ругаюца как на базаре.
А патерпели бы с наше, с огро-ирси-виндусовое и устали бы ругаца!!!

>Я понимаю, тяжело в это поверить,
Огро-ирси-виндусята усе такие. Верить, верить, верить и еще раз, верить... только в тесты...

Ей, лошок - по критерию цена/качество лучшие автомобили - "шаха" и ушастый запор.

Вот только лидерство это исключительно за счет цены. А качество - вот оно:

http://www.silicon.com/news/500011-500001/1/4566.html

:))

Так что засуньте свои игрушечные системы себе в...

...Так что учите Кобол и нормальные операционки, ребятки. Они - рулез. =)

2 anonymous (*) (2003-06-10 17:24:43.751997): Однако ж насдак работает на винде и не жалуется. В игрушки играют наверное там. Лохи несерьезные. То что кто-то что-то сделал там в англии один раз через жопу - не показатель.

2 last anonymous:
Мы в нашей системе используем данные с насдак, а именно тн TRACE данные:
http://www.nasd.com/mkt_sys/trace_info.asp
Ну я скажу там и мудачье сидит, мы были похоже первые кленты, которым этот файл был нужен для автоматической обработки, у них при дизайне даже подобных мыслей не было, они толко инфу на вебе давали, через два месяца ебли с ними, сетапнули ftp, но жизнь особо легкой не стала, у них там на из славной виндус платворме все время каки-ето проблемы, то случайно наш пароль поменяют!, то забудут файл положить! или его обнавить, это не продакшан у них там, а какой то пиздс, нас бы за такие развлечения уже миллион раз бы уволили, так что с виндусом и х#евой работой удивительная корреляция однако .....

Ну и последнее, там выше, какой-то щенок тяфкал про MSSQL, по критерию цена-производительность лучще чем Linux/MySQL не найти, для примера google.com, 10000+ Linux servers c MySQl, а теперь прекинте скока пришлось бы билли отвалить за подрбное.

2anonymous (*) (2003-06-09 18:06:32.339307)

Ты лицензию посмотри - допускается использование Oracle на Linux бесплатно, естественно при этом ограничения есть.

"Ну и последнее, там выше, какой-то щенок тяфкал про MSSQL, по критерию цена-производительность лучще чем Linux/MySQL не найти, для примера google.com, 10000+ Linux servers c MySQl, а теперь прекинте скока пришлось бы билли отвалить за подрбное"

Уважаемый, Google не использует MySQL для хранения индексированной информации. ДЛЯ ЭТОГО РСУБД ВООБЩЕ НЕ ПРИСПОСОБЛЕНА. Там какой-то свой движок написан. И может не будем флейм разводить на тему MySQL vs нормальные корпоративные СУБД, к коим относится MSSQL. Надоело уже...

"Ты лицензию посмотри - допускается использование Oracle на Linux бесплатно, естественно при этом ограничения есть."

Расскажите про это подробнее. Что-то у меня сомнения, что в коммерческой организации можно бесплатно замутить Oracle сервер.

"по критерию цена-производительность лучще чем Linux/MySQL не найти"

И что есть какие-то доказательства этого утверждения, кроме MySQL.com ? Почему нет ни одного результата с потрясающе быстрым MySQL на TPC (C/H/W), на SAP тестах, на PeopleSoft ? А если transactional таблицы использовать он такой же быстрый ?

>Ну и последнее, там выше, какой-то щенок тяфкал про MSSQL, по критерию цена-производительность лучще чем Linux/MySQL не найти, для примера google.com, 10000+ Linux servers c MySQl, а теперь прекинте скока пришлось бы билли отвалить за подрбное.

Справедливости ради отмечу: все-таки MySQL и m$SQL - системы разной функциональности. Ставил бы PostgeSQL...

Относительно цены: если бы стоимость мелкомягких поделок изымали из его зарплаты, он бы совсем иначе запел...

"Относительно цены: если бы стоимость мелкомягких поделок изымали из его зарплаты, он бы совсем иначе запел..."

Ну знаете, если из моей зарплаты вычесть стоимость поделок от Оракла, я бы вообще с голоду подох и еще должен остался бы :)