Здравствуйте, Quintanar, Вы писали:

Q>Здравствуйте, Mirrorer, Вы писали:

M>>А применро что подразумевается под "сервером помощнее" для задачи такого размера под управлением kdb+ ? Я конечно понимаю, что все depends. Но хотя бы плюс-минус трамвайная остановка.

Q>Так в целом ничего особенного — 8 процессоров, 128Г памяти, террабайт 8 диска (если нужно данные долго хранить).

Все бы хорошо, только цена этого добра? и как я понял, схема лицензирования kdb+ очень необычная. Они сдают ПО в аренду.

Здравствуйте, Gerasim.mu, Вы писали:

GM>Все бы хорошо, только цена этого добра? и как я понял, схема лицензирования kdb+ очень необычная. Они сдают ПО в аренду.

Для фирмы с 50м клиентов цена не должна быть неподъемной, тот же Оракл, вроде, не сильно дешевле.

GM>>Все бы хорошо, только цена этого добра? и как я понял, схема лицензирования kdb+ очень необычная. Они сдают ПО в аренду.
Q>Для фирмы с 50м клиентов цена не должна быть неподъемной, тот же Оракл, вроде, не сильно дешевле.

Вы правы. Но разработка продуктовая, не под конкретную фирму, и эти данные взяты как ориентир одного из существующих клиентов.
Поэтому низкая цена необходимого системного ПО и оборудования дает преимущество в тендерах.
Грубо говоря: Выгодней потратить 1 млн долларов на разработку, чем для каждой инсталляции, вынуждать клиента покупать за 1 млн нечто обязательное.

Цены приведены как абстрактный пример. Просто хочу, что бы моя мысль была правильно понята.

Здравствуйте, Gerasim.mu, Вы писали:

GM>Что скажете, Уважаемые?
Эрланг животное тепличное.
А при выезде в поле... короче у нас мужики так и не добились чтобы эрланговый кластер стабильно работал в двух датацентрах.
Хотя в одном както живет.

Здравствуйте, WolfHound, Вы писали:

А что смешного то?

Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, WolfHound, Вы писали:

WH>А что смешного то?

Ну просто если "мужики" не смогли заставить эрланговое решение работать, то это вызывает лишь улыбку или по поводу их квалификации или по поводу качества того продукта, который они запускали...
Это лишь моё мнение, не претендующее на какую-либо объективность (вроде для этого и придуманы оценки на рсдн)

Здравствуйте, Курилка, Вы писали:

К>Ну просто если "мужики" не смогли заставить эрланговое решение работать,
Не решение на эрланге, а эрланг.
Разницу чувствуешь?
В одном датацентре работает. Подняли несколько нод в другом хваленый эрланговский рантайм начал отвисать.
Не любит он на другой конец города через роутеры ходить...
Правда у нас тут еще и нагрузка не рядовая.

К>то это вызывает лишь улыбку или по поводу их квалификации или
Нормальная у них квалификация.

К>по поводу качества того продукта, который они запускали...
С качеством у эрланга действительно проблемы.

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

Здравствуйте, WolfHound, Вы писали:

WH>Не любит он на другой конец города через роутеры ходить...
Забудь про это сразу. Для географической кластеризации и WAN подходы типа встроенного Erlang'овского почти не подходят.

Я перепробовал кучу разных продуктов (от распределённых кэшей до всяких grid-вычислителей) — оно всё дохнет при соединении через что-либо, отличное от свитча+роутера.

WH>Еще народ мне почему то очень любит не верить когда я говорю что линуховый шедуллер при определенных сценариях нагрузки сваливается в кому...
Новый scheduler? Т.е. тот который Completely Fair?

Тогда это баги (а где их нет?). У меня на нём в нагрузочном тесте 2000 потоков работали идеально.

Здравствуйте, Cyberax, Вы писали:

C>Забудь про это сразу.
Да я этой системой и не занимаюсь.
Просто соседи жаловались на то что супер мега эрланг на такой фигне загнулся...

C>Для географической кластеризации и WAN подходы типа встроенного Erlang'овского почти не подходят.
У нас просто требование для всех проектов жить после смерти одного датацентра.

C>Я перепробовал кучу разных продуктов (от распределённых кэшей до всяких grid-вычислителей) — оно всё дохнет при соединении через что-либо, отличное от свитча+роутера.
Ты это Курилке раскажи. А то ведь не верит.

C>Новый scheduler? Т.е. тот который Completely Fair?
Он в debian sarge уже был или еще нет?

C>Тогда это баги (а где их нет?). У меня на нём в нагрузочном тесте 2000 потоков работали идеально.
А ты только процессор грузил или IO то же добавлял?
А то у нас пришлось логи на некоторых нодах кластера отрубить иначе они ядро в кому загоняют. Вернее они становятся последней каплей.

Здравствуйте, WolfHound, Вы писали:

C>>Тогда это баги (а где их нет?). У меня на нём в нагрузочном тесте 2000 потоков работали идеально.
WH>А ты только процессор грузил или IO то же добавлял?
WH>А то у нас пришлось логи на некоторых нодах кластера отрубить иначе они ядро в кому загоняют. Вернее они становятся последней каплей.

Да есть, такое. У нас Линукс адски тормозить начинает, когда диска остается мало. И как-то не очень понятно почему (память особо не занята, но очень интенсивно используется сеть и все процессоры).

Здравствуйте, WolfHound, Вы писали:

C>>Для географической кластеризации и WAN подходы типа встроенного Erlang'овского почти не подходят.
WH>У нас просто требование для всех проектов жить после смерти одного датацентра.
Это надо репликацию делать на более высоком уровне. Например, я в итоге остановился на асинхронной репликации базы для readonly-реплик с автоматическим выбором мастер-копии.

C>>Я перепробовал кучу разных продуктов (от распределённых кэшей до всяких grid-вычислителей) — оно всё дохнет при соединении через что-либо, отличное от свитча+роутера.
WH>Ты это Курилке раскажи. А то ведь не верит.
Могу рассказать.

C>>Новый scheduler? Т.е. тот который Completely Fair?
WH>Он в debian sarge уже был или еще нет?
Ещё нет. У того, который был в Sarge (и Etch без последних апдейтов), внутри стояли жуткие эвристики, которые иногда взрывались при правильном сочетании созвездий.

C>>Тогда это баги (а где их нет?). У меня на нём в нагрузочном тесте 2000 потоков работали идеально.
WH>А ты только процессор грузил или IO то же добавлял?
IO тоже добавлял (работа с БД), но в разумных количествах.

WH>А то у нас пришлось логи на некоторых нодах кластера отрубить иначе они ядро в кому загоняют. Вернее они становятся последней каплей.
Если это Debian Sarge — то да, там у планировщиков IO и процессора были странные взаимодействия. Я на это натыкался.

Здравствуйте, Cyberax, Вы писали:

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

C>Ещё нет. У того, который был в Sarge (и Etch без последних апдейтов),
А с какой версии оно появилось?

C>внутри стояли жуткие эвристики, которые иногда взрывались при правильном сочетании созвездий.
C>Если это Debian Sarge — то да, там у планировщиков IO и процессора были странные взаимодействия. Я на это натыкался.
Ну тогда ускорим переползание на последний Etch.
Может поможет.

Здравствуйте, WolfHound, Вы писали:

C>>Это надо репликацию делать на более высоком уровне. Например, я в итоге остановился на асинхронной репликации базы для readonly-реплик с автоматическим выбором мастер-копии.
WH>Я знаю как это надо делать.
WH>Причем нужно понимать что в разных случаях это надо делать по разному.
Угу, естественно.

C>>Ещё нет. У того, который был в Sarge (и Etch без последних апдейтов),
WH>А с какой версии оно появилось?
С версии ядра 2.6.23. С версии 2.6.24 оно даже стало нормально работать.

Вот тут первые benchmark'и: http://kerneltrap.org/Linux/Additional_CFS_Benchmarks — у CFS почти идеальная масштабируемость.

C>>Если это Debian Sarge — то да, там у планировщиков IO и процессора были странные взаимодействия. Я на это натыкался.
WH>Ну тогда ускорим переползание на последний Etch.
WH>Может поможет.
Обязательно посмотрите, что ядро 2.6.24 поставили (оно в обновлении etchnhalf, вышедшем на прошлой неделе). Иначе смысла перелезать нет.