LINUX.ORG.RU

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


0

0

Jeff Roberson на примере MySQL, сравнил масштабируемость текушей 7-CURRENT версии FreeBSD с масштабируемостью Fedore Core 6.

Первое сравнение:
http://jeffr-tech.livejournal.com/570...

Второе сравнение, с учётом комментариев:
http://jeffr-tech.livejournal.com/626...

Комментарий автора о целях этих сравнений:
http://jeffr-tech.livejournal.com/601...

>>> Обсуждение на OSNews

★★★★★

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

Ответ на: комментарий от los_nikos

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

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

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

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

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

bbk123 ★★★★★
() автор топика

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

chuchelo
()

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

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

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

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

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

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

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

Pi ★★★★★
()

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

avatar
()

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

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

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

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

anonymous
()

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

Gharik
()

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

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

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

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

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

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

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

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

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

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

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

ага, особенно классно это объясняет резкий провал производительности при количестве нитей > 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>

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

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

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

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

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

rtc ★★
()

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

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

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

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

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

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.

los_nikos ★★★★★
()

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

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

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

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

zort, выдыхай.

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

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

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

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

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

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

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

netch
()

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

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

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

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

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

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

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%

anonymous
()

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

Роман.

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

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

> RHEL

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

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

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

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

anonymous
()

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

jackill ★★★★★
()

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

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

annoynimous ★★★★★
()

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

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

> 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

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