скорость MySQL на разных OS

viktor954

Авторы сравнения могли бы и Выньду хохмы ради в тест включить....

Julie16

Вполне предсказуемые результаты Особенно на нескольких процессорах. И что бы не говорили некоторые личности(по поводу fine grained locks для FreeBSD результат налицо.
PS: единственное что показалось несколько необычным, что ядро 2.4 масштабируется несколько лучше чем 2.6. Хотя разница там невелика(около 10% но все же.

dkmv

А можно попросить локальную копию статьи/сообщения для тех, у кого нет инета?
Потому как тема очень интересная
Заранее great thanks!

dkmv

Действительно, большое спасибо!
Весьма информативная статья.

janlynn

хыхы
http://www.microsoft.com/Rus/GetTheFacts/analyses.mspx

Marinavo_0507

fine grained locks обычно нужны, если процессоров гораздо больше двух

sergey_m

Вполне предсказуемые результаты Особенно на нескольких процессорах. И что бы не говорили некоторые личности(по поводу fine grained locks для FreeBSD результат налицо.

А fine grained locks вообще-то не единственное, что нужно для работы userland тредовых приложений.
Я еще до этого теста знал, что userland треды в Linux быстрее, чем в FreeBSD, и что MySQL лучшая тому иллюстрация. Считается, что у MySQL tier-1 платформа Linux и поэтому все оптимизации делаются под Linux. Не знаю насколько это правда.
Что же до конкретного теста, то из текста не понятно, какая же тредовая библиотека использовалась в FreeBSD 5. Похоже автор не в курсе, что их две. Как часто бывает в тестах, побеждает та ОС, которую знает и пользуется автор.
P.S. Вот этот тред: http://lists.freebsd.org/pipermail/freebsd-current/2005-February/046326.html

sergey_m

http://www.microsoft.com/Rus/GetTheFacts/analyses.mspx:
Windows превосходит Linux по результатам тестов веб-серверов в различных конфируациях

Мы недавно под пивко разработали такой план. Нужно купить Windows, официально заключить пари на $100k о том, что виндовз превосходит Linux по результатам тестов веб-серверов в различных конфигурациях. В присутствии независимых экспертов успешно проиграть спор. Подать в суд на MS, выиграть много денег.
В нашей стране такой план конечно не прокатит, но вот по другую сторону океана легко.

Julie16

А fine grained locks вообще-то не единственное, что нужно для работы userland тредовых приложений.

И что? fine grained locks необходимы чтобы треды не мешали друг другу. При системных вызовах. Например чтобы один тред мог читать файл а другой - писать в сеть. Чем локи мельче, тем менее треды мешают друг другу. И тем больше оверхед, разумеется. Поэтому понятно почему NetBSD зарулила в однопроцессорном тесте В Linux работа в этом направлении началась несколько раньше, видимо поэтому и результаты лучше. И еще, я не знаю как у вас называются тредовые библиотеки, но для FreeBSD там два результата: с суффиксами KSE && LT. Это не имеет отношения к твоему вопросу?

sergey_m

И что? fine grained locks необходимы чтобы треды не мешали друг другу. При системных вызовах.

Да. Но userland библиотека тоже не на последнем месте. Нужно быстро и дешево пробуждать треды когда другие треды засыпают. И от выбора того, кого будить тоже многое зависит.
Лучше всего в FreeBSD залочен сетевой стек, который в тестах MySQL не участвует. Также залочен VM. Не могу оценить насколько он используется при работе MySQL. Обычно MySQL не выделяет память при постоянной нагрузке, но я не знаю делает ли он какие-то ремапы. Под Giantом находится уровень VFS и FFS, ясное дело, что это сыграло роль в тестах. Работа над удалением Giant из VFS и FFS ведётся непосредственно сейчас в CURRENT.

И еще, я не знаю как у вас называются тредовые библиотеки, но для FreeBSD там два результата: с суффиксами KSE && LT. Это не имеет отношения к твоему вопросу?

Нет. LT означает linux threads. Это в портах есть такая библиотечка, которая реализуется POSIX threads через fork то есть точь в точь как в старых линуксах. Поэтому она так называется. Известный факт, что MySQL всегда очень хорошо работал на этой библиотеке, что кстати и служит подтверждением того, что он разрабатывается под Linux и под него оптимизируется.
KSE это kernel scheduling entities, то есть ядерные треды. Существует две библиотеки реализующих POSIX threads через KSE. Одна реализует n:n, а другая m:n. Кроме того у них совершенно разный codebase, а значит свои плюсы, минусы и баги. Какая библиотека исользовалась в этих тестах не понятно.