Сравнение масштабируемости FreeBSD 7-CURRENT и Fedore Core 6

жж - компетентное место

но чем мы хуже осньюсов? :)

А чего не с Centos 4 или Fedora7? Так-бы честнее было...

Мне конечно не интересно, но кто победил?

> А чего не с Centos 4 или Fedora7? Так-бы честнее было...

Вероятно потому что у автора уже стояла Fedora Core 6, используемая для работы, а Fedore 7 ещё не вышла. При этом он обновил ядро до последней стабильной версии.

> Мне конечно не интересно, но кто победил?

Неужели так трудно посмотреть?

по графикам видно что гонево конкретное :-)

Мля, мы на лоре, тут не ходят по ссыкам. Кто победил?

При воображении, включенном на максимум не понимаю, как оно так получилось. А transactions/sec -- это на клиента? Или в сумме?

сравниваем теплое с мягким?

>А transactions/sec -- это на клиента? Или в сумме?

меня такие графики веселят тоже.

видать в Линуксе работает не больше 8 нитей - потом, видать, что-то ломается :)

Самое плохое это то, что похожие графики я уже где-то видел, только там сравнивали с solaris-ом, а еще хуже что это совпадает с моим личным опытом работы с linux-ом.

Очередное относительное сравнение, особо даверия не внушает..

Гдето я уже слышашл эти словечки ! Денисик ?

бред

> видать в Линуксе работает не больше 8 нитей - потом, видать, что-то ломается :)

Видать, пока одна нить работает на одном процессорном ядре, всё примерно одинаково. А когда на одно ядро нужно навесть несколько активно работающих нитей, вот тут начинаются интересности. Я надеюсь, ты обратил внимание на надпись "8-core am64" ?

Ложь, пи**ёж и провокация! Небось то чудо дедлайн-шедулер воткнуло и дма выключило. Какой-то реально анриал полный, даже с учётом AMD и в диком темпе мигрирующих по ядрам нитках...

Странные результаты - скорее всего какая-то проблема в FreeBSD'шном планировщике - может быть он решил, что mysql процессы вдруг стали RR.

Даже SUN на своем Slowlaris показала, что Mysql 5 не масштабируется: http://tweakers.net/reviews/649/5

Linux и Solaris не масштабируются, а FreeBSD вдруг заработала?

Кстати, почему postgres всегда быстрее mysql в таких тестах, а используется реже?

Не потому ли, что треды хуже чем fork на smp? С точки зрения масштабируемости... Это в смысле причин, почему Postgre на таких тестах лучше.

>Гдето я уже слышашл эти словечки ! Денисик ?

Нет, это не "Денисик". Мне просто интересно, зачем на серваки FC и тому подобное... Может ещё кубунту поставить? %)

Так кто же победил? :D

>Небось то чудо дедлайн-шедулер воткнуло и дма выключило.

ага, особенно классно это объясняет резкий провал производительности при количестве нитей > 1 на ядро.

фанатизм глаза застит?

<quote>

son: "Ma - Linus says Linux is the best os around the world" ... mother: "yes my dear, take a cookie and be quiet"

</quote>

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

>Не потому ли, что треды хуже чем fork на smp? С точки зрения масштабируемости... Это в смысле причин, почему Postgre на таких тестах лучше.

Очень маловероятно.

>Valmont * (*) (24.02.2007 17:21:46)

Гм, а почему на всех тестах с FreeBSD есть провал роста производительности на количестве потоков от 5 до 7. Вещь очень подозрительна - выходит что шедулер FBSD не способен дать линейную маштабируемость на количестве нитей меньшем чем количество ядер, зато потом дает офигительно ровный участок, у которого не получается демонстрировать уменьшение производительности хотя-бы на 10-12%(это только в первом приближении) на одну нить при условии линейной маштабируемости mysql. Если то, что нарисовано в графике не ересь, то я снесу все линуха с серверов ко всем чертям и поставлю 7ую фряху. И никакого апгрейда железа.

>Гм, а почему на всех тестах с FreeBSD есть провал роста производительности на количестве потоков от 5 до 7.

где вы видите провал? падение роста производительности не есть провал. вот у линакса при > 8 это действительно ужасный провал.

If you are interested in a purely experimental snapshot release of FreeBSD-CURRENT (AKA 7.0-CURRENT), aimed at developers and bleeding-edge testers only, then please see the FreeBSD Snapshot Releases page.

а я видел тесты где linux + postgre даёт колоссальное преимущество на 8 ядерном компе по сравнению с FreeBSD + mysql.

>а я видел тесты где linux + postgre даёт колоссальное преимущество на 8 ядерном компе по сравнению с FreeBSD + mysql.

А я видел тесты, где BMW 330 с четырьмя колесами дает колоссальное преимущество перед 8 ядерном компом.

zort, выдыхай.

Победила дружба! Но линукс, почему-то слил...

Всё-таки правильнее было бы не федору тестить, а что-то типа SLES или RHEL. Тогда тест был бы более объективным. У меня хоть и всюду Фря, но хотелось бы объективности -- видеть сравнение с каким-то именно серверным дистром.

> Linux и Solaris не масштабируются, а FreeBSD вдруг заработала?

Там, по-моему, не названа тредовая библиотека. А это для FreeBSD очень серьёзный момент - libkse и libthr/libthread очень по-разному работают.

А что не с liveinternet.ru? А лучше с damochka.ru.

Некто... Охренеть.

У Fedora Core 6 еще НЕТ ядра 2.6.20.

А какой планировщик? А то лениво в комментах разгребать.

Обсуждение результатов теста на freebsd-performance@freebsd.org

http://lists.freebsd.org/pipermail/freebsd-performance/2007-February/thread.h...

>>А что не с liveinternet.ru? А лучше с damochka.ru.

Если бы вы почитали ранние записи. то увидели бы что чувак шедулер написал во фре. Лоровская привычка хаять не разобравшись ?

The test was run on FreeBSD 7.0, with the latest version of the ULE 2.0 scheduler, the libthr threading library, and an uncommitted patch from Jeff Roberson [1] that addresses poor scalability of file descriptor locking (using a new sleepable mutex primitive); this patch is responsible for almost all of the performance and scaling improvements measured. It also includes some other patches that have been shown to help contention in MySQL workloads in the past (including a UNIX domain socket locking pushdown patch from Robert Watson), but these were shown to only give small individual contributions, with a cumulative effect on the order of 5-10%

Обычно оптимизают ПО под ОС, а тут, видимо, ОС под ПО решели оптимизнуть.

Роман.

> Всё-таки правильнее было бы не федору тестить, а что-то типа SLES или

> RHEL

Я вообще слабо понимаю, как федора вообще хоть как-то работает. Вы посмотрите на федоров конфиг. КАКОЕ количество дебага там включено. А потом возьмите исходники федоровского kernel.src.rpm. Помимо стандартного дебага, RedHat пихает туда дополнительный, более глубокий дебаг. Федора работает раза в три медленнее самосборного оптимизированного ядра без дебага.

> У Fedora Core 6 еще НЕТ ядра 2.6.20.

что значит нет??? А какже девелопмент репозитарий???

> что значит нет??? А какже девелопмент репозитарий???

девелопмент репозитарий - это НЕ Fedora Core 6!

http://lkml.org/lkml/2007/2/25/191

"Некто" jeffr_tech - это jeff@freebsd.org, автор шедулера ULE/ULE2 и многих других вещей. Компетентный и талантливый человек.

> "Некто" jeffr_tech - это jeff@freebsd.org

К сожалению эта информация отсутствует в его профайле.

RedHat воспроизвела проблему в Линуксе:

http://jeffr-tech.livejournal.com/6602.html

>Я вообще слабо понимаю, как федора вообще хоть как-то работает. Вы посмотрите на федоров конфиг. КАКОЕ количество дебага там включено.

debuginfo НЕ ВЛИЯЕТ на производительность - только на размер бинарника. максимум что может влиять - это присутствие stack frame - но это копейки.

>Федора работает раза в три медленнее самосборного оптимизированного ядра без дебага.

это конечно нетак. учите матчасть. да и ядро было 2.6.20, а не федорино 2.6.19.

>Если бы вы почитали ранние записи. то увидели бы что чувак шедулер написал во фре. Лоровская привычка хаять не разобравшись ?

И чего? Шедулер во фре, насколько я помню, частично списан с линухового. Если он шедулер написал, то сразу стал спецом в настройке фри и линухов под musql?

>А потом возьмите исходники федоровского kernel.src.rpm. Помимо стандартного дебага, RedHat пихает туда дополнительный, более глубокий дебаг. Федора работает раза в три медленнее самосборного оптимизированного ядра без дебага.

Продакшн показывает обратное.

Коллеги, успокойтесь!

Шапкозакидательство здесь неуместно. Нужно тщательно проверить результаты и найти причины падения производительности. Не исключено, что проблема _действительно_ есть

ULE шедулер, как мне помнится, по признанию самого автора, был написан с оглядкой на O(1) шедулер Инго Монара. "Списан", скорее, слишком грубый термин, просто при написании ULE использовались идеи из Linux. Не вижу в этом ничего позорного или осудительного, нормальное эволюционное развитие.

>о признанию самого автора, был написан с оглядкой на O(1) шедулер Инго Монара

The Solaris scheduler ideas I borrowed had nothing to do with interactivity. I just took some inspiration from their cpu selection algorithm. http://jeffr-tech.livejournal.com/6602.html

> ULE achieves both by borrowing a novel
approach from the 2.5 Linux scheduler and the
development of new algorithms surrounding that
mechanism.

> ULE: A Modern Scheduler For FreeBSD
>            Jeff Roberson