Vadim Tkachenko, инженер занимающийся вопросами производительности в компании MySQL AB, провел серию тестов (http://www.mysqlperformanceblog.com/2006/06/15/freebsd-tests/) для оценки производительности FreeBSD 6.0 по сравнению с Suse 10.0.
Тестирование проводилось утилитой sysbench (http://sysbench.sf.net/). При сборке MySQL 5.0.22 с libpthread, FreeBSD показала значительное отставание от SuSE и крайне низкую стабильность (http://bugs.mysql.com/bug.php?id=19496) при большой нагрузке (во FreeBSD 6.1 проблема исправлена (http://www.freebsd.org/cgi/query-pr.cgi?pr=95127)).
Пересобрав MySQL с libthr, следуя данным рекомендациям (http://wikitest.freebsd.org/MySQL), результаты тестов в корне изменились, при нагрузке от 4 до 64 потоков FreeBSD продемонстрировала более высокую скорость работы с базами в формате InnoDB, немного уступив при этом в тестах для MyISAM.URL: http://www.mysqlperformanceblog.com/2006/06/15/freebsd-tests/
Новость: http://www.opennet.me/opennews/art.shtml?num=7731
вывод - большинство предпочтут SuSE, т.к. мало кому охота лезть во фрю с напильником.
а ты хочешь сделать _хороший_ сервер без напильника?
что фря проседает под сильной нагрузкой и в особенности это заметно в смп - это уже давно известно, и над этим работают. так что не надо в очередной раз улюлюкать и развивать холиворы.
А большинство предпочнувших СЛЕС оплатит лицензию?
Это от 3000 до 9000 тонн грина на систему, кстати.
Или большинство предпочнувших путает цену медиакита с ценой лицензии?
> вывод - большинство предпочтут SuSE, т.к. мало кому охота лезть во фрю с напильником.
В 6.1 проблем нет, зачем напильник? К тому package ещё никто не отменял.
Почему напильником? /etc/libmap.conf - на лету меняем для mysql libpthread на libthr. Все :)
а кто конфигурацию системы/мускула указывать будет?
опять getzef*ckts?
(more details about box and benchmark see here http://www.mysqlperformanceblog.com/2006/06/13/quick-look-at.../)."So I used MySQL 5.0.22 and my box Dual Core Athlon 3800+, 1Gb of RAM."
Тестирование во FBSD производилось "из коробки", т.е. !True FBSD Way
( наверняка GENERIC )
в том-то и дело, что "наверняка"...ну почему все громко орут, а нормальный отчет предоставить не могут...
хотьбы написали что ВСЕ ставилось из коробки - и суши и фря и мускул и сисбенч... одних верси и конфиги дефалтовые...
При чем тут конфигурация? Тестирование просто показывает что FBSD не хуже и не лучше линукса, опровергая недавнее тестирование, где FBSD проиграла по производительности в 5 раз.
> При чем тут конфигурация?Убей себя об стену, умник.
>Тестирование просто показывает что FBSD не хуже и не лучше линукса, опровергая недавнее >тестирование..
Оно показывает что MySQL заточена под Linux.
>...где FBSD проиграла по производительности в 5 раз.
Проект еще неизбавился от GIANT локов, а это не есть гут, так как степень грануляции ядра невысока, в отличие от Linux.
Но! FBSD Prj почти закончил решение этой задачи, так что поживем увидим...
Не забывайте про Solaris, который вроде на БОЛЬШИХ машинах Linux опережает thread-бенчмарках.
>Не забывайте про Solaris, который вроде на БОЛЬШИХ машинах Linux опережает thread-бенчмарках.
>случаем не на Sun Blade? =)
вобщем реализация потоков в Линуксе и ФриБСД разная... и, к сожалению, в ФриБСД она сделана... эмммм... "некрасиво" =\
хотя по результатам этих тестов ситуация значительно улучшилась
> Убей себя об стену, умник.
Подрасти сначала, мальчик.> Оно показывает что MySQL заточена под Linux.
Это не меньший бред чем `MySQL на MyISAM таблицах заточена под Linux, но при этом на InnoDB таблицах заточена под FreeBSD'
>
>Проект еще неизбавился от GIANT локов, а это не есть гут, так
>как степень грануляции ядра невысока, в отличие от Linux.
>
Для тебя будет новостью, что Giant в логах mutex profiling на MySQL практически не присутствует. Теперь борются с другими затыками, которых раньше из-за Giant было не видно.
Хочу сказать, что FreeBSD проигрывает по производительности тому же SLES 9, причем значительно. Могу показаться голословным, сейчас не могу привести условия и результаты моих наблюдений подробно. На одной и той же машине с 4 - мя процессорами под реальной нагрузкой около 1500 - 2000 запросов с сек под FreeBSD mysql ушел в глубокий ступор в связи с огромной конкуренцией потоков. На SLES ничего подобного не наблюдается, все пляшет без напрягов. Конфигурация, версия mysql, машина - одинаковые. Тестировалось на реальном проекте, что не есть гуд, однако прочуствовал эту разницу очень хорошо.
К предыдущему посту: Да, FBSD 6.1 и SLES 9 2.6 ядро. Памяти много.
Может вы generic юзали?! :)
Может не юзал :) Генерик юзаю только при установке.
Юзал libthr, кстати. lipthread - вообще что-то с чем-то.
Интересно было бы сравнить MySQL-FreeBSD с ULE и 4BSD.
Фряшный коммитер тестил, поиск в группах гуглевых...ps. afaik, пора уже и третий шедулер включать, который David Xu недавно закоммитил....;)
>>ps. afaik, пора уже и третий шедулер включать, который David Xu недавно закоммитил....;)
а вот насчет этого нельзя немного поподробнее?
Я тестил, ищите здесь или в community ru_root
Просто подозрительно почему-то у меня на 6.1 всё летает и у половины народа тоже, у другой половины - нет.. видать где-то что-то не от туда растёт или это очередная провокация линухоидов :) лично мне положить на эти вопли :)
а летает у тебя, потому что у тебя песочница детская, каким бы карьером ты ее не считал
>а летает у тебя, потому что у тебя песочница детская, каким бы карьером ты ее не считал
Не надо по себе судить, уважаемый. Не судимым будешь. Аргументы надо приводить.
>Не надо по себе судить, уважаемый. Не судимым будешь. Аргументы надо приводить.на двухголовых серверах с оптеронами проблемы с производительностью у фри.
Я возможно ошибаюсь, но FreeBSD, AFAIK, проигрывает линуксу в плане файловой системы. Так как MySQL в отличие от, скажем, Oracle, требователен к ФС, особенно под MyISAM.
Совершенно согласен. Особенно под большими нагрузками, когда памяти на кэш, сколько бы ее не было, уже не хватает. Тогда грамотно организованное упреждающее чтение, коим может похвастаться, например, XFS, -- оказывается крайне полезным. К сожалению, UFS2 подобнм пока не располагает.
Read-Ahead можт делать raid контроллер.
>Совершенно согласен. Особенно под большими нагрузками, когда памяти на кэш, сколько бы
>ее не было, уже не хватает. Тогда грамотно организованное упреждающее чтение,
>коим может похвастаться, например, XFS, -- оказывается крайне полезным. К сожалению,
>UFS2 подобнм пока не располагает.
Нету у XFS никакого особенного грамотного read-ahead, там read через общую общесистемную процедуру сделан. Соответственно и read-ahead логика там общесистемная, читай - никакая.
Да и не может она предсказать запросы MySQL.
Да, согласен. В Linux XFS действительно использует generic-read. Выходит, спасти дело может только reiser4...
Июнь на дворе -freebsd 6.1 в релизе
Проблема производительности mysql на freebsd - самая острая и серьезная для меня уже давно. Несколько лет гонок с тредами, версиями, хинтами и патчами. Я реально устал от этого. Я не вернусь на Линукс (прошу прощения у фанов этой системы, я тоже им был когда-то), и изучать новую систему - сродни выстрелу в спину.бещания от версии к версии что все решено, что новые треды стали ахуительно круты и стабильно надоели.
Блах, печально, печально.
Вот и сейчас, поа еще не накатив (да-да, я уже накатывал много раз читая релизы и изменения) на 6.1, распологая 6.0, я компилирую линухтреды и вяжу с ними mysql. Ибо нереально иначе, валится или не тянет.
А сколько конфигов я исписал для mysql...
Печально.
>А сколько конфигов я исписал для mysql...Уважаемый, как печально все это слышать. Просто изучите один раз нормально систему FreeBSD и все ее тонкости, и не мучайтесь более.
У меня на FreeBSD 6.0/6.1 MySQL-серверы держат о*уительные нагрузки. Пример: dual xeon 2,8, 3 gb ram, scsi hdd держит mуsql-сервер с 5k-7k запросов на секунду. И при этом процессор загружен на 30-40%, а la <= 3. Вот так.
>>А сколько конфигов я исписал для mysql...
>
>Уважаемый, как печально все это слышать. Просто изучите один раз нормально систему
>FreeBSD и все ее тонкости, и не мучайтесь более.
>
>У меня на FreeBSD 6.0/6.1 MySQL-серверы держат о*уительные нагрузки. Пример: dual xeon
>2,8, 3 gb ram, scsi hdd держит mуsql-сервер с 5k-7k запросов
>на секунду. И при этом процессор загружен на 30-40%, а la
><= 3. Вот так.Я вот тоже озабочен результатами тестов Фря против Соляры.
Но 6.1 реально продвинулась!
На 4.10 двухгловый Хеон с 4Гб озу УМИРАЛ под Мускулом.
Вплоть до фризов. 98% в топе это просто неперерывно.5.х, 6.0 - не пробовал. Сразу перекатился на 6.10.
База выросла, нагрузки на базу выросли. Конфиг мускула, и приложения НЕ менялись - топ показывает... 2%. Иногда.
В общем для начала - 6.10. Ну и треды от Дэвида Зю.
Я понимаю, нагрузки НЕ ТЕ. Это не 512 тредов, которые потащит Соляра.
Но после припадков отчаяния с 4.10 - 6.10 это большой прыжок.
Я очень доволен и верю, что 7.х уделает линя на СМП.
Ибо слип локи обещают большой прорыв рядом с линевыми спин локами.
>5.х, 6.0 - не пробовал. Сразу перекатился на 6.10.
Можно ссылку на версию 6.10? Что-то новенькое...
Уважаемый prh, а какой объем БД у вас?
Уважаемый prh, я пытаюсь. Если есть возможность поговорить по этому поводу мылом, был бы очень рад, как и что скомпилировано, какие настройки, объем БД и приложения.