OOW - Day 3 (UEK R2)
В своем пресс-релизе, посвященном рекорду Oracle указывает, что победил DB2, в то время как Cisco, которая предоставляла серверное оборудование, указывает, что был побежден IBM Flex System -)). Что интересно, так это то, что в обоих тестах использовался один и тот же Intel Xeon (E5-2690, 8 Cores) и одинаковое кол-во памяти (768 Gb).
Cisco использовал Oracle Enterprise Kernel, 11gR2, Violin memory array + SAS array.
IBM использовал Red Hat Linux, DB2, SAS + SSD диски.
Т.е. ни одной похожей буквы, кроме буквы Linux.
Посмотрите на Think Times ниже: я честно говоря не вижу отличий. 7% о которых пишут, и это действительно так, выражается в Maximum Qualified Throughput. Но, повторюсь, по временам отклика - мне кажется одинаково.
Т.е. если вы изо всех сил выбираете, какой вам взять Linux, да на каком железе будет лучше, да еще и не дай бог какую взять БД для своего проекта - вы рискуете промахнуться на 7%. Это совсем немного, принимая во внимание цены, и то, что оптимизацией кода получить ускорение в разы - не проблема. Выбирать по производительности стало бессмысленно, по крайне мере для небольших систем. Еще раз, 7% разницы в максимальной пропускной способности при совершенно разных конфигурациях. Лучше обратить внимание на то, с чем вам удобнее работать, где лучше поддержка, виртуализация и прочее. IBM кстати, очень стала пропагандировать PowerLinux именно из-за виртуализации и консолидации приложений в первую очередь. Набор мелких коробок наверно будет быстрее чем одна большая, в которой собраны все задачки, но потери в управляемости, гибкости, надежности будут несравненно выше.
PS обратите внимание на размещение файлов Oracle: redo на sas, файлы данных на violin memory
Результаты: IBM
Результаты: Oracle/Cisco
Поздравляю команду Oracle/Cisco с отличным результатом!
Полная версия видео с OOW
Сообщения
В тестах TPC-C традиционно побеждают "космолеты" в части подсистемы хранения - ранее высокие показатели IOPS достигались тысячами или десятками тысяч шпинделей, теперь пачкой дорогих SSD-дисков или терабайтами Flash-памяти.
ОтветитьУдалитьЭтого Linux,что-то много стало.Или в самом деле время
ОтветитьУдалитьUnix и Solaris в частности проходит.Linux ведь не
тянет на серьёзных нагрузках.
Да давно уже пропагандирует PowerLinux, только лично я еще ни разу не видел его живьем в России. AIX on POWER сколько угодно. Даже приходилось сталкиваться с Linux on Itanium! (причем под Oracle!=) ). Насколько много ISV, поддерживающих эту платформу....кроме SAP.
ОтветитьУдалитьВ тестах TPC-C традиционно побеждали "космолеты" с нереалистичными дисковыми подсистемами (т.к. для высоких показателей tpmC необходимо обеспечить огромное кол-во IOPS), поэтому сравнивать по этому тесту серверы не слишком объективно. До эпохи SSD в тестовых конфигурациях были монстры с десятком тысяч шпинделей (при этом использовалось пару процентов емкости на самых быстрых крайних дорожках HDD); затем появились конфигурации с терабайтами SSD. В любом случае, эти конфигурации далеки от того, что используют заказчики.
ОтветитьУдалитьЛюбой Linux на любой платформе-всё тот же самый.Никаких отличий или преимуществ,только более худшая поддержка
ОтветитьУдалитьвозможностей аппартной платформы в том числе и на x86.Специально занимался вопросом.Проверял на SPARC T3 Power6
Xeon,ставил UNIX BSD Linux,запускал всякие проги,организовывал высокие нагрузки снимал самые разные показатели.
У Linux не,зависимо от дистрибутива,эти показатели хуже чем на других OS.Например,на Xeon лучшие показатели у *BSD.
Чтобы высказывание имело хоть какой-то вес, будьте добры, назовите - что же это за "высокие нагрузки" и "самые разные показатели"?
Удалить"Т.е. если вы изо всех сил выбираете, какой вам взять Linux, да на каком железе будет лучше, да еще и не дай бог какую взять БД для своего проекта - вы рискуете промахнуться на 7%."
ОтветитьУдалитьДмитрий, готов бы согласиться - с парой поправок:
1. Это новый проект. 100% from scratch.
2. Это либо проект, несильно "зажатый" по перформансу (или мелкая база, или большая база с маленьким актуальным подмножестовом), либо в проектной команде есть спецы и best practice по любой из альтернатив.
Вот только поправки всё переворачивают:
1) по моему опыту, проект 100% с нуля в энтерпрайзе - редкость. Что-то придется унаследовать, чаще всего - инфраструктуру: "нам плевать, что ваше приложение лучше себя ведет на Xeon, у нас тут везде - SPARC Т1 ближайшие три года". Да, через 3 года "случился" апгрейд и риспонз-тайм "вдруг" снизился на 1,5-2-5секунд для самых популярных экранов webapplication. Но до этого приходилось мириться, потому что переписывание кода под Т1 получалось никак не меньше 1000человеко-дней.
По внутренним оценкам, переписывание ядра одной энтерпрайзной системы с Oracle на DB2 выливалось в еще больший объем работ. Потому что "
http://publib.boulder.ibm.com/infocenter/dzichelp/v2r2/topic/com.ibm.db2z10.doc.sqlref/src/tpc/db2z_sql_readonlyclause.htm
For example, in programs that contain dynamic SQL statements without the FOR READ ONLY or ORDER BY clause, DB2 might open cursors as if the UPDATE clause was specified." - без переписывания это смерть scalability.
2) наличие реальных спецов по разным БД в одном ISV. Положа руку на сердце - часто приходилось видеть?
Т.е. если подача была про "какой линух на каком сервере" - полностью согласен.
Насчет "какая БД" и "всего 7% разницы" - увольте, несогласен.
Хоть с позиций честного ISV, хоть с позиций ex-бригадира сантехников. Равноправильно пишущих под Oracle и DB2 девелоперов - единицы, а чтобы просадить решение по производительности, хватит двух упертых апологетов чего-то одного, но не того, под что приложение targeted.
Это ты ловко сделал подмену понятий: обосновал невозможность миграции с позиции организационно-экономических проблем и сделал выводы о производительности двух СУБД в целом. Молодец, Сванидзе гордится тобой.
Удалить