Apache,PHP, MySQL on FreeBSD/Linux/Solaris benchmark

[smb-]

Да не тестите вы MySQL supersmack-ом, он однопоточный, о чем черным по белому написано на mysql.com....Тестите каким-нибудь sysbench-ем, а то пользы от тестов - вот уж реально нет никакой, имхо...

А по фряхе - да, действительно, до версии ~ 5.2 все потоковые либы были userspace => один процесс <-> один CPU и полная бестолковость MySQL на Dual Xeon на freebsd 4.11 =)

[Stranger03]

Это не разница. Это не то, ради чего разумный человек откажется от любимой, стабильной, нужной, привычной (ненужное зачеркнуть) платформы.  :lol: Это не страшная разница, она только на тестах и видна. Вот если А быстрее Б (в КОРРЕКТНО равных условиях) хотя бы на 50-60% - тут да...

Не, поймите меня правильно, я сам Фрю знаю еще с 3-й ветки лет так уже и не помню сколько. Ее структура мне кажется эталоном любого юникса. Ни в одной системе, даже коммерческой, я не видел хотя бы похожую схему фришных портов. Но к сожалению подтверждается небольшой факт, что на любом коммерческом юниксе - линуксе сторонний тяжелый софт аля Оракл работает быстрее, вылизан лучше, заточен под него. Не даром практически все тяжелые задачи с Ораклом работают на Соляре, Аиксе, теперь вот на Сусе и Редхате. А Фря с ее надежностью, гибкостью и дружелюбностью к админу остается в своем рынке. ИМХО, надо повторить тест, пусть может не на таких серверах, попроще, но в одинаковых условиях. Разница будет не в пользу Фри, но не во столько раз.

[umanski]

Это не разница. Это не то, ради чего разумный человек откажется от любимой, стабильной, нужной, привычной (ненужное зачеркнуть) платформы.  :lol: Это не страшная разница, она только на тестах и видна. Вот если А быстрее Б (в КОРРЕКТНО равных условиях) хотя бы на 50-60% - тут да...

Не, поймите меня правильно, я сам Фрю знаю еще с 3-й ветки лет так уже и не помню сколько. Ее структура мне кажется эталоном любого юникса. Ни в одной системе, даже коммерческой, я не видел хотя бы похожую схему фришных портов. Но к сожалению подтверждается небольшой факт, что на любом коммерческом юниксе - линуксе сторонний тяжелый софт аля Оракл работает быстрее, вылизан лучше, заточен под него. Не даром практически все тяжелые задачи с Ораклом работают на Соляре, Аиксе, теперь вот на Сусе и Редхате. А Фря с ее надежностью, гибкостью и дружелюбностью к админу остается в своем рынке. ИМХО, надо повторить тест, пусть может не на таких серверах, попроще, но в одинаковых условиях. Разница будет не в пользу Фри, но не во столько раз.

Аллилуйя!!!!!!!!!!!!

За последнюю фразу респект. ИМЕННО об этом и речь! Будет более или менее объективная картина. Будет небольшая и рациональна объяснимая разница. А дальше каждый выбирает по себе. Для меня стабильность важнее скорости.

P.S. А я раньше, а я раньше! У меня на ФизФаке МГУ на суперсервере Intel 403E (i486DX33 переделан в i486DX2-66 Overdrive, SIMM FPM 72 pin true parity парами (!), насобирал 42MB ... в первый и последний раз в жизни видел SIMM 72 pin 2MB... 10 EISA слотов ... вентиллятор рядом с PSU 460W напоминал небольшую турбинку... Ирландия 1991 год) ... машина зверь ... поднимал из руин месяц, но результат обладал устойчивостью основательно заглубленного в землю танка... там у меня первой версии фряхи бегала 2.2.1 . Универсальный сервер (HTTP, FTP, Samba, ipfw, natd, named, sshd, Sendmail, etc., etc. ) как ни забавно - вполне справлялся со всем... только компилял немного по-дзеновски...  :D

[a_shats]

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

[umanski]

Зачем же до 2 раз? До 20-30% от силы  :twisted: Мечтать так мечтать.  :lol:

[Stranger03]

состоянии - времени столько нету. Поэтому давайте согласуем конфиг и оптимизации, подходящие по Вашему мнению, здесь.

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

[rdu]

Аллилуйя!!!!!!!!!!!!
За последнюю фразу респект. ИМЕННО об этом и речь! Будет более или менее объективная картина. Будет небольшая и рациональна объяснимая разница. А дальше каждый выбирает по себе. Для меня стабильность важнее скорости.

Стабильность и то что ты одну систему знаеш лучше другой, это разные вещи.
блин 20%,
ПРИМЕР

Приходит начальник и говорит:
- Я тут станок купил, деньги печатает, его нужно запрограммировать и настроить
Ты:
- Ок
Через 3 дня:
- Вот настроил, печатает $80000 в день
Начальник
- Погоди, у конкурента печатает $100000???
- А та, программа которую мы знаем лучше, умеет только $80000!!!
- Так, что мне повысить фонд ЗП вашего отдела на $2000 в месяц, и найти вместо тебя, того кто знает другую, и сможет печатать на 20% больше???
- ... (твой ответ, с учетом того, что у конкурента вполне нормально, уже давно печатаеться $100000)

[Stranger03]

Стабильность и то что ты одну систему знаеш лучше другой, это разные вещи.
блин 20%

Речь в этой ветке не про знания систем. Поверьте, практически каждый из присутсвующих в этом топике людей профи до мозга костей. Независимо от того, знает ли sanek1978 все системы досконально или нет, он постарался оптимизировать процесс теста и получить реальные результаты.
Но есть объективные причины, по которым та или иная ОСь показывает определенные результаты. От этого никуда не деться. Анекдот ИМХО здесь неуместен.
P.S. собственно поэтому советов по настройке Фри в топике немного. Надо бы мне самому собрать сие чудо, поковырять слегка...

[umanski]

Учитывая себестоимость станков, я - когда мне перестанет хватать 80 тыс. - замотивирую и поставлю второй станок и буду печатать 160 тыс., обслуживая их теми же силами и за ту же зарплату с тем же (минимальным) уровнем геморроя.

Это если продолжать аналогию.

P.S. Я и сам много анекдотов знаю. Тока это фсе фигня.  :lol:

[rdu]

Учитывая себестоимость станков, я - когда мне перестанет хватать 80 тыс. - замотивирую и поставлю второй станок и буду печатать 160 тыс., обслуживая их теми же силами и за ту же зарплату с тем же (минимальным) уровнем геморроя.

Еще один купить надо однако.

[gs]

На корпоративном рынке это часто проще, быстрее и дает гарантированный результат - что важнее всего.

[umanski]

Вот именно.

Нет ничего страшнее, чем в продакшн-системах "зоопарк разводить". Я именно это имел в виду, когда говорил о том, что на разницу в 20-30% вполне себе умные люди регулярно кладут с тройным прибором и чистой советью...

[smb-]

Пошарил в рассылке фряшной(freebsd.perfomance) - позавчера-вчера поднимали тему насчет dual-core opterons и их производительности (mysql), помусолили, потом появился некто Steven Hartland(committer, если не ошибаюсь, и довольно серъезный, подробнее инфы пока не нашел) и заявил, что лучше всего для mysql under FreeBSD_6 использовать такую вот связку

ULE + libthr + TSC + context_time.patch + cpu_acct_1.patch + cpu_acct_2.patch
The biggest increases coming from libthr ( thanks DavidXu ) and the ULE scheduler.

Код: Выделить всё

Adding these jumps from a baseline:
select_index    2000000 8       0       18624.60
to:
select_index    2000000 5       0       29942.10

Далее я привожу вырезки из его perf-тестов по шагам, так сказать:)
(1 = super-smack -d mysql select-key.smack 100 10000
2 = super-smack -d mysql select-key.smack 10 100000),
последняя строка статистики расшифровывается как: Query_type      num_queries     max_time        min_time        q_per_s)

Поехали.

== 4BSD + libpthread + ACPI-Fast ==
====================================
 1: connect: max=46ms  min=6ms avg= 25ms from 100 clients
 select_index    2000000 8       0       18624.60

 2: connect: max=5ms  min=0ms avg= 1ms from 10 clients
 select_index    2000000 0       0       23983.87
====================================


== 4BSD + libthr + ACPI-Fast  ==
====================================
 1: connect: max=107ms  min=2ms avg= 45ms from 100 clients
 select_index    2000000 13      0       22413.39

 2: connect: max=2ms  min=1ms avg= 1ms from 10 clients
 select_index    2000000 0       0       26841.07
====================================


== 4BSD + libthr + TSC ==
====================================
 1: connect: max=46ms  min=1ms avg= 21ms from 100 clients
 select_index    2000000 11      0       23428.03

 2: connect: max=2ms  min=0ms avg= 1ms from 10 clients
 select_index    2000000 0       0       26403.95
====================================


== ULE + libthr + TSC ==
====================================
 1: connect: max=41ms  min=0ms avg= 23ms from 100 clients
 select_index    2000000 5       0       28581.18

 2: connect: max=4ms  min=0ms avg= 1ms from 10 clients
 select_index    2000000 0       0       30128.44
====================================


== ULE + libthr + TSC + context_time.patch + cpu_acct_1.patch + cpu_acct_2.patch ==
====================================
 1: connect: max=27ms  min=0ms avg= 14ms from 100 clients
 select_index    2000000 5       0       29942.10

 2: connect: max=12ms  min=0ms avg= 4ms from 10 clients
 select_index    2000000 0       0       31057.52
====================================


== 4BSD + libthr + TSC + context_time.patch + cpu_acct_1.patch + cpu_acct_2.patch ==
====================================
 1: connect: max=54ms  min=20ms avg= 38ms from 100 clients
 select_index    2000000 9       0       24144.22

 2: connect: max=2ms  min=0ms avg= 1ms from 10 clients
 select_index    2000000 0       0       27073.46
====================================

Machine:
Dual 244, 2Gb running FreeBSD 6.1-PRERELEASE (i386)
Package install of mysql 4.0
Port install of super-smack

[Dyr]

Dual 244, 2Gb running FreeBSD 6.1-PRERELEASE (i386)
Package install of mysql 4.0
Port install of super-smack

Я что-то не понял, а что, теперь модно ставить на 64-битные процы x86 дистрибутивы? А какой глубокий смысл ставить бенчмарк из портов, но mysql (да ещё и 4.0) из паккаджей?

[umanski]

AFAIK it's not recommended...  :shock:  Хотя работать может, если с либами не будет проблем...