| 1.1, Никита (??), 16:28, 30/03/2006 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
Мне не понятно, почему использовалась еще сырая FreeBSD 6. Да и вообще, старнное ощущение после прочтения, автор, по-моему, не особо отличается наличием обширных знаний... | | |
| |
| 2.3, uldus (ok), 16:33, 30/03/2006 [^] [^^] [^^^] [ответить]
| +/– |
>Мне не понятно, почему использовалась еще сырая FreeBSD 6. Да и вообще,
>старнное ощущение после прочтения, автор, по-моему, не особо отличается наличием обширных
>знаний...
Не более сырая, чем FreeBSD 5. И тюнил ее http://people.freebsd.org/~jkoshy Так что вы погорячились толком не разобравшись. | | |
| |
| |
| |
| 5.10, ad (??), 17:46, 30/03/2006 [^] [^^] [^^^] [ответить]
| +/– | |
>>А не пробовал использовать вместо libthread libthr?
> Где вы libthread увидели ? там libpthread. Не пробовал использовать вместо libthr?
Банальная очепятка :-)
Хотя, конечно, при том бардаке с библиотеками тридов в FreeBSD каждая буква важна.
Вопрос был к автору статьи: проводились ли измерения mysql и apache скомпилеными с libthr?
И пробовали сравнивать отдачу статики через тот же апач (возможно проблема была не только в mysql)? Хотя, при наличии отличных результатов у Соляры и Линукса, автору наверное уже не интересно дальше с фрёй возится.
У меня в /etc/make.conf:
PTHREAD_LIBS=-lthr
.if ${.CURDIR:N*/ports/databases/mysql41-server} == ""
BATCH=yes
BUILD_OPTIMIZED=yes
WITH_CHARSET=cp1251
WITH_XCHARSET="ascii cp866 greek koi8r koi8u latin1 latin2 latin5 latin7 ucs2 utf8"
WITH_OPENSSL=yes
WITH_COLLATION=cp1251_ukrainian_ci
.endif
Замеров скорости не проводил, но работает стабильно.
| | |
|
|
|
|
| 1.2, Аноним (-), 16:31, 30/03/2006 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
все правильно - по-моему субьективному мнению - буржуи немного не ту политику избрали - гоняться -6,7, - ты сделай 5,0 да так что б комар носа не подточил -
спешка нужна при ловли блох и деверов - IMHO все что после 4 идет - туфта - а не БЗД!!! | | |
| |
| 2.4, universite (ok), 16:51, 30/03/2006 [^] [^^] [^^^] [ответить]
| +/– |
>спешка нужна при ловли блох и деверов - IMHO все что
>после 4 идет - туфта - а не БЗД!!!
6-ка очень себя неплохо показывает на продакшен серверах.
Я специально перехожу с 4.11 на 6.1.
| | |
| |
| 3.24, Dyr (?), 01:25, 31/03/2006 [^] [^^] [^^^] [ответить]
| +/– |
 Как это ни прискорбно, но я замечаю обратное. Несмотря на то, что скорость дисковой подсистемы действительно повысили, по сравнению с пятёркой, работа Apache и Proftpd вызывает серьёзные нарекания. Я так и не смог, например, в тестовых условиях заставлять отдавать их файлы на скорости выше двух с копейками Мбайт/с. Причём если ходить ЧЕРЕЗ сервер, качается всё на ура. Неоднократно встречал упоминания, что Апач у народа под шестёркой медленно работает. =(
P.S. По MySQL. Тестил встроенным sql-bench, получил такие результаты.
1. FreeBSD 5.4, MySQL 4.0.16, P4 3,0GHz, без HT:
>Totals per operation:
>Operation seconds usr sys cpu tests
>TOTALS 3359.00 379.77 300.78 680.49 3225950
2. FreeBSD 6.0, MySQL 5.0.18, P4 3,00GHz, включен HT:
>Totals per operation:
>Operation seconds usr sys cpu tests
>TOTALS 2867.00 292.29 89.34 381.58 3425950
3. FreeBSD 6.0, MySQL 5.0.18, AMD 64 X2 3800+ (два ядра@2,00GHz):
Лень перегружаться и смотреть, но seconds было в районе от 1500 до 1600.
Такие дела. | | |
| |
| 4.29, smb (?), 08:21, 31/03/2006 [^] [^^] [^^^] [ответить]
| +/– |
>Как это ни прискорбно, но я замечаю обратное. Несмотря на то, что
>скорость дисковой подсистемы действительно повысили, по сравнению с пятёркой, работа Apache
>и Proftpd вызывает серьёзные нарекания. Я так и не смог, например,
>в тестовых условиях заставлять отдавать их файлы на скорости выше двух
>с копейками Мбайт/с. Причём если ходить ЧЕРЕЗ сервер, качается всё на
>ура. Неоднократно встречал упоминания, что Апач у народа под шестёркой медленно
>работает. =(
>
>P.S. По MySQL. Тестил встроенным sql-bench, получил такие результаты.
>1. FreeBSD 5.4, MySQL 4.0.16, P4 3,0GHz, без HT:
>>Totals per operation:
>>Operation seconds usr sys cpu tests
>>TOTALS 3359.00 379.77 300.78 680.49 3225950
>
>2. FreeBSD 6.0, MySQL 5.0.18, P4 3,00GHz, включен HT:
>>Totals per operation:
>>Operation seconds usr sys cpu tests
>>TOTALS 2867.00 292.29 89.34 381.58 3425950
>
>3. FreeBSD 6.0, MySQL 5.0.18, AMD 64 X2 3800+ (два ядра@2,00GHz):
>Лень перегружаться и смотреть, но seconds было в районе от 1500 до
>1600.
>
>Такие дела.
Встроенный в Mysql benchmark не предназначен для реального тестирования, он однопоточный...Лучше использовать какой-нибудь sysbench, там получаются классные картины как проседает мускул при увеличении кол-ва потоков 2->4->8->16->32->64....=)
| | |
| |
| 5.32, Dyr (?), 12:35, 31/03/2006 [^] [^^] [^^^] [ответить]
| +/– |
>Встроенный в Mysql benchmark не предназначен для реального тестирования, он однопоточный
Вот как? Я, честно говоря, не знал. В таком случае, кстати, отрыв AMD64 получается особенно впечатляющим.
>...Лучше использовать какой-нибудь sysbench, там получаются классные картины как проседает мускул при увеличении кол-ва потоков 2->4->8->16->32->64....=)
Хорошо, попробую. Может, сразу подскажете ещё, с какими параметрами его лучше запускать?
| | |
| |
| 6.48, smb (?), 12:10, 01/04/2006 [^] [^^] [^^^] [ответить]
| +/– |
/offtop:
Нашел старый кусок скрипта....вот....
sysbench --num-threads=1 --max-time=60 --test=oltp --mysql-user=<mysql_user> --mysql-db=<mysql_db> --oltp-read-only=on cleanup > cleanup
sysbench --num-threads=1 --max-time=$MT --test=oltp --mysql-user=<mysql_user> --mysql-db=<mysql_db> --oltp-read-only=on prepare > prepare
for a in "on" "off"; do
for t in 1 2 4 8 16 32 64 128 256 512 1024; do
echo "Now testing with --oltp-read-only=$a and --num-threads=$t"
sysbench --max-requests=5000000 --num-threads=$t --max-time=60 --test=oltp --mysql-user=<mysql_user> --mysql-db=<mysql_db> --oltp-read-only=$a run > bench_${a}_${t}
done;
done;
//offtop.
| | |
|
|
| 4.43, ad (??), 20:23, 31/03/2006 [^] [^^] [^^^] [ответить]
| +/– |
>Как это ни прискорбно, но я замечаю обратное. Несмотря на то, что
>скорость дисковой подсистемы действительно повысили, по сравнению с пятёркой, работа Apache
>и Proftpd вызывает серьёзные нарекания. Я так и не смог, например,
>в тестовых условиях заставлять отдавать их файлы на скорости выше двух
>с копейками Мбайт/с. Причём если ходить ЧЕРЕЗ сервер, качается всё на
>ура. Неоднократно встречал упоминания, что Апач у народа под шестёркой медленно
>работает. =(
Странно, у меня что апач (2.0.55), что ftp (штатный ftpd) спокойно выдают 9.6 Mбайт/с (100 Мбитный езер). Система 6.0-STABLE от 16 января, вобщем-то вполне обычная железяка, SCSI нет,
raid'ов тоже, винт так вообще Samsung, правда SATA. | | |
|
|
|
| 1.8, Аноним (-), 17:38, 30/03/2006 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
интересно, а какому количеству пользователей соответствует 1024 потока одновременно?
То есть если к практике - сколько посетителей в час надо для такой нагрузки и сколько просмотров страниц/запросов? | | |
| |
| 2.13, smb (?), 18:54, 30/03/2006 [^] [^^] [^^^] [ответить]
| +/– |
Еще как сказывается...Да и вообще там ядро ни к черту....IPI_PREEMPTION и APIC куда-то дели, а еще удивляются почему не все загружено ;)
Собственно, см. ветку форума на trinity.tu.... | | |
| |
| 3.17, Sun (??), 19:48, 30/03/2006 [^] [^^] [^^^] [ответить]
| +/– |
options IPI_PREEMPTION
device atpic # Optional legacy pic support
device mptable # Optional MPSPEC mptable support
| | |
|
| 2.15, Sun (??), 19:24, 30/03/2006 [^] [^^] [^^^] [ответить]
| +/– | |
не вижу там ничего типа
options MAXSSIZ=(1024UL*1024*1024)
options DFLDSIZ=(1024UL*1024*1024)
с несколько увеличенными показателями
также не мешало бы выложить сообщения ядра при загрузке. Итересно ведь посмотреть как это все железо видит система. | | |
|
| |
| 2.16, smb (?), 19:48, 30/03/2006 [^] [^^] [^^^] [ответить]
| +/– |
Какая разница чем собирать?Мы же сравниваем оси между собой, а не компиляторы...
Sun Studio нативная вещь для Solaris, и насколько я знаю только недавно был портирован под linux, а в его существовании под freebsd я вообще сомневаюсь :) | | |
|
| 1.18, pavel (??), 22:50, 30/03/2006 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
Просто родной компилятор пытается использовать все известные ему преимущества ОС, вследствие этого лучше компилровать софт именно им. | | |
| |
| 2.20, smb (?), 23:21, 30/03/2006 [^] [^^] [^^^] [ответить]
| +/– |
Еще раз - условия тестирования должны быть _одинаковые_ для всех ОС - ибо мы идейно меряем производительность планировщика при наличии кучки процессоров, а не крутость компиляторов. Поэтому - gcc 3.4.4 =)
Другое дело, в реальной жизни естественно стоит юзать Sun Studio для сборки ПО в Solaris =) | | |
|
| 1.19, pavel (??), 22:56, 30/03/2006 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
IMHO, на сегодня Solaris 10 01/06 реальный конкурент Red Hat и Suse Linux, не говоря уж про FreeBSD, на промышленных x86 совместимых (особенно 64 bit) системах, как это не обидно сторонникам Free и прочих BSD.Да, у этих систем большая армия ФАНАТОВ, но доля их, опять таки IMHO, будет постоянно снижаться. | | |
| 1.21, Michael Shigorin (?), 23:30, 30/03/2006 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 "Ну вот" (c)
Как это ни смешно, но результаты (при известном) довольно предсказуемые даже, вот только не ожидал, что на 3nity.ru набежит *такая* толка красноглазых студентов-бсдишников (года три такой не встречал), которые не въехали даже, какой случай для отладки был предоставлен фрёвым ядерщикам в процессе тестов. То, на чём линуксы оттачивают в штатном порядке по всей планете, в кои-то веки попалось. Процессы -- это вам не байтики гонять.
http://www.3nity.ru/viewtopic.htm?t=6383&postdays=0&postorder=asc&start=30#38
http://www.3nity.ru/viewtopic.htm?t=6383&postdays=0&postorder=asc&start=45
SLES с соляркой выступили как промышленные решения, что очень ярко демонстрируется и некатастрофическим влиянием тюнинга, и небольшим его объёмом до того, чтобы потащило что надо. Фря -- где-то как тот линукс, который на всех перекрёстках поносили за то, что вокруг надо попрыгать (её тогда упоминаемой на всех перекрёстках, впрочем, и не помню).
Ещё из подумавшегося... как и намекает автор теста, фронтэнд (вроде того же nginx) был бы весьма симпатичен в качестве сдвигалки баланса нагрузки и на самом деле приближения её к тому, как (насколько знаю) и организовываются высоконагруженные динамические веб-серверы (у нас в ту же степь, но говорить о "высокой" нагрузке обычно не приходится -- слэшдоттинг как-то сдерживал скорее провайдерский шейпер в два мегабита скорее, чем остальное).
И ещё к слову для тех, кому линуксовый софт надо покрутить в руках на N процессорах -- могу запустить в vserver на 4*Xeon 550/2M. Сейчас там 2.4 и, соответственно, без NPTL.
Ergo: удачи нам всем находить нужный софт под свои задачи и нужные задачи под свой софт! | | |
| |
| 2.40, Michael Shigorin (?), 17:36, 31/03/2006 [^] [^^] [^^^] [ответить]
| +/– |
>Жаль, что при тестировании производительности MySQL на FreeBSD не использовались рекомендации отсюда:
>http://wikitest.freebsd.org/moin.cgi/MySQL
Нескромный вопрос -- как думаете, если линукс заточить при участии kernel developers с теми же времязатратами, что получится? А если mysql и прочее на нём ещё потюнить даже без пересборок? А если поверх ещё nginx набросить?..
Веб-сервер в нашем веке обычно не является подкованной блохой всё-таки. | | |
| |
| 3.42, ad (??), 20:16, 31/03/2006 [^] [^^] [^^^] [ответить]
| +/– |
Если линукс заточить при участии kernel developers то получится ровно тоже, что и сейчас, потому что девелоперы MySQL плотно взаимодействуют с kernel developers Linux'а.
Тут вопрос в другом, FreeBSD поставляется с незаточеной конфигурацией :-( Это есть крупный (очень крупный) недостаток, приходится администратору делать то, что уже за него сделали в RedHat или Novell, если бы он использовал Линукс.
Ребята, проводившие тестирование, не слишком разбираются в аспектах системы, иначе результаты получились бы несколько другими. Думаю, все же проблема была далеко не в mysql, которому уделили такую кучу внимания. Судя по кускам конфигурации, представленым на форуме их сайта, если бы они свиснули здесь, о том что нуждаются в консультациях по тюнингу системы, то они бы не затратили на возню с явно незнакомой системой 3 недели. | | |
| |
| |
| 5.45, terver (?), 21:14, 31/03/2006 [^] [^^] [^^^] [ответить]
| +/– | |
> если кто недочитал тамошнее обсуждение, то опубликованный фрёвый конфиг был снят с последней стадии системы, когда jkoshy@ уже её раскладывал по столу
Разъясните, пожалуйста, что значит "раскладывал её по столу"? Вы имеете ввиду, что Koshy занимался дебагингом? Из Индии?
> Судя по тому, что народ поступил грамотнее и пнул разработчиков
Плохо пинал видимо, про такие вещи как IPI_PREEMPTION они бы вряд ли забыли :-( Пнули бы Роберта Ватсона, что ли :-) | | |
|
|
|
|
| 1.35, zuborg (?), 14:36, 31/03/2006 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
StartServers 200
MaxClients 150
отличная шутка, интересно как соляра сумела удержать низким время отклика при таких условиях ))
модули через mod_so лоадятся, это на продашн то сервере, мдя
mod_autoindex там очень кстати, наверное, как и куча других модулей
нету AcceptFilter On, ну это так, к слову
/etc/sysctl.conf надо полагать вообще не трогал никто, по крайней мере упоминания об этом я не нашел. А ведь фря по умолчанию оптимизирована как веб-клиент, а не веб-сервер.
в my.cnf нет query_cache_type= 1 , а зря
в общем, действительно комментариев по FreeBSD нет. | | |
| 1.36, Vanoha (?), 14:49, 31/03/2006 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Если внимательно посмотреть на результаты, то можно увидеть, что более 256 потоков - это эммуляция заведомо нерабочей ситуации.
Т.е. все результаты с большим количеством потоков можно не рассматривать.
Это следует из того, что при 256 потоках начинается деградация производительности на всех системах, поэтому обсуждать кто лучше работает в неработоспособной конфигурации - занятие для особо утонченных натур.
Поэтому выводs по тестам несколько другие:
1. В разумной конфигурации BSD не выдерживает никакой конкуренции с linux и Solaris.
2. При низкой нагрузке Linux ведет себя лучше остальных.
3. Более 256 потоков при любой ОС - плохая конфигурация (т.е. выходящая за рамки нормального рабочего режима).
4. За границей рабочего режима Solaris ведет себя устойчиво.
Кстати, Solaris подтвердил давно известные факты:
1. Малые накладные расходы при переключении между процессами
2. Умение хорошо работать при разных перегрузках (к слову - этим же славятся AIX и VMS)
Вообще, тест конечно слегка "натянутый", но тем не менее хотелось бы увидеть нечто похожее не на "форкающемся" Apache 1.3, а на 2.0, который нормально поддерживает threads.
Кстати, использованные тесты обычно применяются для определения границ работоспособности и оптимизации параметров систем.
| | |
| 1.37, Аноним (-), 15:12, 31/03/2006 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
кто мне скажет, это какого уровня проэкт должен быть, чтобы 256 потоков обслуживать?
Скольно народу в час/просмотров страниц? | | |
| |
| 2.38, zuborg (?), 15:41, 31/03/2006 [^] [^^] [^^^] [ответить]
| +/– |
несколько сотен тысяч посетителей в день
одна машина выдерживает от 100K до 1000K посетителей,
но это сильно зависит как от оптимизированности проекта,
так и от качества драйверов железа.
ЗЫ: иногда не хватает и MaxClients 1024, но это нечасто.
Причем никакой особенной деградации производительности. | | |
| |
| 3.49, zyxman (?), 06:53, 08/04/2006 [^] [^^] [^^^] [ответить]
| +/– |
>несколько сотен тысяч посетителей в день
>одна машина выдерживает от 100K до 1000K посетителей,
>но это сильно зависит как от оптимизированности проекта,
>так и от качества драйверов железа.
>
>ЗЫ: иногда не хватает и MaxClients 1024, но это нечасто.
>Причем никакой особенной деградации производительности.
если программеры так программят, что оно больше долей секунды тратит на рисование потенциально посещаемой странички - кому-то нужно руки рубить по самую голову, потому как ровнять уже поздно :(
у меня был опыт борьбы с одним таким, который сделал форум с хранением данных в mysql, при этом даже не понимая, как индексы создать - как только количество сообщений в базе превысило 10к, больше 30 человек в форуме не могло нормально присутствовать, а однажды зашли 50 и пришлось лавочку совсем закрыть..
Кстати, все это крутилось на слаквари, mysql 3.x, apache 1.3.x..
Потом даже была мысль сделать для сайта затычку, чтобы просто нельзя было одновременно из двух точек одну страницу открыть (в смысле чтобы открывалось новое соединение только после окончания обработки старого) - кстати достаточно просто реализовать с помощью mod_rewrite и одного скрипта с одной таблицей.
Просто большое количество открытых сокетов не опасно - сам работал с системой, где один прокси на фре 2.х на сквиде (без каки-то нестандартных настроек, кроме maxusers=32 в ядре) обслуживал несколько тысяч клиентов и было в нормальном состоянии открыто около 600 соединений - поэтому почти всегда есть смысл ставить реверсивный прокси.
Кстати, поищите, где-то в форумах рассказывали на чем рамблер жил несколько лет назад (всего один p2-450/512RAM) - просто тщательно настроен апач + аккуратно написаны скрипты + статику отдавали чем-то сверхлегким.
| | |
|
| 2.41, uldus (ok), 17:53, 31/03/2006 [^] [^^] [^^^] [ответить]
| +/– |
>кто мне скажет, это какого уровня проэкт должен быть, чтобы 256 потоков
>обслуживать?
Любой проект может с этим столкнуться, если ссылка на него появится в slashdot или хотябы на news.yandex/rambler.ru :-)
| | |
|
| 1.50, def (??), 20:11, 31/05/2006 [ответить] [﹢﹢﹢] [ · · · ] | +/– |  Использую FreeBSD больше 5 лет Постоянно занят оптимизацией связки mysql apache... большой текст свёрнут, показать | | |
| |
| 2.51, weldpua2008 (ok), 14:36, 22/10/2006 [^] [^^] [^^^] [ответить]
| +/– |
 >Использую FreeBSD больше 5 лет. Постоянно занят оптимизацией связки mysql/apache/php. Толька большая
>любовь к FreeBSD и уважение к команде разработчиков держит.
>
>Ловите мои тесты, делал 3 месяца назад, mysql 4.1.16 тогда была. Юзаю
>два года LINUXTHREADS. На больших нагрузках бывают сбои, система сейчас SMP
>(Intel).
у Меня вопрос - а что эти тесты показывают?
(только не пинать)
И как они позиционируют Себя в сравнени с тестами у топикстартера? | | |
|
|
