Компания Sun Microsystems опубликовала (http://www.sun.com/smi/Press/sunflash/2006-04/sunflash.20060...) результаты OLTP (OnLine Transaction Processing) тестирования производительности СУБД MySQL 5.0.18 под Solaris 10 и Red Hat Enterprise Linux 4 Advanced Server Edition.
На операциях чтения выигрыш Solaris составил 91%, на операциях чтения/записи - 64%. Тестирование проводилось на сервере Sun Fire V40z, работающем под управлением Dual-Core AMD Opteron 875.
По словам Sun Microsystems, подобных результатов удалось достичь благодаря работе по оптимизации кода Soalris 10, проведенной в кооперации с разработчиками MySQL.
Подробно результаты тестирования изложены в данном PDF документе (http://www.sun.com/x64/docs/MySQL-sysbench-benchmark.pdf).
URL: http://www.sun.com/smi/Press/sunflash/2006-04/sunflash.20060...
Новость: http://www.opennet.me/opennews/art.shtml?num=7382
Интересно, на Зионах такой же выигрыш?Или эта радость только на AMD + Соляра?
> Интересно, на Зионах такой же выигрыш?
Скорее всего, да. Такая разница производительности вряд ли вызвана сверхтонкой оптимизацией Solaris под AMD'шные камушки.
> Интересно, на Зионах такой же выигрыш?> Скорее всего, да. Такая разница производительности вряд ли вызвана
> сверхтонкой оптимизацией Solaris под AMD'шные камушкиТакая разница может быть вызвана СВЕРХТОЛСТОЙ оптимизацией Solaris.
Спарковское масштабирование на процы может работать ТОЛЬКО со Спарком\Ниагарой и AMD.Более того, у меня есть подозрение, что "правильный" шедулер может работать
только на AMD на матерях Sun Fire, подобно тому, как Mac OS X запускается
только на Эппловских Интелах :(
>Такая разница может быть вызвана СВЕРХТОЛСТОЙ оптимизацией Solaris.
>Спарковское масштабирование на процы может работать ТОЛЬКО со Спарком\Ниагарой и AMD.Ню-ню. Некоторое время назад я гонял Solaris как раз на двухпроцессорной системе
с Xeon'ами. И рядом на аналогичном железе под подобной нагрузкой трудился Linux.
Собственно, крутилась и там, и там некая Оракловая база. Субъективно разница
была солидная, и как раз в пользу Solaris.>Более того, у меня есть подозрение, что "правильный" шедулер может работать
>только на AMD на матерях Sun Fire, подобно тому, как Mac OS
>X запускается только на Эппловских Интелах :(Вряд ли переход с одного на другой процессор с совместимым набором инструкций
может как-то сильно помочь планировщику делать свою работу, равно как и переход
с одной мамы на другую. Разве что речь зайдёт о NUMA архитектурах, но здесь-то
явно чистейшая 'UMA'.
> Субъективно разница была солидная
Это 10--20% (уже солидная) или ближе к "60--90%"? Те всё-таки сильно коррелируют с не столь давним тестом тринити на схожем же агрегате и очень сильно наводят на две мысли -- локинг и треды (сюрпризов тут нет).> но здесь-то явно чистейшая 'UMA'.
Хде?? Я, конечно, в архитектурах профан полный, но про AMD64 как минимум в контексте "кучка оптеронов" слышал именно "NUMA". От Бокового, кажется (им там в IBM/Samba должно быть видней ;-).
>> Субъективно разница была солидная
>Это 10--20% (уже солидная) или ближе к "60--90%"? Те всё-таки сильноОчень приблизительно - в районе 30-50%.
>Хде?? Я, конечно, в архитектурах профан полный, но про AMD64 как
>минимум в контексте "кучка оптеронов" слышал именно "NUMA". От Бокового,
>кажется (им там в IBM/Samba должно быть видней ;-).Откуда там NUMA, простите? Там что, набор системных плат, каждая со своими
отдельными процессорами, памятью и вводом-выводом, и коммутатор для объединения
всего этого хозяйства воедино? По-моему, системы с подобной архитектурой
в цене начинаются от $50K. И на x86-совместимых процах их обычно не делают.
>Откуда там NUMA, простите? Там что, набор системных плат
Архитектуре-то с неравномерным доступом к памяти всё равно, куда засунули -- в кучку бордов или один чипсет (плюс N контроллеров памяти).Судя по "opteron numa", тут это /возможный/ при некоторых условиях отдельный режим:
http://www.digit-life.com/articles2/cpu/rmma-numa.html
http://www.ixbt.com/cpu/rmma-numa.shtml
IMHO. Контроллер памяти внутри процессоров AMD, посему NUMA.
> Там что, набор системных плат?Типа того. По независимому банку RAM на каждый из 4-х Оптеронов на основоной маме
и по независимому банку RAM на каждый из 4-х Оптеронов на антресоли.
Нифига. MACOS(ломаный - :-) ) запускается и на обычных матерях Intel чипсет 945. Проверено.
Главное чтоб железка была схожа.
MacOS X (ессесно ломанный) нормально работает на Athlon64 и чипсете VIA.
И кто же шедулер Соляркин сломает?
>Более того, у меня есть подозрение, что "правильный" шедулер может работать
>только на AMD на матерях Sun Fire, подобно тому, как Mac OS
>X запускается
>только на Эппловских Интелах :(Глупости.
MacOS X запускается на компах с Pentium процессором, не Celeron и не AMD.
Сам запускал на I845 чипсете+Pentium4 2.4GHz
Жаль, что не написали, с какими параметрами запускали sysbench. А то мне тоже интересно потестить, сейчас гоняю на двухядернике с FreeBSD, было бы интересно сравнить...
Ну молодцы, сравнили ОС собранную под i386 с x86_64.
Маркетологам медаль.
>Ну молодцы, сравнили ОС собранную под i386 с x86_64.
>Маркетологам медаль.Они не настолько идиоты, чтобы брать таким примитивом. На самом деле причина в том, что Linux ядро начинает работать неэффективно при размерах памяти больше 4 Гб и числе процессоров больше 4. В тесте машина с 4-мя оптеронами, т.е. для системы 8 процессоров, и 16 Гб оперативки.
В RHEL есть какие-то патчи для увеличения масштабируемости, но они лишь не дают явно падать лицом в грязь.Второй момент, в Solaris нити гораздо лучше чем в Linux.
Для Linux оптимальным было бы сравнение на 2-х оптеронах с 4 Гб памяти, тогда отставание не было бы таким значительным. Если бы тестировали apache без нитей, вероятно Linux даже бы выйграл.
>Они не настолько идиоты, чтобы брать таким примитивом.
Тем не менее - решили взять. Они-то и не идиоты, раз пипл и такое хавает - почему бы не использовать.
>На самом деле причина в том, что Linux ядро начинает работать неэффективно при размерах памяти больше 4 Гб и числе процессоров больше 4. В тесте машина с 4-мя оптеронами, т.е. для системы 8 процессоров, и 16 Гб оперативки.
Вообще-то в приведенном pdf - buffer pool размером 1ГБ, то есть остальная память в тесте не используется. И утверждается увеличение скорости select'ов на 40% при работе в один поток (а это - один процессор, читающий данные из 1 гб памяти).
Я ничего не утверждаю, но...
1) в "тесте" не указано, какая rhel взята - i386 или x86-64, не указано ядро - а у них есть разные (largesmp..) не указана ФС для обеих ОС, не указаны настройки системы вообще.
Итого - по данному "документу" от Сана я бы вообще выводов не делал. Хотя очень хорошая работа Солярки на системах с несколькими процами мне известна и в ней я не совмневаюсь.
> 1) в "тесте" не указано, какая rhel взята - i386 или x86-64
RHEL4 x86_64 Sun не поддерживает и на железке из "теста", и вообще.
Ну тогда какой смысл сравнивать i386 и x86_64??? Чтобы быть как майкрософт?
>> 1) в "тесте" не указано, какая rhel взята - i386 или x86-64
>RHEL4 x86_64 Sun не поддерживает и на железке из "теста", и вообще.
Хорошо... я и не знал.
Тогда это вообще не тест, а чистой воды профанация.
Там же по идее клон nforce4 чипсет ?
У Сана ж были заявления про сертифицированность их оптерон-серверов под rhel&suse..
Но там не было указано, i386 или x86-64. 8-(
Про нфорс (на 4 сокетах :) я ,конечно же, сморозил.
> У Сана ж были заявления про сертифицированность их оптерон-серверов под rhel&suse..
Но там не было указано, i386 или x86-64. 8-(
На свои серваки они ставят SLES - x86_64, RHEL3 - x86_64, а вот RHEL4 - i386. Довольно странная логика конечно, учитывая что RHEL3 - на 2.4 ядре еще.
А вообще железки хорошие и цены не ломят... так что может доведется поработать, поставлю вообще Федору. :))
>> У Сана ж были заявления про сертифицированность их оптерон-серверов под rhel&suse..
>Но там не было указано, i386 или x86-64. 8-(
>На свои серваки они ставят SLES - x86_64, RHEL3 - x86_64, а
>вот RHEL4 - i386. Довольно странная логика конечно, учитывая что RHEL3
>- на 2.4 ядре еще.как версия - RHEL4 - более опасный конкурент, чем SLES9 ?
(по поддержке железа по идее проблем быть не должно, раз 3-ка работает.)>А вообще железки хорошие и цены не ломят...
>>Ну молодцы, сравнили ОС собранную под i386 с x86_64.
>>Маркетологам медаль.
>
>Они не настолько идиоты, чтобы брать таким примитивом.Ха! А там вобще не указаны ни вариант RHEL, ни использ. ядро, ни ФС.
Вообще ничего. Так что - пустой, чисто рекламный документ.
Схемотехническая оптимизация чипсета на материнке сервера Sun Fire под Солярку. Ведь для себя же делали и оптимизировали под своё родное!
ГЫ, а может космические силы и вселенская энергия? Linuxu тоже дрова не идиёты пишут и спецификации железа доступны всем кому надо.
Хрен тут спорить - если купите SunFire сервак + Солярис,
то будет вам счастья на 60% больше.
А купите IBM xServer, прочитаете " from Solaris to Linux on x86", и поставите
"Migration Kit for Solaris OS to Linux" и будет вам счастья на 60%+10% теперь уж хрен знает относительно кого (наверно Sun).Вот теперь угадайте, кого Sun имел ввиду в этой статейке...
Ну что ж, битва титатов продолжается:
IBM vs. Sun
Cell vs. Spark T1000
"Guide to porting" "Migration Kit for Solaris OS to Linux" vs. "Faster Solaris10 Than Red Hat Linux"Помоему IBM всё таки ведет.
а вот нифига, как тоцел этот ничего нового непринес тока много слюней и пиара, а т1000 действительно что-то новое в камне строение.
Вот кстати, коль уж про камушки заговорили
"AMD to optimize future CPUs for Linux"
http://www.techspot.com/news/21372-amd-to-optimize-future-cp...
Мда, маркетологи рулят... Хорошо что ещё всего 60-90%, могло бы быть и больше :)Восьмисотые оптероны есть NUMA система, тоесть у каждого процессора свой контролеер памяти и доступ к памяти другого процессора намного медленнее чем к родной.
Ядра редхата для i386 собраны без поддержки NUMA, оттуда и тормоза.Linux гораздо лучше расширяемая операционная система чем всякие солярисы, поглядите хотябы в Top100 суперкомпьютеров - 95% работают под линуксом.
--wbr Николас
>Восьмисотые оптероны есть NUMA система, тоесть у каждого процессора свой контролеер памяти
>и доступ к памяти другого процессора намного медленнее чем к родной.
>
>Ядра редхата для i386 собраны без поддержки NUMA, оттуда и тормоза.Я сильно подозреваю, что Линуховая "поддержка NUMA" всяко не лучше
Солярисной будет. В Соляре ее лет 20 полировали.>Linux гораздо лучше расширяемая операционная система чем всякие солярисы,
>поглядите хотябы в Top100 суперкомпьютеров - 95% работают под линуксом.Solaris на "своих" железках может все, что может Linux, плюс еще столько же.
Кто пользовался, тот поймет. А кто не пользовался, тот пущай свой Linux сам ест.
>Я сильно подозреваю, что Линуховая "поддержка NUMA" всяко не лучше Солярисной будет.
>В Соляре ее лет 20 полировали.Неправильно подозреваете, в линуксе лучше менеджер памяти и планировщик процессов, поэтому Java приложения на многопроцессорных системах (и на однопроцессорных тоже) работают лучше под Linux чем под Solaris.
Тот же факт, Sun долго тряслась портируя Linux на новый проц Sun t1000 (или как он там называется), так как клиентам без Linux эта система ненужна.
NUMA в ядре линукса если я не ошибаюсь занималась SGI для своих высокопроизводительных многопроцессорных систем, что тоже чтото говорит...--wbr Николас
>Неправильно подозреваете, в линуксе лучше менеджер памяти и планировщик
>процессов, поэтому Java приложения на многопроцессорных системах
>(и на однопроцессорных тоже) работают лучше под Linux чем под Solaris.Сказочник. Факты, please. Известные мне - ровно обратные. Особенно
если систему правильно поднастроить.Что планировщик, что менеджер памяти в Соляре - очень хороши.
Настолько близки к идеалу, насколько это вообще возможно в
современной ОС. Нигде вы не найдете статей про проблемы
производительности Solaris, упирающиеся в качество планировщика
либо правильно выбранного и настроенного менеджера памяти.>Тот же факт, Sun долго тряслась портируя Linux на новый проц Sun
>t1000 (или как он там называется), так как клиентам без Linux
>эта система ненужна.T1000 - это модель сервера. Проц называется T1.
По абсолютно всем параметрам Соляра - это такой идеальный Linux ;)
Нормальным клиентам, на самом деле, Linux совершенно не уперся,
потому что все, что может Linux - может и Solaris. Не наоборот.>NUMA в ядре линукса если я не ошибаюсь занималась SGI для своих
>высокопроизводительных многопроцессорных систем, что тоже чтото говорит...SGI для своих систем IRIX полировала, совсем не Linux.