LINUX.ORG.RU

MySQL scalability benchmark

 , ,


0

0

Из списка рассылки freebsd-performance@freebsd.org. Была использована следующая конфигурация оборудования - два процессора Intel(r) Xeon E5405 2.00GHz, суммарно 8 CPU.

Результаты sysbench:

число запросов чтение/запись (1 поток / 8 потоков)

FreeBSD 6.2 (6091.80 / 5614.48)
FreeBSD 7.1 (6741.98 / 28091.60)
SunOS 5.10 (4286.61 / 6949.80)

Совершенно неожиданный результат для Solaris.

>>> Подробности



Проверено: JB ()

Саныч против Сана? Да объективен иногда :)

timur_dav ☆☆☆☆☆
()

>суммарно 8 CPU

Я бы сказал, что 2 CPU и 8 ядер :) Всё же, CPU - это железячный, а не конструкционый термин. А то можно будет сказать, что и у всяких БЭСМ были ЦПУ. Ну и что, что мультиплатные :D

KRoN73 ★★★★★
()

нет ни настроек mysql, ни настроек ос, ни строки sysbench, рассылка freebsd, сам автор считает тест quick and dirty..

мораль - несерьезно..

anonymous
()

что меряли, как меряли, зачем меряли - не известно. где какие попугаи? Это разве тест? Это разве новость?

пц, деградация.

anonymous
()
Ответ на: комментарий от anonymous

А я вообще не видел тестов мускуля на разных системах, хотя активно интересуюсь этим. Наверное кто-то их делает, но на деньги заказчика.

Sun-ch
() автор топика
Ответ на: комментарий от phasma

Да, поэтому и запостил. Кто бы мог ожидать от этой старой доброй рабочей лошади такой прыти.

Sun-ch
() автор топика
Ответ на: комментарий от KRoN73

> А то можно будет сказать, что и у всяких БЭСМ были ЦПУ. Ну и что, что мультиплатные :D

На момент изобретения термина CPU они все были мультиплатные.

tailgunner ★★★★★
()

Хочу сравнение с SunOS 5.11. И с линуксом

anonymous
()

Я нихрена не понял

> Результаты sysbench:

> число запросов чтение/запись (1 поток / 8 потоков)

> FreeBSD 6.2 (6091.80 / 5614.48)

> FreeBSD 7.1 (6741.98 / 28091.60)

> SunOS 5.10 (4286.61 / 6949.80)


Какие запросы? 4286.61 запросов чтения и 6949.80 запросов записи? Тогда почему число дробное? Наверно 4286.61 запросов чтение/запись в 1 поток, и 6949.80 запросов чтение/запись в 8 потоков? Но почему число дробное? Наверное это в единицу времени? В секунду? В минуту? В год?

По ссылке, как всегда, не ходил.

xintrea
()
Ответ на: комментарий от KRoN73

> Всё же, CPU - это железячный, а не конструкционый термин.

Нет, CPU/ЦП - это архитектурный термин. А конструктивно это микросхема или набор микросхем. Подробнее об истории здесь http://en.wikipedia.org/wiki/Cpu

nempyxa ★★
()
Ответ на: комментарий от xintrea

SysBench is a modular, cross-platform and multi-threaded benchmark tool for evaluating OS parameters that are important for a system running a database under intensive load.

Current features allow to test the following system parameters:

    * file I/O performance
    * scheduler performance
    * memory allocation and transfer speed
    * POSIX threads implementation performance
    * database server performance (OLTP benchmark)

Sun-ch
() автор топика
Ответ на: комментарий от anonymous

>А у БЭСМ не было CPU? Интересно.

Только при логическом (в уме) объединении плат АЛУ, УУ и т.п.

Под ЦПУ/CPU же изначально понимался законченный сменный модуль. А уж сейчас (точнее - последние лет 25) под CPU понимается исключительно микропроцессор.

KRoN73 ★★★★★
()
Ответ на: комментарий от nempyxa

>Нет, CPU/ЦП - это архитектурный термин. А конструктивно это микросхема или набор микросхем.

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

Для меня CPU - это в первую очередь Unit. Сменный девайс. Как с мультиядерном процессоре поменять ядро? :)

KRoN73 ★★★★★
()
Ответ на: комментарий от KRoN73

На серьезных машинах до сих пор так. Процессор + локальная память == юнит. Все юниты соединяются высокоскоростной шиной.

Sun-ch
() автор топика
Ответ на: комментарий от Sun-ch

> Я так и знал, линакс 2.6.23 после числа потоков == числу ядер, резко слил даже FreeBSD 7.0.

Бредятина. Элементарно сменить шедулер на удобный для DB или наоборот и результаты кардинально изменятся, не говоря уже о куче других факторов никак не раскрытых в тестах. Это равносильно сравнивать производительность процессоров по цвету системного блока.

anonymous
()

> число запросов чтение/запись (1 поток / 8 потоков) > FreeBSD 6.2 (6091.80 / 5614.48)

Ничего не понял. Это запись/чтение или же 1/8 потоков?

А тут: > FreeBSD 7.1 (6741.98 / _28091.60_)

Фря внезапно обоглала компьютер? Под ней даже ява теперь тормозить не будет.

anonymous
()

> FreeBSD 6.2 (6091.80 / 5614.48)
> FreeBSD 7.1 (6741.98 / 28091.60)


БЗДуны из года в год утверждали, что БЗДя итак самая быстрая. А тут, очевидно, комп под воздействием FreeBSD-7.1 перешел в состояние сверхпроводимости.

anonymous
()
Ответ на: комментарий от anonymous

Видно, что серьезно начали улучшать поддержку SMP систем.

Sun-ch
() автор топика

Запомоили соляру опенсорсом ...

anonymous
()

Неужели у 7.1 такая хорошая поддержка SMP? Что-то с трудом верится. И почему 6.2, а не 6.4?

alex-w ★★★★★
()
Ответ на: комментарий от alex-w

Наверное потому что между 6.2 и 6.4 нет разницы в качестве поддержки SMP. А вот 7-ая ветка действительно сильно отличается по масштабируемости.

aff
()
Ответ на: комментарий от aff

SCHED_ULE рулит! Хотели треды в SMP -- на-те Вам треды в SMP! Как положено! Позитив есть однозначно!

byteplayer
()

Для Ъ:


2009/1/27 pluknet <pluknet at gmail.com>:
> Do anyone have MySQL scalability comparison numbers between
> FreeBSD7.x/8 and Solaris?
>
> Thanks.

I have quick'n'dirty scalability benchmark.

HW: 2 x Intel(r) Xeon(r) CPU           E5405  @ 2.00GHz
8 cpus summary.

Values extracted from sysbench:

read/write requests     1 thread        /       8 threads

FreeBSD 6.2             6091.80                 5614.48
FreeBSD 7.1             6741.98                 28091.60
SunOS 5.10              4286.61                 6949.80


Too strange for Solaris..


-- 
wbr,
pluknet

Harliff ★★★★★
()
Ответ на: комментарий от anonymous

>>http://www.kernel.org/pub/linux/kernel/people/npiggin/sysbench/

> Остается надеется, что ситуация улучшится в 8-ой версии FreeBSD

Ну, солярщики файловую систему им подогнали, IO шедулер они, вроде сами пробуют писать. Планировщик задач они сами вылизывали для оптимальной работы на многоядерных системах еще для 7-ки. Так что если не на 8-ке, так на 9-ке можно будет базы данных гонять.

забавляют BSD'оиды. Соптимизируют систему под узкий класс задач и не просто гордятся этим, а считают ее самой передовой.

anonymous
()
Ответ на: комментарий от Harliff

Цифры впечатляют, но "quick'n'dirty scalability benchmark" --- он и в африке "quick'n'dirty scalability benchmark".

Человек мог получить результаты таких тестов не из за того, что солярка плохая, а freebsd 7.1 рвет всех в клочья, а из за кучи других, не зависящих о конкретной ОС факторов.

По нормальному нужно звать сантехников, давать им настроить солярку и только после этого проводить тесты...

А тут получается --- человек из рассылки FreeBSD сделал quick'n'dirty тесты, в которых победила FreeBSD... Ну да, а я вот устрою тесты (quick'n'dirty), в которых победит линукс.

А потом прийдет виндузятник и тоже проведет свои тесты, и будет нам Get The Facts.

То есть, нужно устраивать нормальное тестирование, а не брать результаты из рассылки freebsd.

Кстати, а с какой архитектурой SunOS работает лучше? C x86/amd64 или со спарками?

Harliff ★★★★★
()
Ответ на: комментарий от Harliff

Хотя вообще я рад, что FreeBSD совершенствуется. Должно же быть разнообразие...

Harliff ★★★★★
()
Ответ на: комментарий от brbr

>инуксячьи ссылки с превосходством Linux над FreeBSD в студию! >http://www.kernel.org/pub/linux/kernel/people/npiggin/sysbench/

Ты хоть сам по ссылке которую дал ходил ?

FreeBSD 7.0 was used with all settings default except a custom kernel was used, with SCHED_ULE. Linux kernel 2.6.25-rc4 was the Linux version tested, with glibc 2.7. All non-essential services and processes were stopped before running the tests.

Другими словами взяли настроеный Linux и дефолтную FreeBSD и провели тесты.

anonymous
()

я так пологаю тесты проводились на оттюнингованной этими фанатиками freesbd и на поставленной мизинцем левой ноги соплярисе? как обычно тесты очень "объективны"...

anonymous
()
Ответ на: комментарий от anonymous

> Другими словами взяли настроеный Linux и дефолтную FreeBSD и провели тесты.

Числа для FreeBSD примерно соответствуют тем, чтобы указаны в тестах бздунов, а вот результаты для линукса отличаются в разы. Наверное, можно предположить, исходя из того, что БСД не пытались принизить, что показанный результат значительно больше соответствует действительности, чем то что тестили бздуны. Тебе так не кажется?

anonymous
()

Смешно наблюдать как красноглазое линуксоидное быдло пытается прийти в себя, наблюдая что их супер пупер систему кто-то обошел. Теперь писают кипятком и опускаются в оскобления лишь бы доказать самим себе что они самые крутые, их лицензия самая правильная и вобще они все сплощ на подбор первые парни на деревне. Насколько же вы смешны, красноглазики. А ведь причину сливания линуха нашли еще год назад, это heap allocator в glibc, неужели за год супер программисты GNU не смогли его пофиксить? Похоже что так - они курили свой фан и им не до дел рядовых красноглазиков. Удачи вам, линупсойды ;)

anonymous
()
Ответ на: комментарий от anonymous

Идиот?! Тесты по ссылке к линуксу отношения не имеют.

anonymous
()
Ответ на: комментарий от anonymous

Эм, это вы сейчас к чему? Дайте нам тоже вашей травы!

Mystic
()
Ответ на: комментарий от anonymous

> А ведь причину сливания линуха нашли еще год назад

Интересно, а если выбрать синюю пилюльку, то M$ станет самым самым? любимым...

alx_me ★★☆
()
Ответ на: комментарий от Harliff

Именно поэтому лучше всего использовать ту систему, которую знаешь лучше других альтернатив.

AVL2 ★★★★★
()
Ответ на: комментарий от Harliff

Нормальные тестирования - это миф. Или фороникс круты?

anonymous
()

Err.. It seems we overoptimized our MySQL or whatever.. Official 5.0.67 build for SunOS gives us:

SunOS 5.10 5676.93 25085.87

-- wbr, pluknet

Вот так.

Sun-ch
() автор топика
Ответ на: комментарий от Sun-ch

Ага, вот это больше на правду похоже - не то "оптимизировали". Теперь бы еще увидеть результаты сисбенча на той же машине для линукса. Хотя с вероятностью в 90% нетюнингованый линукс сольет фряхе и солярке.

alex-w ★★★★★
()
Ответ на: комментарий от Sun-ch

> На серьезных машинах до сих пор так. Процессор + локальная память == юнит. Все юниты соединяются высокоскоростной шиной.

Саныч, ну не лоши, а? на серьезных машинах юнит=процессорЫ х память х I/O и все юниты на быстрой кросс-шине

HellAngel ★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.