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

На доскональное знание данной темы, не может претендовать, пожалуй ни один спец, из ныне живущих на земле. ;-)
Так поможем друг другу.

Модераторы: Trinity admin`s, Free-lance moderator`s

Landadan
Junior member
Сообщения: 9
Зарегистрирован: 01 апр 2006, 18:02

Сообщение Landadan » 01 апр 2006, 21:07

2 smb-

Giant Lock'и постепенно уходят, только в некоторых подсистемах и драйверах остаются. Кстати, на адаптековском сказике до сих пор есть! Вот цитата с системы FreeBSD 6.1 BETA4

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

ahc0: <Adaptec aic7899 Ultra160 SCSI adapter> port 0xe400-0xe4ff mem 0xfebfe000-0xfebfefff irq 16 at device 3.0 on pci4
ahc0: [GIANT-LOCKED]
aic7899: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs
ahc1: <Adaptec aic7899 Ultra160 SCSI adapter> port 0xe800-0xe8ff mem 0xfebff000-0xfebfffff irq 17 at device 3.1 on pci4
ahc1: [GIANT-LOCKED]
aic7899: Ultra160 Wide Channel B, SCSI Id=7, 32/253 SCBs
Если у них в системе подобный контроллер - то просто труба. На то он и Гигантский Лок. Если процесс из юзерспейса делает сисколл, который войдет в такой драйвер - то другой юзерский процесс, может, еще и будет работать... пока не сделает какой-то (ЛЮБОЙ!!!) сисколл - а тогда будет курить бамбук, пока первый из ядра не выйдет и свой Giant Lock не снимет.

Неиспользуемые процессоры вполне могут быть намеком на то, что мы проводим время в ожидании, во взаимных блокировках. Вместо того, чтобы работать, сидим и глазки пучим.  :roll: Или еще на что-то... Это уже тонкие материи, но быть такого в норме не должно...



В статье заявлен первый Apache, а не второй. Apache 1.3.34 . Он вообще не тредится, он работает в префорке! Это у второго, у apache-2 есть режимы и worker с тредами, и pre-fork - как и раньше. А процессы чайлдов апача никто по отдельным ядрам планировщику раскидывать не мешает.

=======================

Просьба к автору, sanek1978.
Дайте полную спецификацию на тест-систему. Все. Не только процы, но и мать, модель, какие контроллеры в системе, все детально.  На чем висят диски? Какие сетевушки - модель, чипы?

Дайте, пожалуйста, полностью /var/run/dmesg.boot - может, среди драйверов устройств, по которым идет поток информации прии тесте, все же есть GIANT-LOCKED ... тогда на такой системе нельзя тестировать FreeBSD в рамках Вашего исследования - Вы просто не сможете корректно сравнивать результат с другими ОС, они по-другому реализованы, у них свои тараканы в голове... Скажите, нет ли чего подозрительного при работе в /var/log/messages
Последний раз редактировалось Landadan 01 апр 2006, 22:45, всего редактировалось 2 раза.
Vadim A. Umanski
Panferova.Net.RU
Comcor-TV

Landadan
Junior member
Сообщения: 9
Зарегистрирован: 01 апр 2006, 18:02

Сообщение Landadan » 01 апр 2006, 21:38

gs писал(а):Наверно. Только ведь как раз и хотели потестить машины не энтрилевел. Во второй части будет сравнение на том же тесте разных архитектур - АМД - классикСпарк - Ниагара - возможно ксеон. Только вот побаиваемся выкладывать - если уж банальная фря народу покоя не дает, то что будет после публикации не очень приятных результатов тяжелых машин. Можно и на гнев Великого САНА нарваться :)
Делайте все корректно - и пусть тогда все хоть в пупке лопнут!  :P А так, вы выяснили, что что-то плохо, но не выяснили почему... Может, у вас контроллер дисковый такой, что во фре для него еще в драйвере джайант лок не убрали? И вы смените дисковый контроллер и сразу все системы подровняются, т.к. проблемная их догонит на раз?

Или еще в чем-то дело? Надо бы сначала подопытного джинна датчиками обвешать сверху донизу, да подобрать вариант аппаратуры и методику тестирования (!) так, чтобы для всех систем это было бы корректно одновременно (!). Иначе условия неравны. И все 3 (или сколько их будет) системы одинаково потюнить под задачу.

Апач очень плохо отдает ответ в сеть. Висит в памяти, жрет проц. Висит и жрет, пока клиенту ответ не отдаст. nginx за него это сделает лучше - получит ответ от апача, закроет коннект с бэк-ендом, Апач сможет сразу принимать новые запросы (а не ерундой страдать), а nginx докидает ответ клиенту и еще и keepalive обеспечит.

Апач очень плохо отдает статику (те же картинки и т.д.). Накладные расходы ужасные. Каждая одна картинка - один http-запрос, одно обращение к чайлду апача или порождение нового, если нет их свободных, а потом он полезет на диск, поскрипит мозгами и начнет эту картинку отдавать... И так каждому клиенту каждую чертову стрелочку, логотипчик и смайлик... Обратно же nginx в студию!

Апач тратит массу лишнего времени на загрузку с диска и компиляцию раз за разом выполняющихся скриптов - OS на деле ничерта не кеширует, он сам - если специально не заставить - тоже. eAccelerator + Encoder в студию!

Последовательно и тщательно избавьте Апач на ВСЕХ тестируемых системах от ВСЕЙ лишней работы - не его она! Его дело - выполнение php-шной логики . В самом узком смысле слова. ТОЛЬКО выполнение. Все остальное он делает очень плохо, ОЧЕНЬ. Потому, что большой, сложный и тяжелый, потому, что не для этого предназначен.

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

Избавьте Апач от несвойственной ему работы, убедитесь, что в системах нет паразитных блокировок, которые искажают весь результат, создайте мускулю комфортные условия для работы, мониторьте все, чтобы ВИДЕТЬ, что вы ничего не пропустили - и все у вас будет в шоколаде. Высокосортном. Элитном. Вкусном - все полопаются от зависти.

И никто - ТОГДА - не оспорит результатов.

Это если вообще захотелось протестировать данную частную задачу (phpBB - Apache - MySQL - storage) не на кластере, а на одиночной высокопроизводительной системе.
Последний раз редактировалось Landadan 01 апр 2006, 22:38, всего редактировалось 1 раз.
Vadim A. Umanski
Panferova.Net.RU
Comcor-TV

Landadan
Junior member
Сообщения: 9
Зарегистрирован: 01 апр 2006, 18:02

Сообщение Landadan » 01 апр 2006, 22:27

gs писал(а):По моему тесты пингвина и солярки никакого осуждения не вызвали. Так что они наверно полезны. Про фрю - ну что, еще раз повторить дисклаймер?
Первое неудивительно, полезность несомненна, а дисклеймер ничего не лечит. Или убирать вместе с дисклеймером, или доточить, чтобы явное несообразие в глаза не бросалось... всем...
==============================
KeNt писал(а):Мое субективное IMHO
надо провести тест фри заново
Все тесты. Мотивировка выше.
ставить софт из портов
ППКС!
консультироваться по конфигу ядра на форуме, если уж сами неуверенны
ППКС! И не только ядра. Никто из нас не родился со всеми теми знаниями, умениями и навыками, что сейчас имеет. И никто не выглядит хуже, чем должен, если только вопросы, которые он задает, правильные.

Когда-то я не знал половины того, что тут затронуто, но встали задачи - и я их раскопал. Когда-то я не верил в половину той разницы (качественной разницы) между девелопментом и промышленной нагрузкой, которую потом увидел на натуре и смог не только почувствовать, но и численно сравнить.
==================================
gs писал(а):Тест повторный проведем как я уже сказал (по крайней мере постараемся). На самом деле это далеко не все тесты - просто еще не готово.
Я боюсь показаться нахальным и/или вызвать Ваше разочарование и недовольство, но переделывать нужно гораздо больше, чем Вы, возможно, полагали.
Но по поводу тюнинга конфига, есть подозрение, что многократную разницу покрыть таки не удастся. Слишком круто.
Вы не вполне правы. Все (ВСЕ!) зависит от того, во что Вы уперлись. Если в какую-нибудь блокировку, то ее обход может дать многократную. Влегкую. Избавление системы от несвойственной ей работы даст кратность от 3-4 до 8-10 - и для всех систем. Это не дело, когда вместо полезной работы дорогущий сервер только тепловыделением занимается.
Правда я не очень представляю фрю на промышленной системе такого калибра
Это не аргумент. Я представляю и использую. И ОЧЕНЬ много кто использует.  Мне чаще всего стройность, удобство и стабильность важнее всего.
тут таки в основном солярка, аикс и начинающий внедряться линукс.
10ую солярку, x86/x64 в основном, шедевр индусов-программистов, этот Тадж-Махал программирования, им еще дотачивать и дотачивать, допиливать и допиливать... И драйвера дописывать, и много что доделывать, а детские ошибки (типа непоправленного LittleEndian/BigEndian при портировании на интел со спарка, из-за чего в России 2 раза в год система правит часы, улетая в другой век по времени и снося себе весь чердак напрочь) пора бы переставать делать. Патчей на нее как на винду. А кучу полезного софта от бэкапов до антивирусов для S10/X64 еще ждать и ждать. Я люблю эту систему и ценю во многих применениях, но если в ней поглубже покопаться, там много "интересного" спрятано. Все не без грехов.
Причины - в основном не технические, но от этого не менее веские.
У всех свои причины. Linux'ы входящие в Linux Community люди называют свободой и демократией, а часть не входящих - коротко бардаком и разносортицей. Каждому свое. В моей конторе пингвины вообще не используются - всех изжили. А кому-то они нужны позарез. Ради Бога.
Так что тесты фри по большому счету были чисто факультативные.
И зря Вы так!
Мнение - пусть остается какое угодно, нам собственно интересна только конструктивная критика, а не пальцы.
Я старался. Не судите строго.
Vadim A. Umanski
Panferova.Net.RU
Comcor-TV

smb-
Junior member
Сообщения: 19
Зарегистрирован: 12 янв 2006, 20:20

Сообщение smb- » 01 апр 2006, 23:01

Landadan писал(а):2 smb-

Giant Lock'и постепенно уходят, только в некоторых подсистемах и драйверах остаются.
Так это....А 4.4BSD планировщик не содержит чаем этих самых локов в своем коде? ;) Вот об этом речь...=)
Landadan писал(а): Кстати, на адаптековском сказике до сих пор есть! Вот цитата с системы FreeBSD 6.1 BETA4

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

ahc0: <Adaptec aic7899 Ultra160 SCSI adapter> port 0xe400-0xe4ff mem 0xfebfe000-0xfebfefff irq 16 at device 3.0 on pci4
ahc0: [GIANT-LOCKED]
aic7899: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs
ahc1: <Adaptec aic7899 Ultra160 SCSI adapter> port 0xe800-0xe8ff mem 0xfebff000-0xfebfffff irq 17 at device 3.1 on pci4
ahc1: [GIANT-LOCKED]
aic7899: Ultra160 Wide Channel B, SCSI Id=7, 32/253 SCBs
Если у них в системе подобный контроллер - то просто труба. На то он и Гигантский Лок. Если процесс из юзерспейса делает сисколл, который войдет в такой драйвер - то другой юзерский процесс, может, еще и будет работать... пока не сделает какой-то (ЛЮБОЙ!!!) сисколл - а тогда будет курить бамбук, пока первый из ядра не выйдет и свой Giant Lock не снимет.
Логично...:)
Landadan писал(а): Неиспользуемые процессоры вполне могут быть намеком на то, что мы проводим время в ожидании, во взаимных блокировках. Вместо того, чтобы работать, сидим и глазки пучим.  :roll: Или еще на что-то... Это уже тонкие материи, но быть такого в норме не должно...
Я вот лично не уверен, что 4.4BSD-планировщик нормально распределяет очередь процессов(а уж потоков тем более) при большом кол-ве одновременных запросов....Ну не создан он для такого....
В статье заявлен первый Apache, а не второй. Apache 1.3.34 . Он вообще не тредится, он работает в префорке! Это у второго, у apache-2 есть режимы и worker с тредами, и pre-fork - как и раньше.
[/qoute]
Ценное замечание, еще ведь хотел посмотреть какие MPM-модули в ходу у 1.3 Apache =)
Тогда логичным будет включить 2 апача в тест - 1.3 с mpm_prefork и 2.0(2.2?) с mpm_worker
А процессы чайлдов апача никто по отдельным ядрам планировщику раскидывать не мешает.
В принципе да.....

=======================

Просьба к автору, sanek1978.
Дайте полную спецификацию на тест-систему. Все. Не только процы, но и мать, модель, какие контроллеры в системе, все детально.  На чем висят диски? Какие сетевушки - модель, чипы?

Дайте, пожалуйста, полностью /var/run/dmesg.boot - может, среди драйверов устройств, по которым идет поток информации прии тесте, все же есть GIANT-LOCKED ... тогда на такой системе нельзя тестировать FreeBSD в рамках Вашего исследования - Вы просто не сможете корректно сравнивать результат с другими ОС, они по-другому реализованы, у них свои тараканы в голове... Скажите, нет ли чего подозрительного при работе в /var/log/messages
Тут нечего добавить, разве что странно, что не было сделано...Я подумал было, что на то есть веские причины, но...все равно странно :)

smb-
Junior member
Сообщения: 19
Зарегистрирован: 12 янв 2006, 20:20

Сообщение smb- » 01 апр 2006, 23:15

Landadan писал(а): Избавьте Апач от несвойственной ему работы, убедитесь, что в системах нет паразитных блокировок, которые искажают весь результат, создайте мускулю комфортные условия для работы, мониторьте все, чтобы ВИДЕТЬ, что вы ничего не пропустили - и все у вас будет в шоколаде. Высокосортном. Элитном. Вкусном - все полопаются от зависти.

И никто - ТОГДА - не оспорит результатов.
Тут логика хромает очень сильно.....
Вы хотите сказать, что мы не имеем права тестить на чистом апаче систему?Только потому что чистый апач не будет юзаться в серъезном продакшн?Это НЕ верно....Мы ИМЕЕМ право тестить на чистом апаче...
Только это тогда да, не реальный production-тест, а некоторая синтетика....

Кстати, можно тогда взять какой-нибудь lighttpd+kqueue/epoll+mod_fcgi(local php_sockets)+eaccelerator - будет еще один суровый тест...Заодно сравним perfomance двух http-серверов ;)

Мораль - просторов для оптимизации немеряно, идея тестов - не выжать чистый максимум из системы...Как бы мы софт ни крутили, при том, что крутим одинаково на всех системах - раскладка производительности не поменяется.....
Это если вообще захотелось протестировать данную частную задачу (phpBB - Apache - MySQL - storage) не на кластере, а на одиночной высокопроизводительной системе.
А где вы там кластер узрели?

Да, еще - по поводу сборки всего из портов :) Специально посмотрел - mysql собирается с bdb и ndb-cluster...Я бы сказал, что далеко не на каждом сервере это пригодится :) Мораль - собирать с оглядкой на порты(там грамотно отключено всё не нужное, согласен, + linuxthreads), но все равно с просмотром всех опций для сборки =)

Landadan
Junior member
Сообщения: 9
Зарегистрирован: 01 апр 2006, 18:02

Сообщение Landadan » 01 апр 2006, 23:22

1. Я боюсь соврать с устатку, но в плане Fine-Grain Locking и SMP-ng сделано при переходе 5.x -> 5.4 -> 6.0 -> 6.1 ОЧЕНЬ многое, и НАСТОЛЬКО серьезных проблем в самом шедулере остаться уже не должно. Надо искать менее сложные причины. См. про бритву Оккама.

Типа - на 2 и 4 головах все недурно, а на 8 уже звездец? Это не Вынь... ;)

Там не все так в локах сверху донизу, как свежепереписанный gvinum. Я недавно собрал на 4 Seagate 400GB SATA150 и контроллере Sil3114 под Dual Xeon 1.8 (wHT) на как раз 6.1 BETA4 gvinum/raid5 . Докладываю. Там нехватает части манов, там требуются пляски с бубном и терпение, но он работает. Но это такой ДЗЕН!!! Мама-не горюй... 13.5 запись и 32 на чтение. Но блокировки уйдут, я дождусь, щаз мне на той машине нужно место, а не скорость. А места у меня теперь терабайт. Каждому свое.

2. Я прозрачно намекаю на то, что адаптек - самый распространенный встроенный контроллер на матерях...

3. Старый шедулер ориентирован на корректность, а вслед за тем - на производительность. Они пробовали включить ULEшный по дефолту в какой-то из 4ых версий, кажется - и в следующей же вернулись назад. И стали спокойно его дотачивать. Они близки к полной победе, но т.к. у меня не горит, я пока жду.

Я не считаю верным валить все на шедулер. Мы не устранили гораздо более очевидные проблемы. С ними - в отличие от шедулера - мы можем разобраться без помощи Святого Духа и FreeBSD Core Team.

4. Думаю, это не тайны мадридского двора, а просто недостаточное внимание к важным деталям. "Щитильнее надо, ребята! Общим видом овладели, теперь частности не надо упускать!" (с) М.М. Жванецкий

5. Апач 2.2 я бы не рекомендовал. Доточат они его - вот и будем посмотреть. Один баг одновременно - такой принцип. Девелопмент-глюкота на перформанс-тесте противопоказана.
Последний раз редактировалось Landadan 01 апр 2006, 23:38, всего редактировалось 1 раз.
Vadim A. Umanski
Panferova.Net.RU
Comcor-TV

Landadan
Junior member
Сообщения: 9
Зарегистрирован: 01 апр 2006, 18:02

Сообщение Landadan » 01 апр 2006, 23:32

Тестить чистый апач мы право имеем. Заранее зная, что под серьезной нагрузкой он без костылей нормально работать не способен. Спрашивается, а какого Энрике Иглесиаса и отца его, Хулио, тратить столько времени и так напрягаться?  :lol: Я ж говорю - сферический конь в вакууме. Гордость нашей кунсткамеры.

Раскладка производительности может выровняться (и к гадалке не ходи - выровняется) до справедливого соотношения, если система перестанет страдать фигней, а начнет АРБАЙТЕН, причем ШНЕЛЛЕР. А пока у нас один только АХТУНГ, а это не дело.  8)

Я не узрел там кластер, я говорю, что это задача словно специально для кластера. А сейчас - да, мы тестим один мощный сервак.

Просмотром опций - однозначно. Но изобретать велосипед не нужно. Его уже с портом прикатили. Самое основное он еще и спросит при сборке. И только 1-2 волшебных слова (максимум, и то не факт что для теста именно, скорее уже в работу) мы скормим в командной строке команде make ...
Vadim A. Umanski
Panferova.Net.RU
Comcor-TV

smb-
Junior member
Сообщения: 19
Зарегистрирован: 12 янв 2006, 20:20

Сообщение smb- » 01 апр 2006, 23:43

Landadan писал(а):1. Я боюсь соврать с устатку, но в плане Fine-Grain Locking и SMP-ng сделано при переходе 5.x -> 5.4 -> 6.0 -> 6.1 ОЧЕНЬ многое, и НАСТОЛЬКО серьезных проблем в самом шедулере остаться уже не должно.
Увы, не следил за конкретно этими изменениями, но при переходе 5.4->6.0 не припоминаю таких changes в release_info - впрочем, пересмотрю разумеется, да и еще где-нибудь поищу....=)
Landadan писал(а): Надо искать менее сложные причины. См. про бритву Оккама.
=)
Landadan писал(а):3. Старый шедулер ориентирован на корректность, а вслед за тем - на производительность. Они пробовали включить ULEшный по дефолту в какой-то из 4ых версий, кажется - и в следующей же вернулись назад. И стали спокойно его дотачивать. Они близки к полной победе, но т.к. у меня не горит, я пока жду.
Да мы, в общем-то, тоже ждем, но интересно же ;) К тому же тесты - они на то и тесты, собственно, чтобы дабы давать пищу мозгам 8)
Landadan писал(а): Я не считаю верным валить все на шедулер. Мы не устранили гораздо более очевидные проблемы. С ними - в отличие от шедулера - мы модем разобраться без помощи Святого Духа и FreeBSD Core Team.
Тут, при выжимании из системы max, гораздо более очевидных проблем чем выбор шедулера и оценка его влияния на все, в настройке фряхи нету :) Если конечно у вас буферы внезапно не кончаются посреди бела дня....

Ибо дальше идет подкрутка sysctl под конкретную систему и загрузку...
Landadan писал(а): 5. Апач 2.2 я бы не рекомендовал. Доточат они его - вот и будем посмотреть. Один баг одновременно - такой принцип.
Да я его тоже вроде не рекомендовал, считай даже, просто упомянул, что он есть такой - но на нем тесты проводить - гм-гм, если уж ну очень хочется  :lol:

Landadan
Junior member
Сообщения: 9
Зарегистрирован: 01 апр 2006, 18:02

Сообщение Landadan » 01 апр 2006, 23:57

1. Попадали на глаза осенью-зимой статьи ребят из коре тим и нет-бсд-шников. Не хочу просто по памяти цитировать. Общее впечатление - у них нет избытка ресурсов, но идут они ТУДА, а не неТУДА. А FineGrain Locking и SMPng это и проекты и стратегия, это делается постоянно.
2. Я прагматик. Шедулер я изменить не могу. Пока новый не доказал свою стабильность, мне начхать на его скорость. А тут сначала надо изжить и все проверить проблемы, которые лежат ближе к поверхности. Сдается мне, есть они. И только тогда можно будет прогнать тест на одном и другом шедулерах, если будет очень интентересно. Не раньше.

То, что смена шедулера ничего не давала автору статьи, есть намек именно на то, что не с него надо начинать. Нет смысла рыть тонкости, пока с гарантей не убраны все эффекты более грубого порядка - все упрется в них, а не в тонкости.
Vadim A. Umanski
Panferova.Net.RU
Comcor-TV

opolzen
Junior member
Сообщения: 2
Зарегистрирован: 31 мар 2006, 09:24

Сообщение opolzen » 02 апр 2006, 13:29

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

sanek1978
member
Сообщения: 32
Зарегистрирован: 17 май 2003, 15:36

Сообщение sanek1978 » 02 апр 2006, 15:01

2Landadan
Спасибо за комментарии, с большинством того что вы написали согласен, отвечу по спорным для меня частям.

>  Не то чтобы все плохо, но, возможно, это не самая близко знакомая ему система из представленных

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

По Вашим рекомендация по mysql:
Нагрузка на БД в этом тесте минимальна, поэтому тюнинг этой части врядли кардинально поомжет.

> Взять уже FreeBSD 6.1 PreRelease (BETA4)

С этим не согласен, тогда уж взять последнее ядро Linux (в тесте 2.6.5), какую нить Nexent-у и т.д.
Stable позиционируется как стабильная версия, которая и предназначена для продакшена.

> i386 рядом с 64битным Солярисом

Фря была AMD64

> внедрил nginx (просто в режиме акселерированного некеширующего проксирования, даже статику пока им не раздавал) и eAccelerator (просто, без енкодера)

А без nginx пробовали?
Да, это получится более близкая к жизни конфигурация, но и тестить надо будет долго. К выходу результатов,
будут жалобы  "что же вы взяли FreeBSD бета 4, когда уже есть FreeBSD бета 10". Да и не ставилось целью выжать
больше попугаев при помощи акселераторов и т.п.

> В процессе тестирования мониторьте
> Memory/Swap usage
изначально удостоверялось что нет свопинга

> Disk Load, iops, In/Out (если средняя (!) величина за дежурные 5 минут будет 50-70 - считайте, что Вам недостаточно хорошо, если 80-100 и выше - считайте, что просто плохо)
Не понял, 50-70 какой величины Вы имеете в виду? Если виртуальной цифры средней загрузки диска в %, то эта величина очень относительна,
под Solaris я видел и 200%, и видел 100% когда заведомо известно что дисковая может больше. Насколько объективна эта цифра под FreeBSD не знаю, но под линухом она тоже, что-то типа "для оценки"

> LAN Traffic, pps, In/Out LAN Traffic, Mbps, In/Out
Помониторить можно, только там заведомо будет нагрузка не более 5-10%.

> Попробуйте перейти от RAID1 к RAID10
при 350МБ базы это не актуально, т.к. нагрузка на дисковую во время тестов была близка к нулю.

> 3 системы как 3 сферических коня в вакууме
Вот! Ключевая фраза, я ДО начала тестов знал, что это будет сферический конь в вакууме.
И вообще ЛЮБЫЕ тесты конь в вакууме, т.к. даже небольшая правка скриптов может поменять результаты,
или, как пример, будет много клиентов на меееедленных каналах и т.п.. Любой тест корректен при
полностью описанных условиях, т.е. когда у сферического коня описаны характеристики.

> И никто - ТОГДА - не оспорит результатов.
Изначально неверное утверждение, при каких бы условиях не проводились тесты, они будут субъективны.
Как живой пример - тесты TPC-C. С методической точки зрения все хорошо, все описано и посчитано,
все стандартизовано, даже маркетологи эти результаты в пресс-релизах приводят. Но последние несколько
лет мало кто в здравом рассудке рассматривает эти тесты как близкие к жизни и все больше их ругают.
Так что недовольные будут всегда.


> типа непоправленного LittleEndian/BigEndian при портировании на интел со спарка, из-за чего в России 2 раза в год система правит часы, улетая в другой век по времени и снося себе весь чердак напрочь

У нас не улетает, может чего не так сделали? :)


SMB- Мораль - просторов для оптимизации немеряно, идея тестов - не выжать чистый максимум из системы...Как бы мы софт ни крутили, при том, что крутим одинаково на всех системах - раскладка производительности не поменяется....
Хоть кто-то понял цель, это радует!

Landadan
Junior member
Сообщения: 9
Зарегистрирован: 01 апр 2006, 18:02

Сообщение Landadan » 02 апр 2006, 17:08

sanek1978 писал(а):2Landadan
Спасибо за комментарии, с большинством того что вы написали согласен, отвечу по спорным для меня частям.

>  Не то чтобы все плохо, но, возможно, это не самая близко знакомая ему система из представленных

Вы правы. Почему я и отказался от комментов по поводу этой ОС, и честно признался что "недокрутили".
Докрутите, не пожалеете.
В большей степени, результаты следует разценивать как "FreeBSD при таких настройках имеет такие результаты."
Возможно с результатами фри стоило поступить, аналогично как поступили с результатми Винды..
Нет. В отличие от Винды Фря является сетевым сервером, а не дурной имитацией.
По Вашим рекомендация по mysql:
Нагрузка на БД в этом тесте минимальна, поэтому тюнинг этой части врядли кардинально поомжет.
Не верю! (с) Станиславский. Ни по скорости, ни по времени отклика. Конвертните в Инно - и СРАВНИТЕ! Тогда разговор будет предметным. А до тех пор - Ваши слова против моих. Но это лишь слова. Но есть разница. Я ВИДЕЛ разницу после перехода нагруженного форума на Инно, а Вы - явно нет. Т.к. заставить Вас поверить я не могу, то очень хртел бы, чтобы и Вы увидели. Но - наше дело предложить, а Ваше - отказаться.

Повторю еще раз. Для Фри Вы благодаря МайИсамному мускулю померяли скорость работы (и реакции!) ФС при рэндомном доступе. А то, что база не сильно нагружена - так она и не может...

Я буду готов говорить о моей или Вашей правоте или неправоте в данном частном вопросе тогда, когда будет КОЛИЧЕСТВЕННАЯ разница. А пока - пообщались два умных человека, обоим было приятно... дальше что?  :lol:
> Взять уже FreeBSD 6.1 PreRelease (BETA4)

С этим не согласен, тогда уж взять последнее ядро Linux (в тесте 2.6.5), какую нить Nexent-у и т.д.
Stable позиционируется как стабильная версия, которая и предназначена для продакшена.
Вы не правы. У фри с некоторых пор Stable - это текущая ветка. Не девелопмент 7ка, а текущая 6ка сейчас. И не легаси 4 и 5. 6ка. Консерватизм (здоровый) - использование Release.

Я упоминал, что фри ударными темпами избавляется от блокировок. Это важно. 6.1 Release была намечена на 20 марта, кажется, Code Freeze прошел давно, изменений больше не будет и коммит будет на днях. Уже можно считать новым релизом 6.1. К моменту повторного теста (пусть он будет!) Вам будет нужно уже использовать 6.1.

> внедрил nginx (просто в режиме акселерированного некеширующего проксирования, даже статику пока им не раздавал) и eAccelerator (просто, без енкодера)
А без nginx пробовали?
Было без. LA в пике 50 а то и 100. На 2 тяжелых сайтах на двухголовом П3-1266 с полутора гигами мозга. И прибитых несколько чайлдов апача в сутки по нехватке памяти (бездисковый сервер без свопа). Результат первых оптимизаций (а я еще не тюнид НФС и базу, да и с нгинксом только начал) - см. выше. 1150 мег свободной памяти от одного нгинкса (2 воркера его). А потом еще eA прикрутил...  Я Вам про коней в космосе не рассказываю - я говорю то, что я своими руками сделал. Вот.
Да, это получится более близкая к жизни конфигурация, но и тестить надо будет долго. К выходу результатов,
будут жалобы  "что же вы взяли FreeBSD бета 4, когда уже есть FreeBSD бета 10".
Не будет.
Да и не ставилось целью выжать больше попугаев при помощи акселераторов и т.п.
Без них нормально не работает.
> В процессе тестирования мониторьте
> Memory/Swap usage
изначально удостоверялось что нет свопинга
В первую очередь интересно, сколько занято памяти под разной нагрузкой. Плюс, возможно, сходу неочевидно, сколько информации можно получить, сравнивая в одни и те же моменты предложенные графики.
> Disk Load, iops, In/Out (если средняя (!) величина за дежурные 5 минут будет 50-70 - считайте, что Вам недостаточно хорошо, если 80-100 и выше - считайте, что просто плохо)
Не понял, 50-70 какой величины Вы имеете в виду?
ИОПС!!! Операции в секунду. У дисков есть предел. И он очень невелик. Около 100, кажется.
Если виртуальной цифры средней загрузки диска в %, то эта величина очень относительна,
под Solaris я видел и 200%, и видел 100% когда заведомо известно что дисковая может больше. Насколько объективна эта цифра под FreeBSD не знаю, но под линухом она тоже, что-то типа "для оценки"
Нет, речь не о том.
> LAN Traffic, pps, In/Out LAN Traffic, Mbps, In/Out
Помониторить можно, только там заведомо будет нагрузка не более 5-10%.
Не надо заведомо. Надо факты.
> Попробуйте перейти от RAID1 к RAID10
при 350МБ базы это не актуально, т.к. нагрузка на дисковую во время тестов была близка к нулю.
1. Это Вам так кажется.
2. Время реакции разное.
3. Цифры уже в студию давайте!
> 3 системы как 3 сферических коня в вакууме
Вот! Ключевая фраза, я ДО начала тестов знал, что это будет сферический конь в вакууме.
И вообще ЛЮБЫЕ тесты конь в вакууме, т.к. даже небольшая правка скриптов может поменять результаты,
или, как пример, будет много клиентов на меееедленных каналах и т.п.. Любой тест корректен при
полностью описанных условиях, т.е. когда у сферического коня описаны характеристики.
И когда они хотя бы приближенно описывают реальность.
> И никто - ТОГДА - не оспорит результатов.
Изначально неверное утверждение, при каких бы условиях не проводились тесты, они будут субъективны.
Как живой пример - тесты TPC-C. С методической точки зрения все хорошо, все описано и посчитано,
все стандартизовано, даже маркетологи эти результаты в пресс-релизах приводят. Но последние несколько
лет мало кто в здравом рассудке рассматривает эти тесты как близкие к жизни и все больше их ругают.
Так что недовольные будут всегда.
Но не до такой же степени...
> типа непоправленного LittleEndian/BigEndian при портировании на интел со спарка, из-за чего в России 2 раза в год система правит часы, улетая в другой век по времени и снося себе весь чердак напрочь

У нас не улетает, может чего не так сделали? :)
У меня теперь тоже не улетает. После того, как патчей понаставили. Один из них закрыл ошибку. Только очень уж ошибка детсадовская...
SMB- Мораль - просторов для оптимизации немеряно, идея тестов - не выжать чистый максимум из системы...Как бы мы софт ни крутили, при том, что крутим одинаково на всех системах - раскладка производительности не поменяется....
Хоть кто-то понял цель, это радует!
Раскладка поменяется. Поменяется, если изначально системы не были в равных условиях, а их-таки поставят в равные.

P.S. Хорошие советы для того и даются, чтобы им никто не следовал.
P.P.S. А что - ПОЛНАЯ спецификация тестовой системы - это все-таки тайна?  :shock:
Vadim A. Umanski
Panferova.Net.RU
Comcor-TV

sanek1978
member
Сообщения: 32
Зарегистрирован: 17 май 2003, 15:36

Сообщение sanek1978 » 02 апр 2006, 22:01

> Повторю еще раз. Для Фри Вы благодаря МайИсамному мускулю померяли скорость работы (и реакции!) ФС при рэндомном доступе. А то, что база не сильно нагружена - так она и не может...
Не понял фразы "Она и не может" :(
 
> Я буду готов говорить о моей или Вашей правоте или неправоте в данном частном вопросе тогда, когда будет КОЛИЧЕСТВЕННАЯ разница
Правильный подход :) Точных цифр на руках нет, а без них это просто слово против слова.

> Консерватизм (здоровый) - использование Release
Но не BETA-у же, пусть и 4-ю! Это подход чисто программерский: "вот это... нет это, самый рабочий и крутой модуль"
Улучшение будет идти всегда, а на продакшн будет или Stable или Release, да еще и предыдущей версии :) Вот это пример
здорового консерватизма в моем понятии.

>>А без nginx пробовали?
>Было без. LA в пике 50 а то и 100.
После nginx как изменился LA? До eAccelerator. Мне интересно на сколько падает нагрузка при переходе на него.
В тесте есть возможность включать\выключать запрос "вложенных" в страницу элементов, т.е. как раз статики.

> ИОПС!!! Операции в секунду. У дисков есть предел. И он очень невелик. Около 100, кажется.
Чисто ИОПС это не показатель, еще надо:
- average queue (колличество потоков, которые обслуживает  носитель в данный момент времени)
- average service time (за сколько в среднем обслуживается запрос на ввод вывод)
- bytes transfered (это чтобы привязать к размеру запросов на ввод вывод)
100 средне статистических iops в БД для диска на сегодняшний день - ничто.

>>> LAN Traffic, pps, In/Out LAN Traffic, Mbps, In/Out
>>Помониторить можно, только там заведомо будет нагрузка не более 5-10%.
>Не надо заведомо. Надо факты.
Это мониторилось. Трансфер с сервера был в пределах 10МБит, подключение - 1ГБит.
О том что сеть мониторилось, в статье написано.

>>при 350МБ базы это не актуально, т.к. нагрузка на дисковую во время тестов была близка к нулю.
>1. Это Вам так кажется.
нет, не кажется. параметры iostat мониторились в процессе тестов. Но не сохранялись для статьи.

>2. Время реакции разное.
физического ввода\вывода не было.

>3. Цифры уже в студию давайте!
Вот активность по вводу выводу с солярис:
        bread/s lread/s %rcache bwrit/s lwrit/s %wcache pread/s pwrit/s
              0      88     100       0       2     100       0       0
              0      79     100       0       5     100       0       0
              0      75     100       0       3     100       0       0
              0     102     100       0       3     100       0       0
              0      90     100       0       3     100       0       0
              0      79     100       0       4     100       0       0
              0      91     100       0       3     100       0       0
              0      92     100       0       3     100       0       0
              0     116     100       0       2     100       0       0
              0      89     100       0       5     100       0       0
              0     105     100       0       3     100       0       0
ИМХО это практически сон.
Тут видно, что физического ввода нет. Есть совсем мало работы с кэшем ФС.
Если по памяти не помните колонок: http://www.cs.biu.ac.il/cgi-bin/man?sar+1


> Только очень уж ошибка детсадовская...
Они есть везде :) Даже в оракле совсем недавно:
- Патч Х
- Патч Х.1 через небольшой промежуток (исправление перекомпиляции объектов после патча Х)

> Раскладка поменяется. Поменяется, если изначально системы не были в равных условиях, а их-таки поставят в равные.
Да, при настройке FreeBSD она станет в равные условия.

> P.S. Хорошие советы для того и даются, чтобы им никто не следовал.
Ну почему же! Ряд советов действительно полезных.
Но я до сих пор не могу согласиться с НЕОБХОДИМОСТЬЮ установки nginx и eAccelerator для тестов. В продакшн может быть, но
не в тестовую среду. Появляются дополнительные звенья, которые вносят свои возмущения, требуют неоднозначной настройки.
Тем более как я понял под eAccelerator далеко не все работает, и много хостеров живет без него.
Для исключения nginx можно убрать из теста загрузку статики, и предполагать, что тестируется производительность сервера
стоящего за отдельной машиной с nginx, как и делается именно в нагруженных проектах.

> P.P.S. А что - ПОЛНАЯ спецификация тестовой системы - это все-таки тайна?  
Не тайна конечно, вот даташит:
http://www.newisys.com/products/4300-e.pdf
Если интересно более подробно тринитевцы расскажут, я не работаю в тринити.

> К моменту повторного теста (пусть он будет!) Вам будет нужно уже использовать 6.1.
Наличие или отсутствие повторного теста зависит не только от меня.
Как минимум нужна машина на несколько недель и активные консультации заинтересованных и знающих людей.
Как максимум время для тестов, его надо реально много. Также нужен специалист по фре, также со временем.
Но полезность повторного теста, для меня весьма сомнительна, т.к. мы
протестируем нового сферического коня в вакууме.
- Изменение версии или производителя компилятора может поменять результаты на 20-40%.
- Разные модели шедулеров, мы не можем однозначно утверждать что для этой нагрузки лучше
 тот или иной шедулер, пока не проверим, а проверять долго.
- наличие или отсутствие нормальных драйверов под ту или иную ОС также вносит серьезные возмущения
Этот список можно продолжать до бесконечности, и всегда, абсолютно всегда тест будет неактуален для
реального проекта и надо на проекте делать сайзинг заново.
Будет или нет вторая часть марлезонского балета пока утверждать не берусь.

Landadan
Junior member
Сообщения: 9
Зарегистрирован: 01 апр 2006, 18:02

Сообщение Landadan » 02 апр 2006, 22:36

3. Это и есть новый релиз

4. ЛА упал раза в полтора-два на одном этом. Улучшилось время реакции. Появилась куча памяти, которую можно было отдать еА. Он забрал не так многопамяти (в пике мег 25), но его применение уронило ЛА раз в 5-6 в пике графика МРТГ с 5минутным усреднением, а обычное время довело до уровня полусна. Но сам по себе ЛА - ерунда... Я сопоставлял с мониторингом загрузки по процессорному времени на графике Total & Interrupt Times. Интеррапт не меняется. Тотал упал раза в 2.5-3, иногда до 4. Меньшее количество апачей, работая постоянно и гораздо эффективнее, справились даже с большей реальной нагрузкой (насыщения нет, nginx жмет html-ный вывод, а трафик не упал), потребляя в разы меньше памяти и процессора. Реакция в пике же улучшилась на полтора порядка. Всеобщее щазтье. Эффект кумулятивный. Улучшения взаимно усиливают друг друга.

Кстати, побочный эффект еА - некоторая экономия памяти. Кеш шарится. В top'е показывает для child'ов Апача тотал сайз очень большой (не вся память, разрешенная под кеш, занята, зааллокировано гораздо меньше - сколько реально потребовалось!), а резидентный - меньше, чем был до еА. Суммарно - меньше памяти жрут.

Теперь узким местом является база. Еще буду тюнить НФС. Вот.


5. Тут иопсы не среднестатистические - тут диску надо головами дергать в полный разнобой. Тут ИОПСы очень невыгодные. Под ИННО лучше будет. У меня МРТГ снимает средне-5минутный график. Если на среднем 80-100, значит, в пике насышение. Больше 130-150 раз в секунду дернуть головами драйв не в силах в принципе. А seek это еще не работа, это только подготовка. ;)

Про нгинкс.
Я его тюнил по минимуму. Самому минимуму! Конфиг - полторы строчки на хост. Это и не кастом вовсе. Это годно для тестов.

Про еА.
Я как раз понял, что работает под ним практически все и что он самый адекватный из имеющегося в природе. Покуда полет нормальный. Плюс для параноиков можно запрещать кешировать отдельные каталоги. Я собираюсь наоборот отключить или сильно отложить принудительное устаревание кеша... Пусть держит пока не надоест. Файл изменится - файл перечитается, один раз. По FTP дата меняться будет. У кого есть SSH и кому не влом принудительно руками восстанавливать дату (зачем только) и у кого файл не перечитается - тот сам себе злобный Буратинка. У меня хостинг, а не благотворительное общество, и за 3 копейки пучок все свои мощности я не продаю.

Если ресурсов не жалко и рентабельность фигня - можно жить без него.


Даташит зачитаю завтра с работы.


Про тест.
- Свои аргументы я привел, фонтан иссяк, надо дать отдохнуть и фонтану. (с) К. Прутков.
- Принципиальных изменений компайлера вроде не предвидится.
- Забудьте про шедулер. ULE, насколько слышно, не с 6.1 станет основным. Вам его включение не помогло. Он Вас только отвлекал. Вывод - он НЕ МОЖЕТ быть ответственным за основную часть эффекта - забудьте про него на время. Забейте на шедулер. Пока новый не заявлен Коре Тим как основной - его нет. Кому надо - пусть сам развлекается. У нас свободная страна и плюрализьм!
- Не используйте в тестах контроллеры, для которых хоть под одну из систем кривые драйвера. Иначе Вы опять-таки будете тестить не то, что заявляете. А эту кривизну. Заюзайте контроллеры, которые в норме везде. Это и есть корректный подход.
- Тест может быть первым приближением к реальному проекту. А может быть 0ым или минус-первым. Я за первый вариант, а Вы? ;)



А если будет второй акт мерлезонского балета, об этом будет известно?
Vadim A. Umanski
Panferova.Net.RU
Comcor-TV

sanek1978
member
Сообщения: 32
Зарегистрирован: 17 май 2003, 15:36

Сообщение sanek1978 » 02 апр 2006, 23:38

> А если будет второй акт мерлезонского балета, об этом будет известно?

Если я буду иметь отношение к тестам, то Вам будет известно, не буду зависит от тринитевцев. Уж они то ваше мыло знать должны :)
Идеи как тестировать  есть, инструментарий  чем тестировать есть. Так что в принципе, любой желающий сможет этим занятся.

Ответить

Вернуться в «Серверы - ПО, Unix подобные системы»

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

Сейчас этот форум просматривают: нет зарегистрированных пользователей и 21 гость