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

a_shats · Сообщение **a_shats** » 03 апр 2006, 10:01

Не совсем такую. В т.ч. и по этой причине результаты Windows не приводятся.

Сообщение gs » 03 апр 2006, 12:39

Санек, по поводу винды ты бы не делал таких категоричных утверждений. У нас немало внедрений тяжелых коммерческих СУБД на ней. В частности могу привести пример одного показательного клиента, где транзакционная база более 50ГБ с несколькими сотнями (300-500) операционисток вполне адекватно работает. Там же аналитическая база управления более 100ГБ. Так что в правильных руках оно вполне себе работает.

Terol · Сообщение **Terol** » 03 апр 2006, 14:03

a_shats писал(а):Не совсем такую. В т.ч. и по этой причине результаты Windows не приводятся.

Я кстати так и не получил ответ на свой вопрос http://www.3nity.ru/viewtopic.htm?p=38968#38968. Если честно тоже не совсем понимаю тест. Сравнивать Apache & MySQL под Windows с другими, при этом на приложениях, которые совсем под неё не заточены мне кажется по крайней мере странным. Если вы хотели показать как себя ведет ОС под такими нагрузками то уж точно не с этими приложениями.

sanek1978 · Сообщение **sanek1978** » 03 апр 2006, 19:55

gs писал(а):Санек, по поводу винды ты бы не делал таких категоричных утверждений.

Не онтносись уж совсем серьезно, я же там смайлик не зря поставил

gs писал(а):У нас немало внедрений тяжелых коммерческих СУБД на ней. В частности могу привести пример одного показательного клиента, где транзакционная база более 50ГБ с несколькими сотнями (300-500) операционисток вполне адекватно работает.

В качестве примера могу привести документооброт плюс почту на Лотус под виндовс на несколько тысяч человек. Все работает, хотя я бы не назвал "счастливыми" админов этого комплекса, но при таких нагрузках неизбежны "нюансы".
Либо туже аналитику под MS SQL с несколькми 10-ками гигабайт в месяц, суммарно там далеко за 200ГБ было. "Нюансы" почти закончились когда дисков в HDS забили нужное количество

Так что живые проекты под Виндовс есть!

gs писал(а): Там же аналитическая база управления более 100ГБ. Так что в правильных руках оно вполне себе работает.

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

Terol писал(а):Я кстати так и не получил ответ на свой вопрос

Нет, кажется, там были 5-ый mysql и 5-ый PHP, тестирование не я пытался проводить.

Terol писал(а):равнивать Apache & MySQL под Windows с другими, при этом на приложениях, которые совсем под неё не заточены мне кажется по крайней мере странным. Если вы хотели показать как себя ведет ОС под такими нагрузками то уж точно не с этими приложениями.

Никто и не спорит. Потому и нет результатов. Как, видимо, надо было поступить и с Фрей. Не смотря на не однократное упоминание в статье сомнений в адекватности результатов FreeBSD, многие увидели только графики...

umanski · Сообщение **umanski** » 04 апр 2006, 09:39

Почитал указанный мне даташит http://www.newisys.com/products/4300-e.pdf но МОДЕЛИ (ЧИПА) SCSI-контроллера и LAN-адаптеров так и не увидел. То, что там написано, содержит 0 информации.

Выдайте уже dmesg , пожалуйста!..

Сообщение **Stranger03** » 04 апр 2006, 10:48

Возможно автор это уже читал, но любопытно:

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

Another popular free operating system, FreeBSD, has threading problems that are much worse. Versions prior to 5.2 provide rather weak native threading. In some circumstances, I/O-intensive threads are able to get an unfair amount of CPU time, thus keeping other threads from executing as quickly as they should. Given the I/O-intensive nature of some database queries, this has a rather devastating affect on MySQL.

If upgrading isn't an option, build MySQL from the FreeBSD ports collection, and be sure to enable support for LinuxThreads. Doing so causes MySQL to use an alternative threading that's more like that available in Linux 2.4. Each thread is actually a process that, thanks to FreeBSD's rfork( ) call, has shared access to MySQL's global buffers. The overhead of this approach may sound like an issue, but it's really quite efficient. Many of Yahoo's hundreds of MySQL servers are using LinuxThreads on FreeBSD quite effectively.

Ссылка на первоисточник:
http://dev.mysql.com/books/hpmysql-excerpts/ch06.html

umanski · Сообщение **umanski** » 04 апр 2006, 11:18

Цитата древняя, как хобот мамонта... 5.2 была 100 лет назад и по гамбургеровскому счету вообще не работала как надо. 5.2.1 - уже легче. 5.3 - почти готово ко всему. 5.4 - просто продакшн. И с тредами там уже неплохо.

Но это все уже становится древней историей. У нас сейчас пошла эпоха 6го семейства, именно его мы тут обсуждали. Поэтому цитата о том, как все было плохо до 5.2 - непонятно для чего...

Цитата - из книги http://www.oreilly.com/catalog/hpmysql/ ... 9587575020 ссылка есть на сайте мускуля. А теперь - внимание! Смотрим на дату на книге.... ОЙ! Апрель 2004 года. Мдя...

За эти 2 года немало воды утекло и притекло и в мускуль, и во FreeBSD.

Внимательнее надо, камрады, внимательнее!

У меня на 5.4 мускуль собран с libpthread , а в /etc/make.conf прописано

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

WITH_XCHARSET=all
WITH_CHARSET=cp1251
WITH_COLLATION=cp1251_general_ci
WITH_PROC_SCOPE_PTH=yes
BUILD_OPTIMIZED=yes

Под 6кой очень рулят 64 бита (и система и мускуль, если памяти больше 2Г).

P.S. Нудно твержу свое. 6.0 гораздо быстрее, и 6.1 быстрее. 5.2 - музейный экспонат. Переходное звено от питекантропа к хомо сапиенсу.

Сообщение **Stranger03** » 04 апр 2006, 12:54

umanski писал(а):Цитата древняя, как хобот мамонта...

Возможно. Вот здесь еще похожий тест, не такой уж и древний.
http://people.fsn.hu/~bra/freebsd/mysql ... lbench.pdf

a_shats · Сообщение **a_shats** » 04 апр 2006, 13:16

umanski
SCSI там - LSI 53C1030
LAN какие-то из Broadcom 5700 серии (руки еще не дошли глянуть точно).

umanski · Сообщение **umanski** » 04 апр 2006, 15:21

http://people.fsn.hu/~bra/freebsd/mysql ... lbench.pdf
Мерси, почитал. Интересно. Но, сдается мне, благородные доны, они тоже до конца не разобрались, в какой именно bottleneck они уперлись... BTW, прошу меня простить, что нет улик на руках, но по рассказам знающих камрадов в моем асечном архиве есть запись "с чужих слов", что разница между между линуксом и freebsd6+libthr
на этом суперсмаке должна быть процентов 20 в пользу первого.

LSI Logic 53c1030 (Dual Ultra320 SCSI)
mpt driver
http://www.freebsd.org/cgi/man.cgi?quer ... ormat=html
На Sun Fire V20z на фуджитсу-сименсной амд-шной мамке такой, LSI 1030 она его зовет. GIANT_LOCK там нет (по крайней мере в i386 5.4) . Но вообще-то это надо в dmesg.boot смотреть - есть в данной версии и на данной платформе (i386, amd64, такие интимные подробности) в этом драйвере GIANTы или нет.

Сообщение **Stranger03** » 04 апр 2006, 15:25

umanski писал(а):камрадов в моем асечном архиве есть запись "с чужих слов", что разница между между линуксом и freebsd6+libthr
на этом суперсмаке должна быть процентов 20 в пользу первого.

Примерно тоже мне подтверждают мои коллеги по БСД,

.

a_shats · Сообщение **a_shats** » 04 апр 2006, 15:27

Newisys 4300E - OEM Sun v40z

Т.е. практически все, что применимо к v40z, применимо и к этим платформам тоже.

umanski · Сообщение **umanski** » 04 апр 2006, 15:44

Stranger03 писал(а):
umanski писал(а):камрадов в моем асечном архиве есть запись "с чужих слов", что разница между между линуксом и freebsd6+libthr
на этом суперсмаке должна быть процентов 20 в пользу первого.
Примерно тоже мне подтверждают мои коллеги по БСД, .

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

V40z в руки не попадал. Не имел шанса на нем ничего запустить... Но он не обязан быть совсем сильно похож на 20ый. Скажем, во всяких контроллерах есть разница и между x2100 и x4100 и т.д. ...

a_shats · Сообщение **a_shats** » 04 апр 2006, 15:49

v20z - Newisys 2100E

Нету у них суровых отличий в дровах, нету - и все тут.

umanski · Сообщение **umanski** » 04 апр 2006, 16:08

Я, к сожалению, не смотрел на нем 64битную фрю. В 32битной нет джайанта на этом контроллере. У 64битной может быть чуть другая реализация драйвера. dmesg.boot нужен для уверенности. В свое время с PAE были трудности - много драйверов нельзя было использовать, их постепенно допиливали.

GIANT-LOCK они снимают, когда есть уверенность в стабильности и реентерабельности соответствующего ядреного кода. Этот момент не обязан точно совпадать для разных архитектур.

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

Кто сейчас на конференции