Проект Hudson испытывает проблемы с инфраструктурой Java.net

>Лежит на поверхности

Ну да - Zope и Amazon S3/EC2 - это где-то рядом - почти одно и тоже.

Я удивляюсь как ты не привел чтонить powered by phpBB.

http://www.postgresql.org/support/professional_hosting

> это почему это? даже пресловутый ms sql это давным давно умеет делать

Я имею в виду кластер распределяющий нагрузку, а не failover. MS SQL как я понял ниже вообще не умеет (до 2к5 включительно) балансировать нагрузку.

РСУБД плохо кластеризуются, потому как для Рсубд нужно выполнять ACID, для этого нужно шарить блокировки. Это дает офигенский оферхед. Ведь нужно чтобы ВСЕ блокировки были у ВСЕХ узлов или узлы делятся на части, что еще больше усложняет реализацию.

В итоге в РСУБД очень быстро увеличивается системный трафик по мере роста реальной нагрузки. Тот же Oracle RAC некоторое время назад максимум тянул 4 ноды. Может сейчас поменялось?

Почитал про MS SQL - нашел правда только про 2к5: http://social.technet.microsoft.com/forums/ru-RU/sqlru/thread/63323ea4-5a18-4...

Q: Возможно ли сделать балансировочный кластер SQL 2005 ?

A: Если речь идет о балансировке загрузки, то нет.

может в 2k8 появлися кластер балансирующий нагрузку?

В любом случае если в 2к5 году на смогли сделать балансировку на 2 ноды, то о нормальной балансировке на 8-16-32 вообще говорить смысла нет. А АппСервера балансируются практически линейно.

> Ява работает на синтаксисе Си? Если вы так думаете, вы не знаете Си, извините.

Да, не знаю =)

Заменю высказывание на Java использует С++ синтаксис в большинстве случаев.

>Я удивляюсь как ты не привел чтонить powered by phpBB.

Это шутка юмора такая ?

Еще можно adobe.com добавить. CMS там на java, а сам сайт - ХЗ.

Вы научились делать обработку больших объемов данных без СУБД ? Премию Тьюринга АФФТАРУ!

Определение СУБД в студию ))) а то общее определение слишком общее - любая программа обрабатывающая данные становится СУБД. файл - БД, программа его пишущая или читающая становится СУБД.

Если вы сужаете до РСУБД, то да РСУБД те еще тормоза и на больших объемах данных их не применяют. Или применяют аш пачками в виде странных осьминожек, когда один пишет, с него реплицируется пачка, с которых и идет чтение.

Или вы думаете Google свой BigTable для прикола создал и их мелкие объемы данных можно в РСУБД-хе крутить ;))))))))))))))

>> Вы так и не осили области применения реляционнных СУБД?

А я разве упоминал слово реляционных ? Ведь не упоминал же!

Если не говорить о РСУБД, то любая программа будет сама себе СУБД. А значит говорить а том на кого ложится основная нагрузка по обработке бессмысленно.

«В крупнокалиберном софте, основную работу выполняет СУБД, остальное обвеска»

Так обвеска это тоже СУБД - в софте ничего кроме БД (данных) и СУБД (их обработки) нет.

>Дело в том что Яву назвали в честь сорта кофе. Который именно Ява (Java).

Жесть. Именно «Ява» он с какого языка - с немецкого который исторически более повлиял в прошлом на территорию бссср и потому тут остров Ява, а не Джава? А если бы испанский повлиял была бы «хава»?

Индонезийцы произнося его именно «джава». Архаичное написание названия острова в английском языке Djawa.

Ну и как с пайтоном. Не Питон а Пайтон (ибо в честь Монти Пайтон).

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

Тогда уж либо Джава-Пайтон, либо Ява-Питон.

>Это шутка юмора такая ?

Ну тебя ж хватило сравнивать Амазон с Zope.

> Не хочу сказать ничего хорошего про скорость питона, но неужели у вас именно требуются многопоточные приложения?

Да, даже больше. Поскольку на сервере идет работа большинства или всех работников той или иной компании, то отсутствие параллельности приложения это нонсенс. Представим себе что огромная фармацевтическая лаборатория скажем на 15 000 человек (число уменьшено, NDA ;) ) работает по 8 часов в день. Если есть GIL то реально с системой будут работать человек 10-20 (пока одни заполняют поля, у другого идет обработка). А что делать оставшимся 14 985?

У нас практически во всех проектах по ТЗ было изначально проходило наличие кластеризации.

PS с трудом представляю как можно писать однопоточное серверное приложение.

> блин.. да не будут никогда крупные компании (действительно крупные) использовать всю эту шушеру типа mysql.

А на чем же они сайты держат? Или у них все ъ-сертифицированный-энтерпрайз, включая даже туалетную бумагу в толчках?

> Тогда уж либо Джава-Пайтон, либо Ява-Питон

+1. Я зомбированных так и детектрирую, и именно по «пайтону». :-)

А если бы испанский повлиял была бы «хава»?

если «хава», то точно не испания, хотя и географически недалеко :)

> это почему это? даже пресловутый ms sql это давным давно умеет делать

Я имею в виду кластер распределяющий нагрузку, а не failover.

1. с этого надо было начинать

2. ms sql на таких задачах (да и на других в общем-то тоже) идёт «в топку», тут надо говорить про СУБД уровня ibm db2 и oracle, насколь я знаю у них с этим существенно лучше

3. надо вообще смотреть конкретную задачу, может там нужна какая-нибудь изначально распределённая nosql БД

хоронить

> 1. с этого надо было начинать

ХЗ для меня кластер это всегда распределение нагрузки. failover это недо-кластеры.

2. ms sql на таких задачах (да и на других в общем-то тоже) идёт «в топку», тут надо говорить про СУБД уровня ibm db2 и oracle, насколь я знаю у них с этим существенно лучше

MS SQL очень приличная СУБД. По удобству разработки под нее удобнее Oracle. DB2 не в курсе - редко применяется, а Oracle кластеризуется тоже так себе. В смысле дорого. Дешевле создавать кластеризованные приложения.

3. надо вообще смотреть конкретную задачу, может там нужна какая-нибудь изначально распределённая nosql БД

NoSQL имеют свои прибабахи. Не факт что легко излечимые.

Форкнуть с именем Shmudson. Думаю, половина IT специалистов оценит.

>> А M$ сейчас может тааакую свинью подложить ораклу - она может полностью открыть .Net и сделать его на самом деле кроссплатформенным

Наступит конец света если микрософт сделает что-то межплатформное. Оракл восьмая компания оказавшая вклад а разработку линукс ядра. Пруф - http://www.opennet.ru/opennews/art.shtml?num=28856. Так что микрсофтожополизы идут анальным проходом в говнецо.

продолжительной интеграции

НЕПРЕРЫВНОЙ интеграции

> В итоге безвыходная ситуация - так жить нельзя - 10 минут ждать сабмита формочки, и дропнуть индексы нельзя - придется по 5 минут ждать чтения

А про table partitioning Ваша «соседняя команда» не знает? Ну что тут сказать - не самая перспективная команда. :-)

Сисадмины и школьники , собравшиеся в этом треде, совсем не понимают сути джавы. И того , что, блин, написать на «чистом трушном С» то , что пишется на джаве, настолько геморойно и сложно, что никто браться не будет. Да и на питоне тоже дорого: изобретать все те велосипеды, которые уже давно написаны и оттестированы на не любимом ваме Ынтерпрайзе. В общем, удади.

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

Это не я. Я человек простой, мне ваще похрен как вы тут зовете эти устаревшие ненужные технологии, прочным прикусом бульдога вцепившиеся в ноги несчастного бизнеса. Про Пайтона то сами создатели трещали, а легенду про Яву мне рассказал один очень суровый гик.

Наступит конец света если микрософт сделает что-то межплатформное.

И мы все умрем что ли ? Тогда ? или что.

> А зато процесс при ошибках валится только сам и не валит все приложение. И ты четко знаешь, что процесс пишет только туда, куда разрешено, в то же время в тредах легко разнести «не те» данные. Процессы побезопаснее будут.

Это вопрос акуратности написания и объема данных которыми обмениваются приложения. Так что вам или скорость или «надежность» Хотя такая «надежность» не дорого стоит. А тех кто в состоянии реализовать FSM внутри одного процесса почему-то не много.

> на голом си - это ощутимо, да, на питоне всё не так страшно как Вы себе рисуете

и да, поверьте, обмен данными по сети и чтение с диска всё равно на порядки медленнее

хм.. я вот думал что 350Gbit/s с Network RDMA (IB 12x) и 80-120Gbyte/s скорость чтения с Lustre (120 striped file) - не то что бы сильно отличаются от скорости работы с памятью. Неужели ошибался ? Или вы хотите сказать что у питона что с тредами что с процессами одинаковая жопа с меж тредовым IPC? Тогда что мы обсуждаем - когда платформа в принципе не подходит для HighLoad задач?

>> Вобщем кончай курить или что там у тебя.. но сравнивать thread vs process это даже не смешно.. это .. вобщем маразм тут отдыхает.

1. Там была цитата из википедии (я же не утверждаю что внимательно разбирался) 2. Курю только табак 3. По сути, если речь идет о сетевом приложении, то там и так дохрена ПРОЦЕССОВ сервера, каждый из которых рулит своим интерпретируемым кодом, да и блокировка происходит не на уровне процессора, а на уровне процесса, так что не проблема
А пот поводу общих данных, так это вообще плохо и Python не дает отстреливать ноги

Не похоже на табак - ибо так вставляют только грибы у Кастаньеды. Так что бросай грибы и таки начни учиться, сначала разбересь что такое IPC (inter process communication) - потом почитай как это организовывается, потом почитай «стоимость» - а потом перестанешь нести бред о том что у сетевого приложения дохрена процессов сервера. Так поступает по сути только апач - с его 1 request == one worker, но и то - медленно но верно движется к структуре 1 процесс и куча тредов ибо проблем меньше. Вот у Mysql (чем не сетевой сервис) - все сделано тредами. Или так не бывает ?

> PS с трудом представляю как можно писать однопоточное серверное приложение.

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

>> PS с трудом представляю как можно писать однопоточное серверное приложение.

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

а куда приедем то? Есть 2 CPU по 4 ядра каждый. Есть 16Gb оперативки. Идет работа - приходят данные с внешних систем (5 разных систем, каждая кластером) + подключено оборудование рабочих (еще 100-200 устройств).

внешние системы фигачат примерно по 500-700 запросов в секунду. устройства работников запрос раз в 10 секунд каждое (pop-технологии однако) + еще по запросу на действие это примерно 2-5 в минуту.

КАК на эти запросы успевать отвечать, если сервер однопоточный, а значит 7 из 8 ядер стоят? И как может однопоточный сервер работать быстрее многопоточного на большом количестве обращений? Вероятно никак, а значит производительные приложения нужно писать на многопоточных платформах ;)

> внешние системы фигачат примерно по 500-700 запросов в секунду. устройства работников запрос раз в 10 секунд каждое (pop-технологии однако) + еще по запросу на действие это примерно 2-5 в минуту.

читать правильно: внешние системы фигачат примерно по 500-700 запросов в минуту, толстые XML через WebServices.

>> Ну, я участвовал в нескольких проектах по переносу с Java на .Net

А можно узнать по каким причинам решали делать такой переход?

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

> Если есть GIL то реально с системой будут работать человек 10-20 (пока одни заполняют поля, у другого идет обработка).

Вы серьезно думаете, что в случае веб-морды (к примеру) гил один на всех клиентов или я что-то не допонял? v_v

PS с трудом представляю как можно писать однопоточное серверное приложение.

Берешь и пишешь многопроцессное, в процессе по потоку. v_v

У нас практически во всех проектах по ТЗ было изначально проходило наличие кластеризации.

Ну да. И как вам GIL тут мешает? Вот в питоне и говорят: If you have multiple CPUs and you want to use them all, fork off as many processes as you have CPUs. (You write your web application to be easily scalable, don't you? So if you can run several copies on different boxes it should be trivial to run several copies on the same box as well.)

> КАК на эти запросы успевать отвечать, если сервер однопоточный, а значит 7 из 8 ядер стоят?

А, вы та и не поняли, что GIL один на процесс, а не один на ЭВМ? v_v

> Да и на питоне тоже дорого: изобретать все те велосипеды, которые уже давно написаны и оттестированы

Можно хотя бы часть списка в студию, для общего развития?

Ещё один адекват в треде. Плюсую.

>если «хава», то точно не испания, хотя и географически недалеко :)

Буква J в испанском зовется «хота». Jorje - это совсем не жорже - это хорхе.

>PS с трудом представляю как можно писать однопоточное серверное приложение.

poll/select и все разбито на четкие фрагменты если эти селекты инициируют какую-то длительную работу. Ничего сложного особенно нет.

>КАК на эти запросы успевать отвечать, если сервер однопоточный, а значит 7 из 8 ядер стоят?

Можно инциировать N описанных мной независимых процессов которое зависит от M ядер - такой себе локальный кластер.

как может однопоточный сервер работать быстрее многопоточного на большом количестве обращений?

Если у тебя не гарантировано короткий ответ то poll/select будет грузить только то сетевое IO которое к этому готово. В общем нагрузка попроще чем в thread-per-connection. В жабе собственно называется NIO - для того и придумали. С другой стороны треды на io-блокировке и так ресурсов особо не занимают так что выигрышь может и не быть.

> КАК на эти запросы успевать отвечать, если сервер однопоточный, а значит 7 из 8 ядер стоят? И как может однопоточный сервер работать быстрее многопоточного на большом количестве обращений? Вероятно никак, а значит производительные приложения нужно писать на многопоточных платформах ;)

как правило молча. Если у тебя блокирующиеся запросы - то собственно кроме создания потоков/процессов вариантов не много. А если у тебя дофига достаточно долго выполняющихся запросов, при этом можно послать запрос и результат будет доступен по какому-то событию (select, poll, kevent, etc) - то зачем плодить второй поток когда можно сохранить текущее состояние и начать выполнять другое?

Да это требует продуманной таблицы состояний и формального описания условий перехода из одного состояния в другого, но блин - это как бы state diagram из UML. почти библия :)

А на оставшиеся 7 ядер можно повесить кой чего другое..

PS. ровно таким образом была сделана одна система из серии pay by click, вполне себе 1 процесс умудрялся обрабатывать 800-2000 запросов в секунду (дальше помирал mysql). Единственную вещь которую пришлось вынести в отдельный процесс - mysql ибо эта дура таки только блокирующийся API предоставляет.

> С другой стороны треды на io-блокировке и так ресурсов особо не занимают так что выигрышь может и не быть.

Если считать что тред в ядре не потребляет ничего - то да, если подумать что ядру нужны ресурсы под тред, то лучше вернуться к FSM

А можно и просто форкнуться, или VoDA против форка как идеи? v_v

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

> Вы серьезно думаете, что в случае веб-морды (к примеру) гил один на всех клиентов или я что-то не допонял? v_v

Читая написанное - ДА.

Берешь и пишешь многопроцессное, в процессе по потоку. v_v

Так есть клиенты которые ходят на 80 порт + 443. И что мне самостоятельно разбираться как их раскидать по тредам-обработчикам?

>> PS с трудом представляю как можно писать однопоточное серверное приложение.

poll/select и все разбито на четкие фрагменты если эти селекты инициируют какую-то длительную работу. Ничего сложного особенно нет.

таки не въехал. poll/select «The select() function indicates which of the specified file descriptors is ready for reading, ready for writing, or has an error condition pending».

Таким образом определяется когда файл готов. Фиг с ним пусть мы сетевые соединения (коих в параллель довольно много) каким то образом засунули в файловые дескриптеры.

А дальше что? пришло два запроса в одну еденицу времени. Их нужно обработать параллельно ибо бОльшая часть работы по обоим запросам полностью независима. Как это сделать на одном потоке? Как один поток может обслуживать два запроса одновременно (без перерыва/переключения контекста и т.п.) Может вы мне доку какую дадите чтобы объяснить этот факт.

>> как может однопоточный сервер работать быстрее многопоточного на большом количестве обращений?

Если у тебя не гарантировано короткий ответ то poll/select будет грузить только то сетевое IO которое к этому готово. В общем нагрузка попроще чем в thread-per-connection. В жабе собственно называется NIO - для того и придумали. С другой стороны треды на io-блокировке и так ресурсов особо не занимают так что выигрышь может и не быть.

Так тут ситуация такая что в Java используются треды VM, треды ОС применяются только в RealTIme Java и только для RealTime тредов. Таким образом получается что однопоточный сервер на poll/select будет лисапедом повторяющим уже готовую реализацию.

С java NIO дело не имел - мне бизнес-логику нужно сделать, что там внизу не интересно ибо интерес это человеко-дни которые ограничены.

>> КАК на эти запросы успевать отвечать, если сервер однопоточный, а значит 7 из 8 ядер стоят? И как может однопоточный сервер работать быстрее многопоточного на большом количестве обращений? Вероятно никак, а значит производительные приложения нужно писать на многопоточных платформах ;)

как правило молча. Если у тебя блокирующиеся запросы - то собственно кроме создания потоков/процессов вариантов не много.

Запросы не блокирующие. Блокировки, если и есть, есть только на уровне СУБД. само приложение в 99% неблокирующее. Оптимистичная стратегия блокировок однако ;)

А если у тебя дофига достаточно долго выполняющихся запросов, при этом можно послать запрос и результат будет доступен по какому-то событию (select, poll, kevent, etc) - то зачем плодить второй поток когда можно сохранить текущее состояние и начать выполнять другое?

Кому посылать запрос? нам пришел запрос - на него нужно выполнить описанные в ТЗ шаги и выдать ответ. Шаги довольно простые - проверить валидность пакета, валидность данных, права доступа текущего пользователя к запрашиваемым данным, еще рад бизнес моментов типа наступило ли время обеда (если наступило, то выдать команду - марш на обед). После этого наше приложение формирует ответ и отправляет. Либо на PDA-подобное устройство либо на другой сервер.

так что нужно размазать нагрузку по всем CPU чтобы в сервер влезло как можно больше абонентов.

> Увы...) Весь этот словарный сахар бесполезен) Прогер пишет на том за что платят деньги, все остальное не имеет никакого смысла) Если есть выбор, то тут дело религии, не пересекающейся с реальной действительностью)

Это как искать. Выбор есть всегда - можно сменить компанию где работаешь и найти ту где платят за интересный тебе язык.

Так я изучил и перешел на java.

PS в соседний отдел набирают Linux-оидов для программирования под MeGoo. Было бы желание - С/С++ найдется ;)

> Читая написанное - ДА.

С чего вы это решили?

Так есть клиенты которые ходят на 80 порт + 443. И что мне самостоятельно разбираться как их раскидать по тредам-обработчикам?

Не понял.

> Фиг с ним пусть мы сетевые соединения (коих в параллель довольно много) каким то образом засунули в файловые дескриптеры.

У меня плохие новости. Вы полный неуч. Практически вы тот самый карикатурный явафил, который *ничего* не знает о жизни за границей Java VM, но всех учит, как надо жить и какие у него хорошие (а у остальных --- плохие) инструменты.

Добро поджаловать в игнор, мне хватает студентов как плацдарма для ликбеза. Надеюсь, r более культурен и терпелив, возможно он вас просветит.

>Если считать что тред в ядре не потребляет ничего - то да, если подумать что ядру нужны ресурсы под тред, то лучше вернуться к FSM

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

>А дальше что? пришло два запроса в одну еденицу времени. Их нужно обработать параллельно ибо бОльшая часть работы по обоим запросам полностью независима.

А теперь вернемся к тому что у тебя не реальный параллелизм, а псевдо. На чем собственно процессор у тебя простаивает? На блокированном IO, и псевдо решает эту проблему. На чем он теряет? На переключениях контекста. А теперь представь что у тебя _нет_ блокировок на IO - то есть IO ты выполняешь когда оно реально доступно. select тебя реально тут и спасает - он дает тебе только те дескрипторы в которых в данный момент реально можно что-то прочитать из сети - и ты читаешь ровно столько сколько там есть. То есть твой поток максимально утилизирует IO и процессор и никогда на нем не простаивает, одновременно экономя на переключении контекстов. Вариант архитектуры подобного сетевого сервиса такой (по шагам)
1. есть висячий серверный сокет. если там что-то есть - создать клиентский дескриптор добавить в список.
2. пробежать по списку клиенских дескрипторов которые вернул select для чтения. прочитать что там есть в ассоциированные входные буффера.
3. если в очередном буфере есть что-то осмысленное (весь запрос считан из сокета) - вызвать обработку запроса.
4. обработка запроса запишет в исходящий буфер результатю
5. пробежаться по списку дескрипторов которые вернул select как готовые к записи и переписать содержимое исходящего буфера.
goto 1.

Может вы мне доку какую дадите чтобы объяснить этот факт.

Такие сервисы существуют 100 лет. Самое распространенное применение в MUDах. Абсолютно однопроцесные сервера обслуживащие кучи параллельных персистентных соединений.