The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

MySQL под Solaris работает на 60-90% быстрее чем под Red Hat Linux

23.04.2006 15:34

Компания Sun Microsystems опубликовала результаты OLTP (OnLine Transaction Processing) тестирования производительности Innodb хранилища в СУБД MySQL 5.0.18 под 64-разрядными сборками Solaris 10 и Red Hat Enterprise Linux 4 Advanced Server Edition.

На операциях чтения выигрыш Solaris составил 91%, на операциях чтения/записи - 64%. Тестирование проводилось на 4-x процессорном сервере Sun Fire V40z, работающем под управлением Dual-Core AMD Opteron 875 с 16 Гб ОЗУ.

По словам Sun Microsystems, подобных результатов удалось достичь благодаря работе по оптимизации кода Soalris 10, проведенной в кооперации с разработчиками MySQL.

Подробно результаты тестирования и параметры настройки MySQL изложены в данном PDF документе.

  1. Главная ссылка к новости (http://www.sun.com/smi/Press/s...)
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/7382-mysql
Ключевые слова: mysql, solaris, linux, benchmark, speed
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (34) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Квагга (?), 16:30, 23/04/2006 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Интересно, на Зионах такой же выигрыш?

    Или эта радость только на AMD + Соляра?

     
     
  • 2.2, DeadMustdie (??), 16:55, 23/04/2006 [^] [^^] [^^^] [ответить]  
  • +/
    > Интересно, на Зионах такой же выигрыш?
    Скорее всего, да. Такая разница производительности вряд ли вызвана сверхтонкой оптимизацией Solaris под AMD'шные камушки.
     
     
  • 3.4, Квагга (?), 17:51, 23/04/2006 [^] [^^] [^^^] [ответить]  
  • +/
    > Интересно, на Зионах такой же выигрыш?

    > Скорее всего, да. Такая разница производительности вряд ли вызвана
    > сверхтонкой оптимизацией Solaris под AMD'шные камушки

    Такая разница может быть вызвана СВЕРХТОЛСТОЙ оптимизацией Solaris.
    Спарковское масштабирование на процы может работать ТОЛЬКО со Спарком\Ниагарой и AMD.

    Более того, у меня есть подозрение, что "правильный" шедулер может работать
    только на AMD на матерях Sun Fire, подобно тому, как Mac OS X запускается
    только на Эппловских Интелах :(

     
     
  • 4.5, DeadMustdie (??), 18:20, 23/04/2006 [^] [^^] [^^^] [ответить]  
  • +/
    >Такая разница может быть вызвана СВЕРХТОЛСТОЙ оптимизацией Solaris.
    >Спарковское масштабирование на процы может работать ТОЛЬКО со Спарком\Ниагарой и AMD.

    Ню-ню. Некоторое время назад я гонял Solaris как раз на двухпроцессорной системе
    с Xeon'ами. И рядом на аналогичном железе под подобной нагрузкой трудился Linux.
    Собственно, крутилась и там, и там некая Оракловая база. Субъективно разница
    была солидная, и как раз в пользу Solaris.

    >Более того, у меня есть подозрение, что "правильный" шедулер может работать
    >только на AMD на матерях Sun Fire, подобно тому, как Mac OS
    >X запускается только на Эппловских Интелах :(

    Вряд ли переход с одного на другой процессор с совместимым набором инструкций
    может как-то сильно помочь планировщику делать свою работу, равно как и переход
    с одной мамы на другую. Разве что речь зайдёт о NUMA архитектурах, но здесь-то
    явно чистейшая 'UMA'.

     
     
  • 5.24, Michael Shigorin (?), 19:45, 24/04/2006 [^] [^^] [^^^] [ответить]  
  • +/
    > Субъективно разница была солидная
    Это 10--20% (уже солидная) или ближе к "60--90%"?  Те всё-таки сильно коррелируют с не столь давним тестом тринити на схожем же агрегате и очень сильно наводят на две мысли -- локинг и треды (сюрпризов тут нет).

    > но здесь-то явно чистейшая 'UMA'.
    Хде??  Я, конечно, в архитектурах профан полный, но про AMD64 как минимум в контексте "кучка оптеронов" слышал именно "NUMA".  От Бокового, кажется (им там в IBM/Samba должно быть видней ;-).

     
     
  • 6.25, DeadMustdie (??), 20:21, 24/04/2006 [^] [^^] [^^^] [ответить]  
  • +/
    >> Субъективно разница была солидная
    >Это 10--20% (уже солидная) или ближе к "60--90%"?  Те всё-таки сильно

    Очень приблизительно - в районе 30-50%.

    >Хде??  Я, конечно, в архитектурах профан полный, но про AMD64 как
    >минимум в контексте "кучка оптеронов" слышал именно "NUMA".  От Бокового,
    >кажется (им там в IBM/Samba должно быть видней ;-).

    Откуда там NUMA, простите? Там что, набор системных плат, каждая со своими
    отдельными процессорами, памятью и вводом-выводом, и коммутатор для объединения
    всего этого хозяйства воедино? По-моему, системы с подобной архитектурой
    в цене начинаются от $50K. И на x86-совместимых процах их обычно не делают.

     
     
  • 7.26, Michael Shigorin (?), 20:39, 24/04/2006 [^] [^^] [^^^] [ответить]  
  • +/
    >Откуда там NUMA, простите? Там что, набор системных плат
    Архитектуре-то с неравномерным доступом к памяти всё равно, куда засунули -- в кучку бордов или один чипсет (плюс N контроллеров памяти).

    Судя по "opteron numa", тут это /возможный/ при некоторых условиях отдельный режим:
    http://www.digit-life.com/articles2/cpu/rmma-numa.html
    http://www.ixbt.com/cpu/rmma-numa.shtml

     
  • 7.27, Dmitry (??), 20:40, 24/04/2006 [^] [^^] [^^^] [ответить]  
  • +/
    IMHO. Контроллер памяти внутри процессоров AMD, посему NUMA.
     
     
  • 8.30, Квагга (?), 02:36, 25/04/2006 [^] [^^] [^^^] [ответить]  
  • +/
    Типа того По независимому банку RAM на каждый из 4-х Оптеронов на основоной мам... текст свёрнут, показать
     
  • 4.6, rakshas (??), 19:07, 23/04/2006 [^] [^^] [^^^] [ответить]  
  • +/
    Нифига. MACOS(ломаный - :-) ) запускается и на обычных матерях Intel чипсет 945. Проверено.
    Главное чтоб железка была схожа.
     
  • 4.17, Alexxx (??), 11:32, 24/04/2006 [^] [^^] [^^^] [ответить]  
  • +/
    MacOS X (ессесно ломанный) нормально работает на Athlon64 и чипсете VIA.
     
     
  • 5.18, Квагга (?), 12:17, 24/04/2006 [^] [^^] [^^^] [ответить]  
  • +/
    И кто же шедулер Соляркин сломает?
     
  • 4.31, Mitja_L (?), 03:35, 25/04/2006 [^] [^^] [^^^] [ответить]  
  • +/

    >Более того, у меня есть подозрение, что "правильный" шедулер может работать
    >только на AMD на матерях Sun Fire, подобно тому, как Mac OS
    >X запускается
    >только на Эппловских Интелах :(

    Глупости.
    MacOS X запускается на компах с Pentium процессором, не Celeron и не AMD.
    Сам запускал на I845 чипсете+Pentium4 2.4GHz

     

  • 1.3, Dyr (??), 17:14, 23/04/2006 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Жаль, что не написали, с какими параметрами запускали sysbench. А то мне тоже интересно потестить, сейчас гоняю на двухядернике с FreeBSD, было бы интересно сравнить...
     
  • 1.8, Алексей (??), 21:34, 23/04/2006 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Ну молодцы, сравнили ОС собранную под i386 с x86_64.
    Маркетологам медаль.
     
     
  • 2.9, bashprompt (?), 22:16, 23/04/2006 [^] [^^] [^^^] [ответить]  
  • +/
    >Ну молодцы, сравнили ОС собранную под i386 с x86_64.
    >Маркетологам медаль.

    Они не настолько идиоты, чтобы брать таким примитивом. На самом деле причина в том, что Linux ядро начинает работать неэффективно при размерах памяти больше 4 Гб и числе процессоров больше 4. В тесте машина с 4-мя оптеронами, т.е. для системы 8 процессоров, и 16 Гб оперативки.
    В RHEL есть какие-то патчи для увеличения масштабируемости, но они лишь не дают явно падать лицом в грязь.

    Второй момент, в Solaris нити гораздо лучше чем в Linux.

    Для Linux оптимальным было бы сравнение на 2-х оптеронах с 4 Гб памяти, тогда отставание не было бы таким значительным. Если бы тестировали apache без нитей, вероятно Linux даже бы выйграл.

     
     
  • 3.10, Алексей (??), 23:48, 23/04/2006 [^] [^^] [^^^] [ответить]  
  • +/
    >Они не настолько идиоты, чтобы брать таким примитивом.
    Тем не менее - решили взять. Они-то и не идиоты, раз пипл и такое хавает - почему бы не использовать.
    >На самом деле причина в том, что Linux ядро начинает работать неэффективно при размерах памяти больше 4 Гб и числе процессоров больше 4. В тесте машина с 4-мя оптеронами, т.е. для системы 8 процессоров, и 16 Гб оперативки.
    Вообще-то в приведенном pdf - buffer pool размером 1ГБ, то есть остальная память в тесте не используется. И утверждается увеличение скорости select'ов на 40% при работе в один поток (а это - один процессор, читающий данные из 1 гб памяти).
     
     
  • 4.11, Евгений (??), 00:59, 24/04/2006 [^] [^^] [^^^] [ответить]  
  • +/
    Я ничего не утверждаю, но...
    1) в "тесте" не указано,  какая rhel взята - i386 или x86-64, не указано ядро - а у них есть разные (largesmp..) не указана ФС для обеих ОС, не указаны настройки системы вообще.
    Итого - по данному "документу" от Сана я бы вообще выводов не делал. Хотя очень хорошая работа Солярки на системах с несколькими процами мне известна и в ней я не совмневаюсь.
     
     
  • 5.13, Алексей (??), 02:48, 24/04/2006 [^] [^^] [^^^] [ответить]  
  • +/
    > 1) в "тесте" не указано,  какая rhel взята - i386 или x86-64
    RHEL4 x86_64 Sun не поддерживает и на железке из "теста", и вообще.
     
     
  • 6.16, NoFate (?), 09:55, 24/04/2006 [^] [^^] [^^^] [ответить]  
  • +/
    Ну тогда какой смысл сравнивать i386 и x86_64??? Чтобы быть как майкрософт?
     
  • 6.19, Евгений (??), 14:14, 24/04/2006 [^] [^^] [^^^] [ответить]  
  • +/
    >> 1) в "тесте" не указано,  какая rhel взята - i386 или x86-64
    >RHEL4 x86_64 Sun не поддерживает и на железке из "теста", и вообще.


    Хорошо...  я и не знал.
    Тогда это вообще не тест, а чистой воды профанация.
    Там же по идее клон nforce4 чипсет ?
    У Сана ж были заявления про сертифицированность их оптерон-серверов под rhel&suse..
    Но там не было указано, i386  или x86-64.  8-(

     
     
  • 7.20, Евгений (??), 14:24, 24/04/2006 [^] [^^] [^^^] [ответить]  
  • +/
      Про нфорс (на 4 сокетах :) я ,конечно же, сморозил.  

     
  • 7.21, Алексей (??), 15:47, 24/04/2006 [^] [^^] [^^^] [ответить]  
  • +/
    >  У Сана ж были заявления про сертифицированность их оптерон-серверов под rhel&suse..
    Но там не было указано, i386  или x86-64.  8-(
    На свои серваки они ставят SLES - x86_64, RHEL3 - x86_64, а вот RHEL4 - i386. Довольно странная логика конечно, учитывая что RHEL3 - на 2.4 ядре еще.
    А вообще железки хорошие и цены не ломят... так что может доведется поработать, поставлю вообще Федору. :))
     
     
  • 8.32, Евгений (??), 12:14, 25/04/2006 [^] [^^] [^^^] [ответить]  
  • +/
    как версия - RHEL4 - более опасный конкурент, чем SLES9 по поддержке железа ... текст свёрнут, показать
     
  • 3.12, Евгений (??), 01:02, 24/04/2006 [^] [^^] [^^^] [ответить]  
  • +/
    >>Ну молодцы, сравнили ОС собранную под i386 с x86_64.
    >>Маркетологам медаль.
    >
    >Они не настолько идиоты, чтобы брать таким примитивом.

    Ха!  А там вобще не указаны ни вариант RHEL, ни использ. ядро, ни ФС.
    Вообще ничего. Так что - пустой, чисто рекламный документ.

     

  • 1.15, hexmaker (?), 08:42, 24/04/2006 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Схемотехническая оптимизация чипсета на материнке сервера Sun Fire под Солярку. Ведь для себя же делали и оптимизировали под своё родное!
     
     
  • 2.22, ZOD (??), 17:22, 24/04/2006 [^] [^^] [^^^] [ответить]  
  • +/
    ГЫ, а может космические силы и вселенская энергия? Linuxu тоже дрова не идиёты пишут и спецификации железа доступны всем кому надо.
     

  • 1.23, pavlinux (??), 18:44, 24/04/2006 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Хрен тут спорить -  если купите 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 всё таки ведет.

     
  • 1.28, guest (??), 20:50, 24/04/2006 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    а вот нифига, как тоцел этот ничего нового непринес тока много слюней и пиара, а т1000 действительно что-то новое в камне строение.
     
  • 1.29, pavlinux (??), 22:17, 24/04/2006 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
      Вот кстати, коль уж про камушки заговорили
    "AMD to optimize future CPUs for Linux"
    http://www.techspot.com/news/21372-amd-to-optimize-future-cpus-for-linux.html
     
  • 1.33, Николас (?), 18:56, 11/05/2006 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Мда, маркетологи рулят... Хорошо что ещё всего 60-90%, могло бы быть и больше :)

    Восьмисотые оптероны есть NUMA система, тоесть у каждого процессора свой контролеер памяти и доступ к памяти другого процессора намного медленнее чем к родной.
    Ядра редхата для i386 собраны без поддержки NUMA, оттуда и тормоза.

    Linux гораздо лучше расширяемая операционная система чем всякие солярисы, поглядите хотябы в Top100 суперкомпьютеров - 95% работают под линуксом.

    --wbr Николас

     
     
  • 2.34, DeadMustdie (??), 23:30, 11/05/2006 [^] [^^] [^^^] [ответить]  
  • +/
    >Восьмисотые оптероны есть NUMA система, тоесть у каждого процессора свой контролеер памяти
    >и доступ к памяти другого процессора намного медленнее чем к родной.
    >
    >Ядра редхата для i386 собраны без поддержки NUMA, оттуда и тормоза.

    Я сильно подозреваю, что Линуховая "поддержка NUMA" всяко не лучше
    Солярисной будет. В Соляре ее лет 20 полировали.

    >Linux гораздо лучше расширяемая операционная система чем всякие солярисы,
    >поглядите хотябы в Top100 суперкомпьютеров - 95% работают под линуксом.

    Solaris на "своих" железках может все, что может Linux, плюс еще столько же.
    Кто пользовался, тот поймет. А кто не пользовался, тот пущай свой Linux сам ест.

     
     
  • 3.35, Николас (?), 17:05, 12/05/2006 [^] [^^] [^^^] [ответить]  
  • +/
    >Я сильно подозреваю, что Линуховая "поддержка NUMA" всяко не лучше Солярисной будет.
    >В Соляре ее лет 20 полировали.

    Неправильно подозреваете, в линуксе лучше менеджер памяти и планировщик процессов, поэтому Java приложения на многопроцессорных системах (и на однопроцессорных тоже) работают лучше под Linux чем под Solaris.
    Тот же факт, Sun долго тряслась портируя Linux на новый проц Sun t1000 (или как он там называется), так как клиентам без Linux эта система ненужна.
    NUMA в ядре линукса если я не ошибаюсь занималась SGI для своих высокопроизводительных многопроцессорных систем, что тоже чтото говорит...

    --wbr Николас

     
     
  • 4.36, DeadMustdie (??), 20:14, 12/05/2006 [^] [^^] [^^^] [ответить]  
  • +/
    >Неправильно подозреваете, в линуксе лучше менеджер памяти и планировщик
    >процессов, поэтому Java приложения на многопроцессорных системах
    >(и на однопроцессорных тоже) работают лучше под Linux чем под Solaris.

    Сказочник. Факты, please. Известные мне - ровно обратные. Особенно
    если систему правильно поднастроить.

    Что планировщик, что менеджер памяти в Соляре - очень хороши.
    Настолько близки к идеалу, насколько это вообще возможно в
    современной ОС. Нигде вы не найдете статей про проблемы
    производительности Solaris, упирающиеся в качество планировщика
    либо правильно выбранного и настроенного менеджера памяти.

    >Тот же факт, Sun долго тряслась портируя Linux на новый проц Sun
    >t1000 (или как он там называется), так как клиентам без Linux
    >эта система ненужна.

    T1000 - это модель сервера. Проц называется T1.
    По абсолютно всем параметрам Соляра - это такой идеальный Linux ;)
    Нормальным клиентам, на самом деле, Linux совершенно не уперся,
    потому что все, что может Linux - может и Solaris. Не наоборот.

    >NUMA в ядре линукса если я не ошибаюсь занималась SGI для своих
    >высокопроизводительных многопроцессорных систем, что тоже чтото говорит...

    SGI для своих систем IRIX полировала, совсем не Linux.

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру