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

[sanek1978]

Конфиги снимались в конце тестов, поэтому попал конфиг собранный для траблшутинга

Вы нити изнутри что ли изучали, чтобы понять почему БЗДя так тормозно пашет? Вы разбираетесь в KGDB?

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

[FromON]

Нашлись люди которые захотели помочь в этом, и я почему-то склонен им верить.

Можно поинтересоваться что эти люди сказали?

[Doktor]

Нда, FreeBSD что-то подкачала...
Просто для информации, можно еще прикрутить:
ACCEPT_FILTER_HTTP
http://www.freebsd.org/cgi/man.cgi?quer ... &sektion=9

И посмотреть что будет.

[SysR]

a_shats
По поводу "прибора которого нет" вопрос в том будет ли польза для Вас от того что я поделюсь с Вами своим опытом. По ядру могу сказать уже: Во первых maxusers это не пользователи нечто другая опцыя (непомню точно). Если ее установить в 0 то система САМА будет устанавливать значение. Во вторых где указана геометрия ФС. В третих где указан тип системной шины ы т д... можно перечислять есче много. Хочу отметить то что весь софт устанавливался не из портов а значит небыл собран с оптимальными опциями. Курите маны уважаемый. Вам только на виндах работать.

fs.file-max = 500000 # increases number of open file handles kernel allocates, default 1024
net.core.optmem_max = 10000000 #  maximum amount of option memory buffers, default 20480
net.core.rmem_default = 10000000 #  default recv socket buffer size, default 135168
net.core.rmem_max = 10000000 #  maximum recv socket buffer size, default 131071
net.core.wmem_default = 10000000 #  default send socket buffer size, default 135168
net.core.wmem_max = 10000000 #  maximum send socket buffer size, default 131071
net.ipv4.tcp_max_tw_buckets = 2000000 #  sets TCP time-wait buckets pool size, default 180000
net.ipv4.tcp_mem = 30000000 30000000 30000000 #  sets min/pressure/max TCP buffer space, default 392192 392704 393216
net.ipv4.tcp_rmem = 30000000 30000000 30000000 #  sets min/default/max TCP read buffer, default 4096 87380 174760
net.ipv4.tcp_wmem = 30000000 30000000 30000000 #  sets min/pressure/max TCP write buffer, default 4096 16384 131072
net.ipv4.tcp_timestamps = 0 #  turns TCP timestamps off, default 1
net.ipv4.tcp_max_syn_backlog = 12000 #  max number of remembered connection requests, default 1024
net.core.somaxconn = 10000 #  size of listen que for accepting new TCP connections, default 128
net.ipv4.ip_forward = 1 #  forward across subnets, default 0
net.core.netdev_max_backlog = 400000 #  maximum length of the input queues for the processors, default 300

Вот это вообще интересно "крутим но незнаем что". man sysctl(8). Вы сами хоть поняли что меняли?? Вообще нечего лазить "кривыми руками" туда где ничего не понимаешь.

По поводу тестов: Я не занимаюсь тестингом железа и ОС все о чем пишу прошел на собственном опыте. И желания делится знаниями с автором который ДАЖЕ НЕ ПОТРУДИЛСЯ ПОПРАВИТЬ правильно конфиг ядра под свое железо и УЖЕ сделал выводы у меня совсем нет. Исчите сами я только сказал свое ИМХО.

З.Ы. Очень похоже на заказную статью.

net.inet.tcp.delayed_ack=0
net.local.stream.recvspace=65535
net.local.stream.sendspace=65535
net.inet.tcp.sendspace=131072
net.inet.tcp.recvspace=131072

Вот кусок моего sysctl.conf что касается сети.

[opolzen]

В принципе, дебаг не столь критичен.
Подозреваю, что просто не была увеличена переменная kern.ipc.somaxconn, которая по умолчанию равна 128
вырезка из man 7 tuning :
The kern.ipc.somaxconn sysctl limits the size of the listen queue for accepting new TCP connections.  The default value of 128 is typically too low for robust handling of new connections in a heavily loaded web server environment.  For such environments, we recommend increasing this value to 1024 or higher.  The service daemon may itself  limit the listen queue size (e.g. sendmail(8), apache) but will often have a directive in its configuration file to adjust the queue size up.  Larger listen queues also do a better job of fending off denial of service attacks.

[a_shats]

По поводу "прибора которого нет" вопрос в том будет ли польза для Вас от того что я поделюсь с Вами своим опытом. По ядру могу сказать уже: Во первых maxusers это не пользователи нечто другая опцыя (непомню точно). Если ее установить в 0 то система САМА будет устанавливать значение. Во вторых где указана геометрия ФС. В третих где указан тип системной шины ы т д... можно перечислять есче много. Хочу отметить то что весь софт устанавливался не из портов а значит небыл собран с оптимальными опциями. Курите маны уважаемый. Вам только на виндах работать.

Уважаемый. Вы статью читали  ? Или только до конфига ядра BSD добрались ?

Вариантов два:
это нормально для FreeBSD и она действительно плохо масштабируется на большое количество процессоров
что-то не было учтено при компиляции ПО и ядра.

"Не читал -  но осуждаю" (с)  :down:

Ко всем уважаемым участникам конференции, читающим данную тему:
Всем, кто предлагает (без демонстрации пальцев) конкретные вещи по улучшению методики/конфигов/прочего - наша (Trinity Solutions и автора статьи) благодарность.
Желание "опустить" какую бы то ни было ОС не являлось целью написания данной статьи.
С другой стороны, надеюсь Вы поймете мою и sanek1978 реакцию на распальцовки.

[a_shats]

Есть еще соображение по конфигу ядра под BSD : я не уверен, что предлагаемый тюнинг даст производительность В РАЗЫ больше, чем в данном тестировании. Действительно, 20-30% прироста от тонкого тюнинга вряд ли "спасут" результаты BSD.
Тем не менее, когда под руками вновь окажется аналогичное железо (где-то в течение месяца ожидается) - потестим с учетом поправок, которые предложат в данной ветке. Собственно, в том числе предлагаю обсудить и это.

[tester2]

Предложение ушло на мыло

И мне продублируйте плиз.

[tester2]

Пробовали еще тестировать Вынь, ее результатов тут вообще нет.

Почему? Интересно посмотреть.

[funkblaster]

Я так понял фря использовалась stable. Может быть стоило всё-таки использовать шестой релиз?

[smb-]

Я так понял фря использовалась stable. Может быть стоило всё-таки использовать шестой релиз?

Эм, вы хоть о чем?Текущая stable-ветвь - шестая....Из статьи:

В тестировании приняли участие:
FreeBSD 6.0 STABLE AMD64

Тем не менее, когда под руками вновь окажется аналогичное железо (где-то в течение месяца ожидается) - потестим с учетом поправок, которые предложат в данной ветке. Собственно, в том числе предлагаю обсудить и это.

opolzen прав, кстати...что-нибудь навроде
"#sysctl -w kern.ipc.somaxconn=1024" могло бы прибавить bsd шустрости, причем во всех тестах - больше коннектов держалось бы в очереди в ядре...

2SysR
maxusers - довольно хитрая опция, грубо - отвечает за количество одновременных коннектов/запросов к системе и основываясь на указанном числе ОС выделит соответствующее количество mbuf-ов и всего прочего.....Впрочем, параметр непростой и лучше ставить действительно ставить 0

[SysR]

Всем, кто предлагает (без демонстрации пальцев) конкретные вещи по улучшению методики/конфигов/прочего - наша (Trinity Solutions и автора статьи) благодарность.
С другой стороны, надеюсь Вы поймете мою и sanek1978 реакцию на распальцовки.

"Пальцы" вы уже продемонстрировали тем что показали какая вы НЕКОМПЕТЕНТНАЯ фирма по вопросах тестов ИМХО не умеешь не берись.

Было бы желание читать:
http://www.opennet.ru/tips/info/847.shtml
http://www.opennet.ru/base/net/router_notes.txt.html
http://www.opennet.ru/base/sys/bsd_mysql_tune.txt.html

http://www.opennet.ru/search.shtml?excl ... s=bsd+tune

2SysR
maxusers - довольно хитрая опция, грубо - отвечает за количество одновременных коннектов/запросов к системе и основываясь на указанном числе ОС выделит соответствующее количество mbuf-ов и всего прочего.....Впрочем, параметр непростой и лучше ставить действительно ставить 0

[gs]

Крутой Вы наш, мы преклоняемся перед Вашими познаниями. Но автор по моему вполне корректно написал свои соображения по поводу фри, на что Вам уже на раз указали. Мы и автор совсем не объявляем себя крутыми, мы просто сделали полезный тест. Забесплатно между прочим (а оборудования в нем задействовано не самое дешевое, да и время денег стоит). Часть тестов не удалась, о чем и сказали. Часть - удалась. В чем проблема? Хотите показаться самым умным? Сорри, но письками меряться - удел первоклассников.

[gs]

Со стороны автора была мысль повторить тесты фри на машине попроще (например двухпроцессорном двуядернике, которые чаще пробегают) в старом конфиге и в затюненном. Желающие могут присоединиться в московском офисе (как состыкуемся). На общественных началах - регарды будут отражены в статье.

[SysR]

Крутой Вы наш, мы преклоняемся перед Вашими познаниями. Но автор по моему вполне корректно написал свои соображения по поводу фри, на что Вам уже на раз указали. Мы и автор совсем не объявляем себя крутыми, мы просто сделали полезный тест. Забесплатно между прочим (а оборудования в нем задействовано не самое дешевое, да и время денег стоит). Часть тестов не удалась, о чем и сказали. Часть - удалась. В чем проблема? Хотите показаться самым умным? Сорри, но письками меряться - удел первоклассников.

Вы этот тест называете полезным?? Полезный тест это когда из железа ОС выжимает все что может, это точно не ваш случай. Как можно тестить то про что ты даже ЗЕЛЕНОГО понятия не имеешь??? Сначала изучи что тестишь, а потом пиши.
Я высказал свое мнение, возможно в несколько резкой форме но сказал то что хотел сказать.