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

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

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

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

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

Добрый день всем!

Не программировал уже года три (сам С++ ник). Сейчас занимаюсь больше продукт менеджментом и прочей красивой ерундой.
На горизонте есть Задача. Которую, как мне кажется, нужно решать выйдя за круг своих предыдущих знаний (не создавать велосипеды на С++). Может быть Erlang, которым я проникся за последние два дня, мне поможет?

Описываю задачу:

Исходные данные:
1. Есть база данных с 50 млн клиентов.
2. Каждый клиент владеет в среднем двумя устройствами генерации трафика (телефон, GPRS модем и т.д.) Итого: 100 млн устройств.
3. Максимальное количество устройств на одного клиента — 100 тыс. Минимальное — 1 (одна штука).
4. Для каждого клиента, в системе, хранится баланс.
5. В день, клиенты генерируют 150-200 млн событий.
6. В часы наибольшей нагрузки приходится 2 события на одного клиента.
7. На каждое событие, приходится три обращения к балансу клиента (получить значение и обновить значение — это одно обращение)
8. Интерфейс со стороны сторонних систем TCP/IP.

---------------
Краткие требования.
1. 99.999
2. Скорость обработки одного запроса в интервале от [0.25..1] миллисекунды.
3. Потеря даже одной команды списания баланса невозможна.


Предположения
--------------
1. В память одного компа все не влезет. Фактически речь идет об необходимости распределенной in-memory DB.
2. Необходима горячая замена серверов в кластере.
3. Все команды по получению, предварительно писать на диск, или передавать на другой сервер.


Что скажете, Уважаемые?

Здравствуйте, Gerasim.mu, Вы писали:
GM>Описываю задачу:

GM>Исходные данные:
GM>1. Есть база данных с 50 млн клиентов.
.....
GM>5. В день, клиенты генерируют 150-200 млн событий.
GM>6. В часы наибольшей нагрузки приходится 2 события на одного клиента.

Ну ясно что не mnesia. Не потянет.

Здравствуйте, http://walrus16.blogspot.com/, Вы писали:

HWB>Здравствуйте, Gerasim.mu, Вы писали:
GM>>Описываю задачу:

GM>>Исходные данные:
GM>>1. Есть база данных с 50 млн клиентов.
HWB>.....
GM>>5. В день, клиенты генерируют 150-200 млн событий.
GM>>6. В часы наибольшей нагрузки приходится 2 события на одного клиента.

HWB>Ну ясно что не mnesia. Не потянет.

Интересно, откуда дровишки?
К примеру есть это, плюс тут само собой напрашивается партиционирование данных (т.е. не надо всё сразу хранить в одной базе). В общем — надо архитекторить + писать прототипчики.

Здравствуйте, http://walrus16.blogspot.com/, Вы писали:

GM>>Исходные данные:
GM>>1. Есть база данных с 50 млн клиентов.
HWB>.....
GM>>5. В день, клиенты генерируют 150-200 млн событий.
GM>>6. В часы наибольшей нагрузки приходится 2 события на одного клиента.

HWB>Ну ясно что не mnesia. Не потянет.

Не факт. Если они генерируют 200 млн за день в сумме, то это не так уж и много. Пик — 100 млн. в час, то есть 70 тыс/сек — это уже хуже. Мнезия конечно тормозная, но подергаться есть куда.
1) Применить memory-only таблицы и 64-битный Эрланг. В этом случае снимается ограничение на 2Gb-таблица.
2) Раскидать таблицы по разным машинам, устроить дублирование каждой порции на второй машине, устроив там резервные копии.
3) Аккуратно посмотреть, где можно применить dirty-транзакции, и как избежать распределенных блокировок.
4) Зацепить машины кластера какой-нибудь низколатентной сеткой, например FibreChannel или коммутатором InfiniBand. Это может поправить скорость транзакций.
5) Померять это на прототипе.
6) В крайнем случае — отказаться от мнезии. Все равно изобразить такое на Эрланге будет проще.

А вот насчет задержки обработки отдельного сообщения до 1 миллисекунды — я совсем не уверен, сможет ли Эрланг такое дать. Это вообще гарантировать тяжело, учитывая задержки в TCP/IP, и размер кванта оперсистемы в 10-15 msec.

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

G>А вот насчет задержки обработки отдельного сообщения до 1 миллисекунды — я совсем не уверен, сможет ли Эрланг такое дать. Это вообще гарантировать тяжело, учитывая задержки в TCP/IP, и размер кванта оперсистемы в 10-15 msec.

По идее были где-то в листе обсуждения по поводу добавления наносекундных таймеров (на поддерживающих такое ОС, правда я не знаю какие это)

Всем большое спасибо за участие, коменты внизу.


G>Не факт. Если они генерируют 200 млн за день в сумме, то это не так уж и много. Пик — 100 млн. в час, то есть 70 тыс/сек — это уже хуже. Мнезия конечно тормозная, но подергаться есть куда.
G>1) Применить memory-only таблицы и 64-битный Эрланг. В этом случае снимается ограничение на 2Gb-таблица.
G>2) Раскидать таблицы по разным машинам, устроить дублирование каждой порции на второй машине, устроив там резервные копии.
G>3) Аккуратно посмотреть, где можно применить dirty-транзакции, и как избежать распределенных блокировок.
G>4) Зацепить машины кластера какой-нибудь низколатентной сеткой, например FibreChannel или коммутатором InfiniBand. Это может поправить скорость транзакций.
G>5) Померять это на прототипе.
G>6) В крайнем случае — отказаться от мнезии. Все равно изобразить такое на Эрланге будет проще.

А если не 64 битный? Я правда еще не считал разницу в стоимости хранении одного клиента, при использовании 32 или 64 битных серверов. Попробую узнать во сколько обходится хранение 1 млн клиентов. То есть все таки использовать Мнезию предлагаете? Хотя бы начать строить прототип с ее использованием? А вот такой вопрос тогда. В любом случае, информацию нужно регулярно скидывать на диск, хотя бы раз в биллинговый период. Это средствами мнезии ведь тоже возможно?

G>А вот насчет задержки обработки отдельного сообщения до 1 миллисекунды — я совсем не уверен, сможет ли Эрланг такое дать. Это вообще гарантировать тяжело, учитывая задержки в TCP/IP, и размер кванта оперсистемы в 10-15 msec.

Упс, сорри моя опечатка: от 0.25 до 1 секунды.

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

GM>Описываю задачу:

GM>Исходные данные:
GM>1. Есть база данных с 50 млн клиентов.
GM>2. Каждый клиент владеет в среднем двумя устройствами генерации трафика (телефон, GPRS модем и т.д.) Итого: 100 млн устройств.
GM>3. Максимальное количество устройств на одного клиента — 100 тыс. Минимальное — 1 (одна штука).
GM>4. Для каждого клиента, в системе, хранится баланс.
GM>5. В день, клиенты генерируют 150-200 млн событий.
GM>6. В часы наибольшей нагрузки приходится 2 события на одного клиента.
GM>7. На каждое событие, приходится три обращения к балансу клиента (получить значение и обновить значение — это одно обращение)
GM>8. Интерфейс со стороны сторонних систем TCP/IP.

GM>---------------
GM>Краткие требования.
GM>1. 99.999
GM>2. Скорость обработки одного запроса в интервале от [0.25..1] миллисекунды.
GM>3. Потеря даже одной команды списания баланса невозможна.


GM>Предположения
GM>--------------
GM>1. В память одного компа все не влезет. Фактически речь идет об необходимости распределенной in-memory DB.
GM>2. Необходима горячая замена серверов в кластере.
GM>3. Все команды по получению, предварительно писать на диск, или передавать на другой сервер.


Похоже на систему обработки биржевых данных с небольшими нюансами. У нас она решается парой серверов с базой данных kdb+. Начальные условия похожи — более 200 миллионов сообщений в день (в основном за 8 часов работы биржи), в США так даже уже под миллиард сообщений (если считать не только трейды/квоуты но и служебные). Все данные обязательно сохраняются на диск по мере поступления, это довольно стандартный прием, поскольку в случае каких-либо проблем их надо уметь восстановить. Данные, конечно, хранятся в памяти и ничего особенного в базе данных на 200 миллионов не вижу, проблема решается установкой сервера помощнее. Разница в том — что нужно апдейтить баланс, а не добавлять новые данные в конец базы данных. Я сейчас попробовал — апдейт для таблицы с миллионом элементов работает со скоростью 1000 апдейтов за 5 миллисекунд, т.е. достаточно быстро. Задача распределения нагрузки решается достаточно просто средствами самого kdb+, проблема отказа — установкой дублирующих серверов. В общем, задача кажется в чем-то даже более простой, поскольку мы эти данные еще и клиентам предоставляем, которые исполняют достаточно сложные запросы, т.е. большую часть времени сервер занят ими.
Но на все это счастье требуется Бабло и на сам Kdb+ и на серверы. Хотя, опять же, вам, например, не надо столько места на диске сколько нам (для хранения данных за несколько лет), т.е. экономия.

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

GM>А если не 64 битный? Я правда еще не считал разницу в стоимости хранении одного клиента, при использовании 32 или 64 битных серверов. Попробую узнать во сколько обходится хранение 1 млн клиентов. То есть все таки использовать Мнезию предлагаете? Хотя бы начать строить прототип с ее использованием? А вот такой вопрос тогда. В любом случае, информацию нужно регулярно скидывать на диск, хотя бы раз в биллинговый период. Это средствами мнезии ведь тоже возможно?
GM>Упс, сорри моя опечатка: от 0.25 до 1 секунды.

Что-то у вас запросы совсем несерьезные, чувствую, что и Эрланга вполне достаточно.

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

GM>А если не 64 битный? Я правда еще не считал разницу в стоимости хранении одного клиента, при использовании 32 или 64 битных серверов. Попробую узнать во сколько обходится хранение 1 млн клиентов.

Да, лучше наверное начать с этого.

GM>То есть все таки использовать Мнезию предлагаете? Хотя бы начать строить прототип с ее использованием?

Прототип на базе Мнезии для этой задачи сделать должно быть очень просто. Сложно — выжать из него требуюмую производительность, придется как следует постараться, и не факт что получится. Но учитывая, что прототип собирается очень быстро, я бы — попробовал.

В случае неудачи — я бы стал пробовать сделать свое распределенное хранилище на базе ets.

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

Вполне возможно, если указхать тип таблицы disc_copies. В этом случае, таблица точно также будет хранится в памяти, только изменения будут сбрасываться в журнал на диске, это достаточно эффективно.

G>>А вот насчет задержки обработки отдельного сообщения до 1 миллисекунды — я совсем не уверен, сможет ли Эрланг такое дать. Это вообще гарантировать тяжело, учитывая задержки в TCP/IP, и размер кванта оперсистемы в 10-15 msec.

GM>Упс, сорри моя опечатка: от 0.25 до 1 секунды.

А, ну это должно получиться без проблем.

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

Q>Данные, конечно, хранятся в памяти и ничего особенного в базе данных на 200 миллионов не вижу, проблема решается установкой сервера помощнее.

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

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

GM>2. Скорость обработки одного запроса в интервале от [0.25..1] миллисекунды.
GM>3. Потеря даже одной команды списания баланса невозможна.
. . . .
GM>3. Все команды по получению, предварительно писать на диск, или передавать на другой сервер.

А как можно физически за это время что-то там успеть записать на диск, если даже у самых быстрых и хороших дисков seek time — порядка 5 миллисекунд?

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

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

GM>>2. Скорость обработки одного запроса в интервале от [0.25..1] миллисекунды.
GM>>3. Потеря даже одной команды списания баланса невозможна.
Pzz> . . . .
GM>>3. Все команды по получению, предварительно писать на диск, или передавать на другой сервер.

Pzz>А как можно физически за это время что-то там успеть записать на диск, если даже у самых быстрых и хороших дисков seek time — порядка 5 миллисекунд?

Я предполагал:
1. Команды на изменение баланса приходят в асинхронном режиме. То есть, с момента приема команды, проблема обеспечения консистентности и надежности — проблема разрабатываемой системы.
2. Серверов будет в любом случае больше одного и винтов можно использовать несколько (тут тоже распараллеливать). В Oracle похожий механизм это Redo файлы.

Сохранение предполагается для восстановления при сбое. Как вариант рассматривается передача данного сообщения на другой сервер, что бы он там в памяти хранился (опять таки аналог Oracle StandBy только не файлами а сообщениями по сети). Но как вы уже заметили, сложно выйти за круг своих знаний по C++. нужно образ мышления менять

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

GM>Я предполагал:
GM>1. Команды на изменение баланса приходят в асинхронном режиме. То есть, с момента приема команды, проблема обеспечения консистентности и надежности — проблема разрабатываемой системы.
GM>2. Серверов будет в любом случае больше одного и винтов можно использовать несколько (тут тоже распараллеливать). В Oracle похожий механизм это Redo файлы.

Распараллеливание может увеличить скорость линейного чтения/записи и позволить исполнять несколько запросов одновременно (т.е., увеличить количество запросов, которые вы в состоянии выполнить за единицу времени). Однако от seek time вы никуда не денетесь, и каждый отдельный запрос, сколько бы их одновременно не выполнялось, будет ограничен снизу этим временем. Это аналогично тому, что 10 тёток могут родить 10 детей за 9 месяцев, но не могут родить одного ребенка за месяц.

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

Кроме того, даже при последовательной записи не так-то просто понять, когда данные уже точно оказались на диске, потому что их буферизует и операционная система и диск, а если вы выключите эту буферизацию, вы будете писать по сектору за раз, с интервалами порядка времени оборота диска. В UNIX'е узнать это по-моему вообще невозможно из user space (кроме как ценой сказать fsync() на файл и дождаться, когда все буферизованные данные окажутся на диске, но это займет больше 1 миллисекунды). В венде теоретически возможно, используя overlapped i/o, но работает ли это на практике, я не уверен, и ответ на этот вопрос из документации не выводится.

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

GM>Сохранение предполагается для восстановления при сбое. Как вариант рассматривается передача данного сообщения на другой сервер, что бы он там в памяти хранился (опять таки аналог Oracle StandBy только не файлами а сообщениями по сети). Но как вы уже заметили, сложно выйти за круг своих знаний по C++. нужно образ мышления менять

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

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

Pzz>Единственный способ преодолеть это ограничение — это писать все поступающие запросы на диск последовательно — seek будет происходить лишь когда вы дошли до конца дорожки на диске и переходите на следующую, т.е. далеко не на каждый запрос. Но это очень не похоже на то, что делают с дисками базы данных.
Вариант решения аппаратный: для redo-диска взять SDD. Время поиска меньше миллисекунды.

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

Pzz>>Единственный способ преодолеть это ограничение — это писать все поступающие запросы на диск последовательно — seek будет происходить лишь когда вы дошли до конца дорожки на диске и переходите на следующую, т.е. далеко не на каждый запрос. Но это очень не похоже на то, что делают с дисками базы данных.
C>Вариант решения аппаратный: для redo-диска взять SDD. Время поиска меньше миллисекунды.

Можно, да. Но они маленькие, дорогие, и в них при интенсивном использовании протираются дырки. Зато время доступа predictable, в отличии от механического диска.

Можно еще просто RAM взять с автономным питанием — наверняка в природе существует такое железо с дисковым интерфейсом.

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

Pzz>Можно, да. Но они маленькие, дорогие, и в них при интенсивном использовании протираются дырки. Зато время доступа predictable, в отличии от механического диска.
1) Для redo-диска много места не надо.
2) Уже не дорогие. Одна модель на 128GB стоит $550.
3) Дырки уже давно не протираются, это сказки.

Pzz>Можно еще просто RAM взять с автономным питанием — наверняка в природе существует такое железо с дисковым интерфейсом.
Есть.

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

C>2) Уже не дорогие. Одна модель на 128GB стоит $550.

Ух ты! 128G за $550 — это очень соблазнительная цена.

C>3) Дырки уже давно не протираются, это сказки.

А сколько циклов записи выдерживают современные флешки?

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

C>>2) Уже не дорогие. Одна модель на 128GB стоит $550.
Pzz>Ух ты! 128G за $550 — это очень соблазнительная цена.
Ага. Я себе купил, сейчас сижу и радуюсь.

C>>3) Дырки уже давно не протираются, это сказки.
Pzz>А сколько циклов записи выдерживают современные флешки?
Около 500000 на ячейку. Но это не важно, так как там микроконтроллер делает аппаратный wear levelling. При постоянной записи 24x7 срок службы более 5 лет.

Pzz>>Можно еще просто RAM взять с автономным питанием — наверняка в природе существует такое железо с дисковым интерфейсом.
C>Есть.

Да есть такая штука. Но она увеличивает стоимость "одной транзакции" и "стоимость хранения одной записи".
А по поводу последовательной записи — да, я согласен. Скорость будет выше.

Просто как вариант, я рассматриваю следующий вариант:
передача сообщений идет сквозь несколько серверов, на промежуточном сервере она хранится только в ОЗУ, а запись на диск идет только на последнем.

client->Server1->Server2->Server3 (запись на HDD только тут)

P.S.
углубляюсь в эранг, может есть решение изящней.

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

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

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

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

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

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

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

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

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

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

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

Здравствуйте, 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, вышедшем на прошлой неделе). Иначе смысла перелезать нет.