Форум Тринити

Открытый технический форум по серверам и системам хранения данных, кластерным решениям, SAN, NAS.
Microsemi infortrend storage
Текущее время: 13 дек 2018, 14:52

Часовой пояс: UTC + 3 часа [ Летнее время ]




Начать новую тему Ответить на тему  [ Сообщений: 142 ]  На страницу Пред.  1, 2, 3, 4, 5, 6, 7, 8 ... 10  След.
Автор Сообщение
 Заголовок сообщения:
СообщениеДобавлено: 31 мар 2006, 13:15 
Не в сети
Advanced member
Аватара пользователя

Зарегистрирован: 27 авг 2002, 10:55
Сообщения: 5020
Откуда: Москва
SysR
Мда. Уважаемый. Либо измените тон Ваших постов (вежливее пожалуйста), либо будете забанены.
Ваше мнение выражено в хамской форме, я бы сказал.
Если лично для Вас тесты бесполезны - не пишите в ветку, пожалуйста.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: 31 мар 2006, 13:24 
Не в сети
Junior member

Зарегистрирован: 30 мар 2006, 17:06
Сообщения: 5
a_shats писал(а):
Мда. Уважаемый. Либо измените тон Ваших постов (вежливее пожалуйста), либо будете забанены.
Ваше мнение выражено в хамской форме, я бы сказал.
Если лично для Вас тесты бесполезны - не пишите в ветку, пожалуйста.

Прошу просчения, больше писать небуду, можете мой профиль удалить. Так как на таких НЕКОМПЕТЕНТНЫХ форумах я не обычно не сижу, мне за державу обидно.
Один совет: изучайте то что тестируете.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: 31 мар 2006, 13:28 
Не в сети
Сотрудник Тринити
Сотрудник Тринити
Аватара пользователя

Зарегистрирован: 23 авг 2002, 17:34
Сообщения: 16730
Откуда: Москва
По моему тесты пингвина и солярки никакого осуждения не вызвали. Так что они наверно полезны. Про фрю - ну что, еще раз повторить дисклаймер?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: 31 мар 2006, 15:05 
Не в сети
Junior member

Зарегистрирован: 31 мар 2006, 09:32
Сообщения: 1
Мое субективное IMHO
надо провести тест фри заново
ставить софт из портов
консультироваться по конфигу ядра на форуме, если уж сами неуверенны

в основном поддерживаю SysR

з/ы/ еще бы результаты мастдайки выдали бы
так для общего развития


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: 31 мар 2006, 15:17 
Не в сети
Сотрудник Тринити
Сотрудник Тринити
Аватара пользователя

Зарегистрирован: 23 авг 2002, 17:34
Сообщения: 16730
Откуда: Москва
Тест повторный проведем как я уже сказал (по крайней мере постараемся). На самом деле это далеко не все тесты - просто еще не готово.
Но по поводу тюнинга конфига, есть подозрение, что многократную разницу покрыть таки не удастся. Слишком круто. Правда я не очень представляю фрю на промышленной системе такого калибра - тут таки в основном солярка, аикс и начинающий внедряться линукс. Причины - в основном не технические, но от этого не менее веские. Так что тесты фри по большому счету были чисто факультативные.

Винда слила напрочь.

Мнение - пусть остается какое угодно, нам собственно интересна только конструктивная критика, а не пальцы.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: 31 мар 2006, 15:17 
Не в сети
Advanced member

Зарегистрирован: 04 окт 2004, 15:07
Сообщения: 103
SysR писал(а):
Цитата:
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 что касается сети.


Маловато будет, однако.:)

Код:
kern.ipc.somaxconn=2048
kern.ipc.maxsockbuf=16777216
net.inet.tcp.sendspace=1048576
net.inet.tcp.recvspace=1048576


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: 31 мар 2006, 15:42 
Не в сети
Junior member

Зарегистрирован: 31 мар 2006, 15:33
Сообщения: 2
gs писал(а):
....
Винда слила напрочь.
....

Простите, а правильно ли я понял что под Windows вы тестировали точно такую же конфигурацию:

Цитата:
# Apache 1.3.34
# MySQL 4.1.18
# PHP 4.4.2
# Форум phpBB 2.0.19 150000 сообщений


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: 31 мар 2006, 19:20 
Не в сети
Junior member

Зарегистрирован: 31 мар 2006, 19:10
Сообщения: 1
В общем как показывает практика для Linux и FreeBSD тесты на файловых системах, TCP стек, фильтры и.тд. достаточно похожи и значения отличаются на 10-30% максимум. Тут удивляют РАЗЫ....
Самый пресамый тюнинг дает тоже около 10-20% в отличие от нетюнингованной машины.
Скорее всего, что это беда FreeBSD при работе с многопроцессорными машинами или проблема именно с 64-битной AMD, но скорее всего именно с многопроцессорностью...
Для однопроцессорных машин таких различий не наблюдается. Проверялось неоднократно.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: 31 мар 2006, 19:26 
Не в сети
Сотрудник Тринити
Сотрудник Тринити
Аватара пользователя

Зарегистрирован: 23 авг 2002, 17:34
Сообщения: 16730
Откуда: Москва
Наверно. Только ведь как раз и хотели потестить машины не энтрилевел. Во второй части будет сравнение на том же тесте разных архитектур - АМД - классикСпарк - Ниагара - возможно ксеон. Только вот побаиваемся выкладывать - если уж банальная фря народу покоя не дает, то что будет после публикации не очень приятных результатов тяжелых машин. Можно и на гнев Великого САНА нарваться :)


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: 01 апр 2006, 00:58 
Не в сети
member

Зарегистрирован: 17 май 2003, 15:36
Сообщения: 32
Наконец-то я увидел ваш форум!
Цитата:
KeNt еще бы результаты мастдайки выдали бы
так для общего развития

Чтобы набежали мастдайщики и говорили что надо в реестре править? Мне вообще не интересно что у этого зверька в кишках. Мастдайка именно СЛИЛА. Кто-то ее рассматривает серьезно как сервер, кроме как для 1С? :)

Цитата:
smb - больше коннектов держалось бы в очереди в ядре...

Ну таймауты бы увеличились, кому легче стало бы?  :) Не было процессорного времени для работы пхп скриптов, куда его подевала фря и пытались понять.
Ты точно уверен что целесообразно использовать ULE? Пока пытался разобратся с проблемой, нашел ряд комментов, что мускул с ним гаррантированно дохнет.

Цитата:
Можно и на гнев Великого САНА нарваться

С классическим спарком не нарвемся, по предварительным оценкам он держит нагрузку лучше Newisys в разы. Я до сих пор сомневаюсь выкладывать результаты или нет, т.к. эти железки совсем не для веб нагрузок и никто в здравом уме их покупать не будет для веба.  Это как проводить соревнование жигулей с камазом, едет теже 90км\ч, но с 10т вместо 300кг. Пока склоняюсь больше к "не выкладывать". Удел веба мелкие сервера 1-2, макс 4 ядрышка, даже 8 что мы взяли - перебор.

Цитата:
анальная фря народу покоя не дает

можно элементарно забить, был ряд конструктивных комментариев (спасибо за них), их проверим если будет время и железки.

Сегодня получил письмо от разработчика одного из продуктов используемого в тесте. Примерно смысл: результаты тестирования в целом совпадают с нашими внутренними тестами.
В качестве оценки проделаной работы, их авторитетное мнение, для меня ценнее чем мнение 95% писателей, которые так и не привели ни лучших результатов на таком же или худшем железе по описаной методике, ни дали конструктивных советов.

На создание стенда надо:
- собрать как вам кажется оптимальным ядро AMD64 линуха/фри (пусть 30 минут)
- собрать как вам кажется оптимальным апач, мускул, пых-пых соответствующих версий (пусть еще час). Ставить nginx, zend и т.п. не надо. Ежу понятно что будет быстрее, но цель проверить работу ОС, а не доказать что эти продукты улучшают производительность.
- залить уже готовую базу (ну еще 15 минут).
- для оценки запустить тестилку на паре прогонов 256 и 1024 треда. Желательно на jre 1.5, она сильно лучше работает с потоками (хватит 1 часа)
- выложить конфиги и результаты (15 минут)
- ждать пока другие обгадят твои результаты (10минут)
Итого от силы 3-4 часа. На флейм времени было потрачено больше :)


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: 01 апр 2006, 01:31 
Не в сети
Junior member

Зарегистрирован: 12 янв 2006, 21:20
Сообщения: 19
sanek1978 писал(а):
Наконец-то я увидел ваш форум!
Цитата:
smb - больше коннектов держалось бы в очереди в ядре...

Ну таймауты бы увеличились, кому легче стало бы?  :)

Эм, как я понимаю, уменьшились бы, возможно, в тесте на отдачу кучи одновременных коннектов и измерения задержки фряха бы выправилась...
sanek1978 писал(а):
Не было процессорного времени для работы пхп скриптов, куда его подевала фря и пытались понять.
Ты точно уверен что целесообразно использовать ULE? Пока пытался разобратся с проблемой, нашел ряд комментов, что мускул с ним гаррантированно дохнет.

Идея использования ULE и всего прочего заместо 4.4BSD в том, чтобы добиться именно нормальной работы в SMP - с 4.4BSD работать будет, и стабильно - но про perfomance можно подзабыть.....4.4BSD планировщик не создан для работы в SMP, у него кучи Giant Lock-ов, он не умеет кидать threads между процессорами - а без этого у вас апач нормально не отмасштабируется - ибо будет привязка (процесс -> CPU)....По факту - на одной из наших машин загрузка мускула доходила до 50% - при машине dual xeon получается полностью занят один проц....Второй проц простаивал....Фряха - 4.11, планировщик => 4.4BSD...Вот эта обратная сторона медали стабильности оного планировщика(сейчас, впрочем, переделали запросы к базе, благо есть возможность, обновлили сам MySQL, полегчало :) )

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

sanek1978 писал(а):
Цитата:
Можно и на гнев Великого САНА нарваться

С классическим спарком не нарвемся, по предварительным оценкам он держит нагрузку лучше Newisys в разы. Я до сих пор сомневаюсь выкладывать результаты или нет, т.к. эти железки совсем не для веб нагрузок и никто в здравом уме их покупать не будет для веба.  Это как проводить соревнование жигулей с камазом, едет теже 90км\ч, но с 10т вместо 300кг. Пока склоняюсь больше к "не выкладывать". Удел веба мелкие сервера 1-2, макс 4 ядрышка, даже 8 что мы взяли - перебор.

Цитата:
анальная фря народу покоя не дает

можно элементарно забить, был ряд конструктивных комментариев (спасибо за них), их проверим если будет время и железки.

Сегодня получил письмо от разработчика одного из продуктов используемого в тесте. Примерно смысл: результаты тестирования в целом совпадают с нашими внутренними тестами.
В качестве оценки проделаной работы, их авторитетное мнение, для меня ценнее чем мнение 95% писателей, которые так и не привели ни лучших результатов на таком же или худшем железе по описаной методике, ни дали конструктивных советов.

На создание стенда надо:
- собрать как вам кажется оптимальным ядро AMD64 линуха/фри (пусть 30 минут)
- собрать как вам кажется оптимальным апач, мускул, пых-пых соответствующих версий (пусть еще час). Ставить nginx, zend и т.п. не надо. Ежу понятно что будет быстрее, но цель проверить работу ОС, а не доказать что эти продукты улучшают производительность.
- залить уже готовую базу (ну еще 15 минут).
- для оценки запустить тестилку на паре прогонов 256 и 1024 треда. Желательно на jre 1.5, она сильно лучше работает с потоками (хватит 1 часа)
- выложить конфиги и результаты (15 минут)
- ждать пока другие обгадят твои результаты (10минут)
Итого от силы 3-4 часа. На флейм времени было потрачено больше :)

Кстати, если уж у нас тут такие дебаты по MySQL - можно отдельно для него синтетику погонять какую-нибудь :) sysbench-евскую(или что посерьезней) OLTP-шку, например...Я как-то гонял для теста дома, нормально, имхо, некоторое представление дает...Картина при одновременных коннектах 2-4-8-16-32-...1024 может быть интересной...Впрочем, я-то тестил на одном камне - очевидно ничего реально интересного :)


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: 01 апр 2006, 20:24 
Не в сети
Junior member

Зарегистрирован: 01 апр 2006, 18:02
Сообщения: 9
Что тут сказать, коллеги...

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

Прошу сразу меня простить и на краткость не обижаться, мало времени - постараюсь конспективно, но конструктивно наметить то, что сделано не так.
  1. Не могу выкачать домой 50-мегабайтную базу, долго очень будет, но т.к. формат базы не указан, а это важно, предположу - а меня поправят, если я ошибаюсь, что база у Вас в формате MyISAM. MyISAM КАТЕГОРИЧЕСКИ противопоказан при работе под большими нагрузками. Все разрабатывают всякие форумы в этом формате, т.к. он дефолтный, так проще и никаких проблем при разработке они, ессно, увидеть не могут. Под нагрузкой ситуация меняется - я подчеркиваю это - КАЧЕСТВЕННО, а не количественно.
  2. Прошу меня простить, что не привожу здесь ссылки на первоисточники, но общеизвестно то, что под фрей с майисамным мускулем вы будете измерять фактически скорость работы файловой системы. Причем в очень неэффективном режиме работы. База данных все-таки. И на графике у вас при росте нагрузки сначала все хорошо, потом она наедается.
  3. Неотключенный дебуг в ядре пугать никого особо не должен. От дебуг-символов еще никто не умирал. Включение SMP это хорошо. Оптимизировать ядро надо - выкинуть лишние драйвера, процессор оставить только один - старший допустимый... это все просто. Ядро меньше весит и быстрее работает.
Нужно.
  1. Взять уже FreeBSD 6.1 PreRelease (BETA4) или релиз, если успеет выйти. Она лучше работает - ребята там все же движутся в верном направлении. И она уже вполне готова в дело. И 64 бита быстрее работает, так что не надо тестировать i386 рядом с 64битным Солярисом. Надо аккуратно все собрать под 64 бита и все. Есть вещи, с которыми это не очень просто - но апач и мускуль вполне себе соберутся.
  2. Аккуратно разобраться с ядром. Нетюненое ядро - какой интерес? Кто ж на таком работает? Сравнить из чисто академического интереса? Ну, если времени не жалко... Шедулер ULE - я слышал, что он еще не вполне готов, трогать его без толку. Хотя ситуация может и измениться, и скоро... IPV6 проще вообще не трогать - есть еще над чем подумать. Неиспользуемые драйвера надо выкинуть ВСЕ. NFS никому не мешает. Кстати, может быть интересно использовать для всех тестируемых систем один общий внешний NFSный сторадж - очень частая на практике ситуация.
  3. Далее. Все собирать из портов. Убедиться, что все собирается с оптимизацией, под нужный проц и с правильными опциями.
  4. Сконвертировать базу в InnoDB. Full-text indexes форум phpBB не использует, так что сконвертируются все таблицы (в отличие от IPB, где в 2 самых нагруженных - порядка 50% нагрузки - нужно было бы отказаться от них). Далее нужно будет добавить в базу phpBB ряд индексов, которых ему реально не хватает - примерно 3-4-5 индексов - анализ медленных запросов поможет. Разработчики форумов не работают с экземплярами под такой нагрузкой, им многое просто не видно и не очевидно. Разнице показываемых результатов вы поразитесь. Когда мне показали графики загрузки одной системы с множеством очень посещаемых форумов до и после - я поразился.
  5. Внедрите nginx. Ту же работу у вас будет делать гораздо меньшее количество апачей и гораздо эффективнее. Памяти много - буферами можно будет не жадничать.
  6. Внедрите к php модуль расширения eAccelerator (кеширование php и байт-кодов, кэш общий для всех детей данного мастер-процесса апача), а еще лучше в связке с php Encoder'ом (предварительная прекомпиляция с оптимизацией). Лично недавно внедрил nginx (просто в режиме акселерированного некеширующего проксирования, даже статику пока им не раздавал) и eAccelerator (просто, без енкодера) на системе, где основную нагрузку создавали большой php-шный сайт и форум на IPB 2. Использование памяти уменьшилось втрое, зарузка про процессорному времени в 2.5-3 раза, загрузка по LA в 3-4 раза, время реакции в часы пик - на порядок-полтора. Памяти у вас много, в кэш все влезет, что будет надо.
  7. В процессе тестирования мониторьте
    • CPU LA
    • CPU Total/Interrupt Times (для Solaris - Total/System Times)
    • Memory/Swap usage (для FreeBSD нужно Inact+Free, для Solaris нужно учитывать специфику ее обращения со свопом, нужно извлечь, сколько там реально лежит). Памяти у вас много, своп должен показывать 0.
    • Disk Load, iops, In/Out (если средняя (!) величина за дежурные 5 минут будет 50-70 - считайте, что Вам недостаточно хорошо, если 80-100 и выше - считайте, что просто плохо)
    • Disk Load, throughput, MPps In/Out (Необходимы оба графика! Вы можете - и скорее всего, должны - выйти на насыщение по операциям гораздо раньше, чем диски начнут захлебываться по пропускной способностями - клиент, веб-сервер, форум и база взаимодействуют тучами мелких пакетиков вразнобой, а не большими потоками подряд, доступ у базы гораздо более random чем sequential, тем более в вашем варианте, и операции ввода-вывода гораздо важнее объемов).
    • LAN Traffic, pps, In/Out
    • LAN Traffic, Mbps, In/Out
    Без мониторинга и графиков тесты не очень дорого стоят. Вы просто не знаете, что на самом деле происходит, а вам кажется, что знаете - и вы рассказываете об этом другим. И внутреннюю жизнедеятельность мускуля стоит помониторить. А без этого вы так и не будете знать, в которое именно узкое место вы уперлись, и не зная это, будете не сравнивать между собой 3 системы, а измерять толщину 3 бутылочных горлышек, вам неизвестных.
  8. Попробуйте перейти от RAID1 к RAID10 . Особый экстремизм - раздробить базу на части и разложить вдумчиво по разным независимым шпинделям без всяких RAIDов.
  9. И вот после всего этого надо перемерять все 3 системы. В этих новых условиях - все 3 системы. Это не очень маленькая работа, но вы ведь не ожидали, что корректно оттестить сложную проблематику будет быстро и легко? А так, как щаз - "грустное зрелище, душераздирающее зрелище". 3 системы как 3 сферических коня в вакууме, запущены в режиме, для которого не предназначены под такими нагрузками, как сказали бы физики "за границами применимости выбранной абстрактной модели". Из них одна система - сильно за границей.

    Это все равно как залить в 3 суперкара 3 разных сорта прямогонного бензина, масло у всех слить, родной антифриз заменить на "савейский" тосол (поддельный, с авторынка) - а потом в попытке побить рекорд скорости выяснять, который из 3 несчастных суперкаров быстрее едет. Top Gear, одно слово...
Поэтому результаты всех 3 систем в той или иной степени некорректны. А одной - некорректны сильно. Все 3 спокойно себя чувствуют под невысокой нагрузкой, а потом вы экстраполируете это на высокую нагрузку, для которой вы системы не приспособили, под которой они в неприспособленном виде не обязаны показывать по-настоящему хорошую работу - а потом удивляетесь, что результаты странные.

Ничего странного. 3 системы, недоточенные под интенсивную задачу. Двум нехорошо, одной плохо. Ну и что с того? Никто их в таком виде под такой нагрузкой не использует (просто не может :lol: ), никаких выводов сделать нельзя. Для чего тратилось время? Почему не потратить больше времени, чтобы результат был полезен? И оправдал бы все усилия? А так-то пока не оправдал никаких! Вы просто не то меряли. Говорю вам как человек, профессионально знакомый с техникой физического эксперимента. У вас методические погрешности. Результат системно и закономерно отличается от должного. Со всем уважением, коллеги, без обид!

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

P.S. Еще раз - меньше всего хочу кого-либо обидеть, но статью хорошо бы убрать, переделать и перевыложить. Вы же солидная фирма с хорошей репутацией, все-таки...
P.P.S. И простите за немного категоричный тон. Но я решил, что накидать хинтов и идей все же стоит, и указать на неучтенное и незамеченное - тоже. Удачи!


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: 01 апр 2006, 21:07 
Не в сети
Junior member

Зарегистрирован: 01 апр 2006, 18:02
Сообщения: 9
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

_________________
Vadim A. Umanski
Panferova.Net.RU
Comcor-TV


Последний раз редактировалось Landadan 01 апр 2006, 22:45, всего редактировалось 2 раз(а).

Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: 01 апр 2006, 21:38 
Не в сети
Junior member

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

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

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

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

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

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

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

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

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

Это если вообще захотелось протестировать данную частную задачу (phpBB - Apache - MySQL - storage) не на кластере, а на одиночной высокопроизводительной системе.

_________________
Vadim A. Umanski
Panferova.Net.RU
Comcor-TV


Последний раз редактировалось Landadan 01 апр 2006, 22:38, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: 01 апр 2006, 22:27 
Не в сети
Junior member

Зарегистрирован: 01 апр 2006, 18:02
Сообщения: 9
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


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 142 ]  На страницу Пред.  1, 2, 3, 4, 5, 6, 7, 8 ... 10  След.

Часовой пояс: UTC + 3 часа [ Летнее время ]


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

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


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
Создано на основе phpBB® Forum Software © phpBB Group
Русская поддержка phpBB