Тестирования Apache,PHP, MySQL на FreeBSD/Linux/Solaris

> root@student8:/ # nslookup trinity.su ;; connection timed out; no servers could be reached

А чо ты хотел, ведь тестирование прямо там и проводятся.

>Заблуждение. Она сама по себе, хотя папа у нее делал VAX VMS. Редкостная дрянь, кстати.

Да нет, OS/2 v2 - это общий предок третей полуоси и третей NT. Собственно и разделение произошло из-за того что микросовт рассорился и ибм.

> Без обид, ребята, но по вашим высказываниям похоже, что вы очень хотели победы Соляриса, что не замедлило сказаться на результах :)

Не угадал, клиент там выбрал фрю. Со словами "я ее лучше знаю", может он и прав....

А почему нет данных про примерное время отклика FreeBSD при 1024 процессах? Понятно, что всё плохо, но интересно знать насколько плохо.

>> под линуксом надо было попробовать разные планировщики (коих в ядре 2.6 - 4 штуки)

> ... и в солярке 5, итого 9 итераций, тогда бы статьи вообще не было.

под линукс достаточно было 2х, думаю cqf (обычно по умолчанию) & Deadline

описание есть на http://www.rhd.ru/docs/articles/schedulers/

А чего сайт-то не грузится?

Третья НТ и четвертая НТ - совсем разные вещи. Да, и полуосью как предком тоже гордиться сложно.

>Без обид, ребята, но по вашим высказываниям похоже, что вы очень хотели победы Соляриса, что не замедлило сказаться на результах :)

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

Хочешь сказать, что в четвертой совсем нет кода из третей? Не верю. Да, они серьезно изменили архитектуру, но с нуля они AFAIK не переписывали. А гордиться да, смысла нет.

А вот еще такой вопрос: а этот SLES 9.2 Up3, он какого времени выпуска?

makeoptions DEBUG=-g

все. дальше даже не глядел.

>makeoptions DEBUG=-g
>
>все. дальше даже не глядел.

чукча не читатель, чукча писатель?

> все. дальше даже не глядел.

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

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

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

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

Вопросы по фре: 1. options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS # Pseudo-filesystem framework options COMPAT_IA32 # Compatible with i386 binaries options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options COMPAT_FREEBSD5 # Compatible with FreeBSD5 options COMPAT_LINUX32 # Compatible with i386 linux binaries options LINPROCFS # Cannot be a module yet. Это всё убрать - производительности это точно не добавляет.

2. options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions Как и это.

3. А где POLLING? HZ? (О разделяемой памяти уже сказали).

4. sysctl (хотя уже и упоминалось) требуют более тщательного тюнинга для достижения максимальной производительности. Курим до просветления: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/configtuning-kernel... Чего стоит только одна фраза: "The kern.ipc.somaxconn sysctl variable 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, it is recommended to increase this value to 1024 or higher."

Вывод один: почти нетюненная фря сливает серверным операционным системам из коробки.

Другие вопросы: 1. Почему Apache 1.3.x, а не 2.0.5x? Время не стоит на месте... 2. Конфиги апача, мускула и пхп одинаковые на всех системах или дефайлтные из адаптированных для ОС дистрибутивов? 3. Глупый вопрос, но всё же: PHP модулем? :-)

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

Вынос MySQL на другую машину и гигабитный канал на нее - is right. И таки в разы уменьшает LA при высоких нагрузках. Как вариант (хотя бы) - вынос баз мускуля на другой физический носитель (типа дата апача лежит на /dev/sda1, а дата мускля - на /dev/sdb1), а лучше - еще и на другой контроллер.

Ядро все же желательно было ставить 2.6.14+... Почитай ченджлоги, сколько раз до 2.6.14 ломали треды... :-( Так что неудивительно.

Ну и оптимизации флагов компиляции ядра/апача/пхп/мускля вещь очень полезная... При хорошо подобранных опциях оптимизации можно выиграть 10-15%. Если хочешь, поищи на http://dev.mysql.com/ - там где-то есть инфа о source distribution с описанием типа "включени опции -g отнимает 10% производительности" и т. д.

nginx+fast cgi+perl+postgresql спасут от покупки 8ми процессорного сервера %)

Не думаю :), постгря сильно проигрывает мускулу на простых запросах

>Совершенно согласен. Посвежее ядро никак ?

C чем согласен то ептыть? Соляра тоже не невада была. Или нужно на промышленную систему ядро с кенл.орг ставить или суся+сп3 не промышленная система?

>Нет. Железо уже уехало. Я не думаю что кардинально результаты поменяются.

Оно может и поменяются (даже наверняка) ибо недавно ( если не ошибаюсь где то между 2.6.15 и 2.6.16 ) много перелопатили на тему синхронизации да и http://lwn.net/Articles/174128/ на тему "RCU and open file accounting" - выплыло при портировании на ниагару ... узких мест еще полно. Однако если уж сравнивать, так сравнивать промышленные системы, а не полуфабрикаты.

SLES SLESOом, а RHEL тоже посмотреть хотелось бы...

>Без обид, ребята, но по вашим высказываниям похоже, что вы очень хотели победы Соляриса, что не замедлило сказаться на результах :)

Результаты ожидаемы и логичны. Соляра на SMP десятилетия. Линукс на SMP > 4 процов массово не используется, поэтому масса узких мест ( порт на ниагару - яркий пример). Фря еще не избавилась от BKL - о какой масштабируемости может идти речь?

> Результаты ожидаемы и логичны. Соляра на SMP десятилетия. Линукс на SMP > 4 процов массово не используется, поэтому масса узких мест ( порт на ниагару - яркий пример). Фря еще не избавилась от BKL - о какой масштабируемости может идти речь?

Все, конечно, хорошо, но SMP у Линукса должен быть более чем: многие крупнейшие SMP системы из top-100 на Linux.

>Все, конечно, хорошо, но SMP у Линукса должен быть более чем: многие крупнейшие SMP системы из top-100 на Linux.

Посмотри на ссылку, которую я дал выше. Вот например еще http://lwn.net/Articles/175787/ - проблемы с планировщиком - там вот такая интересная фраза есть

Mike found that, on a system with a heavily-loaded Apache server running, tasks could find themselves starved for long periods of time; it seems that the starvation-avoidance logic was not working right. The problem turned out to be in the wakeup code. That code was always putting freshly-awakened processes onto the active array, regardless of what was going on elsewhere in the system. With a large number of server processes being continually awakened as requests came in, the scheduler was never able to switch arrays.

Это еще не исправлено в 2.6.16. К сожалению немогу найти статью, о других проблемах с масштабируемостью на SMP обнаруженных сосвсем недавно ... Так что ...

>Афаик, свое. Думаю, Linux бы помер от такого количества нативных тредов :)

Вот, собственно, потому и интересуюсь :) Хотя интерес, скорее, теоретический. Вряд ли мы L2-эмулятор на Erlang когда-то соберёмся переносить. Будем бороться с глюками в Java :)

> многие крупнейшие SMP системы из top-100 на Linux.

В top 100 КЛАСТЕРЫ ! КЛАСТЕРЫ, ламиры пазорные.

Дурацкий вопрос. А чем треды нэйтивные лучше, если они во фре сто лет как, а clone из линкса всё равно их рвёт?

кто там тупит по поводу "старья" 2.6.5?

для тормозов - это отдельная энтерпрайз ветка 2.6 ядра от SuSE
2.6.5 это чисто номинально, там много вещей и из 2.1x.x например бэкпорты, а много вообще униикальных....

Эти ядро - лучше что я встречал когда-либо, работают максимально стабильно и быстро.

Кстати SLES9SP3 тоже тюнить можно/надо - можно заметно поднять скорость сети и тд

Если честно, то SLES порвет FreeBSD почти во всех аспектах - сами тестили тоже.

уточнение - бэкпорты из 2.6.1x и тд ;)

> В top 100 КЛАСТЕРЫ ! КЛАСТЕРЫ, ламиры пазорные.

Да,да, ошибся. А что, в top500 не осталось SMP?

Я тут покопался, но навскидку не нашел.

> кто там тупит по поводу "старья" 2.6.5?

> для тормозов - это отдельная энтерпрайз ветка 2.6 ядра от SuSE 2.6.5 это чисто номинально, там много вещей и из 2.1x.x например бэкпорты, а много вообще униикальных....

Поосторожнее в выражениях, не борзеем.

А по теме: потому и интересно было бы сравнить еще систему от RedHat, бо они тоже нехило патчат ванильные ядра.

Интересно было бы посмотреть на Windows 2003 в тестах. Как думаете какое место занял бы?

...смотря кто тест закажет

Повторюсь конечно, но оно того стоит.

это каким же ламо надо быть, чтобы тетстировать БСД с вклученным дебагом?
...
makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols
...

и вот это:


# Workarounds for some known-to-be-broken chipsets (nVidia nForce3-Pro150)
#!device atpic # 8259A compatability

=/

нет слов, одни выражения.... тюнер хренов.

хорошо посмеялся. это же каким ламо надо быть, чтобы ожидать от "добавления debuginfo" падения производительности.

>freebsd хорошая, удобная и гибкая система, но по сравнению с линуксом тормознутая

я надеюсь тебе не надо об'яснять кто здесь понастоящему тормоз? ;)

Ок, дебагинфо может толко на скорость сборки ядра и влияет, но что по поводу apic?

Тоже смешно?

для здорового смеха достаточно и -g

Это просто маркетоидные понты, не имеющие почти ничего общего с ядром.

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

Но их не постят. Предпочитают изобретать велосипеды самостоятельно (а те самые дырки в ядрах все-равно закрываются в следующих версиях - зачастую более эффективными алгоритмами).

Я не против форков ядра. Я против попыток навязать свою значимость всякими конторами типа Novell.

У многих типов дистров (и я не только о несчастном SLES - RHES ничем не лучше) есть огромный минус: эти дистры ничем не отличаются от наркотика.
Дело в том, что современные дистры используют хидеры того ядра, с которым были собраны glibc... Соответственно, возникает коллизия: софт, собранный с хидерами от ядер более новых, чем ядро при котором собирали glibc, может попросту не заработать. А может проглючить и форматнуть винт ;-).
Вот откуда появились "лучше что я встречал когда-либо, работают максимально стабильно и быстро". Это _НЕ_ ядро. Это _НЕ_ хидеры ядра (они-то как раз остаются дефолтными). Это даже не патчи, а "обходные маневры" в коде, вместо изменения самого кода на предмет исключения глюков.
Это именно то, что делает макросакс, когда рекламирует "новый, суперзащищенный и быстрый сервиспак номер ХХХ".

Добавление дебагинфо в любом случае подразумевает падение производительности. Попросту потому, что нужно иметь некоторое количество ОЗУ для сохранения дебагинфо и дополнительное место в ОЗУ на собственно сам код дебагинфо (которое можно было бы потратить на дисковый кеш, например), нужно выполнять излишние обращения к ОЗУ на предмет сохранения состояния (а это очень немаленькое время простоя процессора), нужно в конце-концов выполнять дополнительный к непосредственно самому коду приложения код дебагинфо... В общем, как сказано где-то в недрах dev.mysql.com, добавление опции -g к компилятору означает потерю 10% производительности.

Или, может быть, имелось в виду:
"это же каким ламо надо быть, чтобы ожидать от "добавления debuginfo" ПОВЫШЕНИЯ производительности"?

> В общем, как сказано где-то в недрах dev.mysql.com, добавление опции -g к компилятору означает потерю 10% производительности.

На предыдущей странице говорилось, что -g там изначально не было, вот цитата: "> makeoptions DEBUG=-g Сорри, в тестах этого не было. Конфиги собирал в конце, а с фрей прыгали долго, в т.ч. и debug для этого включали.".

-g есть много где...
/usr/src/linux/Makefile :-)

погрепай любой configure скрипт на предмет -g...

:-)

> нужно в конце-концов выполнять дополнительный к непосредственно самому коду приложения код дебагинфо...

LOL. код дебагинфо ... держите меня семеро! пацтулом!

Не берусь утверждать с полной уверенностью, но дебаг инфо не должна замедлиать работу программы. Она по идее не должна загружатся в ОЗУ, а остается в ЕЛФе. Оттуда ее и берет дебугер, по мере необходимости. Да и на генерацию кода, -г не должен влиять. Все это теоретически, при реализации могли, конечно, нахомутать разного.

> А вот еще такой вопрос: а этот SLES 9.2 Up3, он какого времени выпуска?

сам sles9 - лето 2004, SP3 - конец января 2006

> Все, конечно, хорошо, но SMP у Линукса должен быть более чем: многие крупнейшие SMP системы из top-100 на Linux.

это кластеры. А к каждой ноде не более 4-8 процессоров

1) Я так понял не устроили плохие результаты во Фре, так бы было все спокойно. Если будет время, то попробую потестить с рекомендациями которые предостаивли люди с конструктивным подходом.

2) Вчера тестил Т2000 о 4-ех ядрах по гигагерцу. Результаты пока не выдаю, т.к. на той машине почему-то горит алерт на PCI-E. У кого есть 8-ми ядреная ниагара на ОДИН вечер? Сделайте полезно обществу, поделитесь :)

>Вывод один: почти нетюненная фря сливает серверным операционным системам из коробки.

Она не сливает, она как следует из теста, равномерно держит нагрузку.

>Другие вопросы: 1. Почему Apache 1.3.x, а не 2.0.5x? Время не стоит на месте... 2. Конфиги апача, мускула и пхп одинаковые на всех системах или дефайлтные из адаптированных для ОС дистрибутивов? 3. Глупый вопрос, но всё же: PHP модулем? :-)

Неправильный подход. nginx+php/FastCGI. Будет быстрее в разы.