Discussion:
SuperClassic
(too old to reply)
Alexey Popov
2009-12-09 14:53:30 UTC
Permalink
Насколька я понял, сабжевая архитектура - это объединение процессов
классика в один процесс?
Плюсы: многопоточная работа с базой, потенциально более масштабируем чем
классик.

Но это всё ещё не то, чего хочется. Сейчас проблема в том, что суперсервер
из за кривизны кода плохо параллелится по разным потокам. Тем не менее
суперсервер за счёт единого кэша весьма эффективен и быстр.
Давайте сделаем такую архитектуру: гибрид классика и супера.
1) Каждый процесс классика будет обрабатывать произвольное количество
соединений как сейчас суперсервер делает в режиме сериализации
с псевдопараллелизмом.
2) Заранее запускаем N экземпляров процессов классика, по числу ядер
или меньше.
3) Менеджер соединений передаёт коннекты от пользователей экземплярам
классика с целью равномерного распределения нагрузки.

Либо такая интерпретация: доработать суперсервер так, чтобы он мог
расшаривать работу с базой с другим инстансами суперсервера по принципу
работы классика.
Dmitry Yemanov
2009-12-09 17:30:41 UTC
Permalink
Post by Alexey Popov
суперсервер за счёт единого кэша весьма эффективен и быстр
Это скорее теорема, чем аксиома...
Post by Alexey Popov
Давайте сделаем такую архитектуру: гибрид классика и супера
Может лучше таки параллельную работу с общим кешем?
--
Дмитрий Еманов
Alexey Popov
2009-12-10 08:56:39 UTC
Permalink
Post by Dmitry Yemanov
Post by Alexey Popov
суперсервер за счёт единого кэша весьма эффективен и быстр
Это скорее теорема, чем аксиома...
Разнесённый кэш мне не ещё нравится тем, что быстро выжирает
память. Различные процессы классика конкурируют и вытесняют горячие данные
из кэша процессора, который нерезиновый.
Post by Dmitry Yemanov
Post by Alexey Popov
Давайте сделаем такую архитектуру: гибрид классика и супера
Может лучше таки параллельную работу с общим кешем?
Это конечно идеальный вариант, но требует больше переработок. Как я себе
представляю проблема в большом количестве legacy code, который не может
выполняться сразу несколькими потоками. Чисто теоретически, read only
запросы при полном попадании в кэш должны очень хорошо параллелится.

Что же касается вытесняющей многозадачности на одном ядре, то в идеале надо
делать свой шедулер потоков и ресурсов. Потому что надо эффективно
управлять приоритетом. Например, в одном соединении запускается
долгоиграющий запрос, а другое соединение хочет выполнять короткие быстрые
запросы. Первое соединение после n секунд выполнения запроса должно
принудительно быть понижено в приоритете.
Аналогично между соединениями должна по братски распределяться полоса
пропускания IO, память.
Dmitri Kuzmenko
2009-12-10 18:20:25 UTC
Permalink
Hello, Alexey!
Post by Alexey Popov
Насколька я понял, сабжевая архитектура - это объединение процессов
классика в один процесс?
не совсем.
Post by Alexey Popov
Но это всё ещё не то, чего хочется. Сейчас проблема в том, что суперсервер
из за кривизны кода плохо параллелится по разным потокам.
он вообще не параллелится, и не из-за кривизны, а из-за архитектуры.
Post by Alexey Popov
Давайте сделаем такую архитектуру: гибрид классика и супера.
ты бы пару лет назад это написал. А теперь уже поздно.
Post by Alexey Popov
Первое соединение после n секунд выполнения запроса должно
принудительно быть понижено в приоритете.
с какого буя? С приоритетами уже баловались, на классике.

В общем, "я из лесу вышел..." :-)
--
Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Kovalenko Dmitry
2009-12-10 18:43:16 UTC
Permalink
Post by Dmitri Kuzmenko
Post by Alexey Popov
Но это всё ещё не то, чего хочется. Сейчас проблема в том, что
суперсервер
из за кривизны кода плохо параллелится по разным потокам.
он вообще не параллелится, и не из-за кривизны, а из-за архитектуры.
На супере 2.5 независимые базы нормально параллельно работают. Я года назад
очень активно с этим игрался.

А потом, когда замутил многопоточную тестовую систему - перешел на одну
базу. И то, если мне не изменяли глаза, супер умудрялся выжирать чуть больше
одного ядра (~30% на четырехядернике). При 8 тестовых потоках.

Честное пионерское. Мне сказали - возможно это асинхронное I/O. Да и по
любому - в рамках одной базы одно время были грабли с многопоточностью.
Значит он (супер) таки что то там делает параллельно. Грабли исчезли где то
с начала прошедшей оcени. Причем все - и у FB, и у Висты c новыми дисками :)

[стучу по дереву]

Но щас пересел на суперклассик. И пруся от нереальной загрузки процессора :)

Вот.
Коваленко Дмитрий.
Dmitry Lendel
2009-12-11 09:04:52 UTC
Permalink
Post by Kovalenko Dmitry
А потом, когда замутил многопоточную тестовую систему - перешел на одну
базу. И то, если мне не изменяли глаза, супер умудрялся выжирать чуть
больше одного ядра (~30% на четырехядернике). При 8 тестовых потоках.
А что она тестила?
CTE не пробовал джойнить с немерянными таблицами?

Дмитрий
Kovalenko Dmitry
2009-12-11 09:48:14 UTC
Permalink
Post by Dmitry Lendel
Post by Kovalenko Dmitry
А потом, когда замутил многопоточную тестовую систему - перешел на одну
базу. И то, если мне не изменяли глаза, супер умудрялся выжирать чуть
больше одного ядра (~30% на четырехядернике). При 8 тестовых потоках.
А что она тестила?
Конвертирование текстовых данных (блобы, массивы, обычные колонки) в разных
мутанских комбинациях кодовых страниц, форматов и размеров данных.
Фактически, проверяется каждая буква определенного набора кодовых страниц в
разных позах (WIN1251 тоже проверям :) )

То есть _дофига_ простых операций по чтению, записи и удалению.

Багов они поймали ... ну типа много :)

Да и щас вот ... интересную картину показывают :))

Там еще другие веселые тесты есть.
Post by Dmitry Lendel
CTE не пробовал джойнить с немерянными таблицами?
Не, CTE я вообще ни разу не юзал :))

Максимум - это у нас юзаются EB которые проверяют какую то формулу с датами.

Коваленко Дмитрий.

PS. Желающим поигратсо
- качаем триал провайдера (тока щас обновил, свеженький)
- собираем тесты TestCode\ActiveX\IBP\oledb_test (VS2008 желательно)
- генерим базу TestCode\ActiveX\IBP\test_database

И насилуем FB (вместе со своим компутером) :-)))

Особенно приветствуются четырех и более ядерные монстры :-)))))
Alexey Popov
2009-12-11 09:20:59 UTC
Permalink
Post by Kovalenko Dmitry
На супере 2.5 независимые базы нормально параллельно работают. Я года
назад очень активно с этим игрался.
Интересно насколько параллельно. Как я помню по FB1.0 банальный yacc
выдавал нереентабельный парсер.
Post by Kovalenko Dmitry
А потом, когда замутил многопоточную тестовую систему - перешел на одну
базу. И то, если мне не изменяли глаза, супер умудрялся выжирать чуть
больше одного ядра (~30% на четырехядернике). При 8 тестовых потоках.
Ну много потоков там всегда создавалось. Вопрос в том, что в большенстве
случает работал только один.
Kovalenko Dmitry
2009-12-11 09:59:47 UTC
Permalink
Post by Alexey Popov
Post by Kovalenko Dmitry
На супере 2.5 независимые базы нормально параллельно работают. Я года
назад очень активно с этим игрался.
Интересно насколько параллельно.
Запусти и посмотри сам :)
Post by Alexey Popov
Как я помню по FB1.0 банальный yacc выдавал нереентабельный парсер.
Я на днях всю линейку мучал. IB4-IB9, FB0.9-FB2.5

Жизнь начинается с IB7 / FB1.5.

Коваленко Дмитрий.
Sergey Mereutsa
2009-12-11 10:37:15 UTC
Permalink
Превед!
Post by Alexey Popov
Интересно насколько параллельно. Как я помню по FB1.0 банальный yacc
выдавал нереентабельный парсер.
Reentrant - если уж использовать кальку - то реентрабельный или -
потокобезопасный. Ы?
--
Best regards,
Sergey mailto:gebelezis-***@public.gmane.org
Alexey Popov
2009-12-11 09:17:18 UTC
Permalink
Post by Dmitri Kuzmenko
Post by Alexey Popov
Но это всё ещё не то, чего хочется. Сейчас проблема в том, что
суперсервер
из за кривизны кода плохо параллелится по разным потокам.
он вообще не параллелится, и не из-за кривизны, а из-за архитектуры.
Насколько я помню из времён ковыряния к коде FB1.0 там
1) кооперативная многозадачаность. FB сам переодически переключается на
другой запрос.
2) много глобальных переменных.
3) блокировки
4) нереентабельный код.

В принципе на истинный параллелизм можно и забить, если бы кооперативная
многозадачность работала бы более качественно.
Post by Dmitri Kuzmenko
Post by Alexey Popov
Давайте сделаем такую архитектуру: гибрид классика и супера.
ты бы пару лет назад это написал. А теперь уже поздно.
"Никогда не поздно". Если посмотреть на перспективу, то даже если
суперсервер будет идеально параллелиться по ядрам, то полезно было бы
иметь возможность запускать несколько его процессов для:
1) надёжности от программных сбоев
2) загребания большего количества памяти (32бит лимит)
3) перспектив кластеризации и работы а железе где нет глобальной SMP.
Post by Dmitri Kuzmenko
с какого буя? С приоритетами уже баловались, на классике.
Запускаем на супере:
1) тяжёлый долгоиграющий запрос
2) в другом коннекте пускаем сверхкороткий.

В результате скорость отклика на короткие запросы существенно падает.
Для тяжёлого запроса пофиг сколько он будет выполняться 1 минуту, или 2.
А для коротких скорость отклика критична.
Поэтому введение приоритета явного или неявного напрашивается.
Dmitry Yemanov
2009-12-11 10:41:08 UTC
Permalink
Post by Alexey Popov
"Никогда не поздно". Если посмотреть на перспективу, то даже если
суперсервер будет идеально параллелиться по ядрам, то полезно было бы
иметь возможность запускать несколько его процессов
Другой разговор. Главное - определиться с приоритетами и не ставить это
во главу угла.
--
Дмитрий Еманов
Dmitri Kuzmenko
2009-12-11 10:48:18 UTC
Permalink
Hello, Alexey!
Post by Alexey Popov
Post by Dmitri Kuzmenko
ты бы пару лет назад это написал. А теперь уже поздно.
"Никогда не поздно". Если посмотреть на перспективу, то даже если
суперсервер будет идеально параллелиться по ядрам, то полезно было бы
в топку перспективу. Иди смотри FB 3.0. Потом возвращайся обратно.
Post by Alexey Popov
Post by Dmitri Kuzmenko
с какого буя? С приоритетами уже баловались, на классике.
1) тяжёлый долгоиграющий запрос
2) в другом коннекте пускаем сверхкороткий.
В результате скорость отклика на короткие запросы существенно падает.
мочи мочало, начинай сначала...
В IB2007/2009 на супере, кстати, таких проблем нет.
Post by Alexey Popov
Для тяжёлого запроса пофиг сколько он будет выполняться 1 минуту, или 2.
А для коротких скорость отклика критична.
Поэтому введение приоритета явного или неявного напрашивается.
якобы напрашивается.

В общем, ты бы для начала подковался по архивам fb-devel,
что сделано в 2.5, и что делается в 3.0. А потом с предложениями
приходил бы.

А то получается так - "чего там в 3.0 нафигачили я не знаю, но я
предлагаю вот так."
И разработчики быстро побежали менять архитектуру 3.0?
--
Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Alexey Popov
2009-12-12 17:00:24 UTC
Permalink
Post by Dmitri Kuzmenko
В общем, ты бы для начала подковался по архивам fb-devel,
Не читал, но осуждаю.
Post by Dmitri Kuzmenko
что сделано в 2.5, и что делается в 3.0. А потом с предложениями
приходил бы.
Про 2.5 вроде всё ясно. Про 3.0 где можно увидеть поподробнее, акромя fb-devel?
freemanzav
2009-12-15 12:43:14 UTC
Permalink
А почему я вижу только чёрточки и закорючки в некоторых с
Alex Cherednichenko
2009-12-15 12:51:11 UTC
Permalink
Hello, freemanzav!
You wrote on Tue, 15 Dec 2009 04:43:14 -0800 (PST):

f> А почему я вижу только чёрточки и закорючки в некоторых сообщениях
f> никто не не знает? :)

я знаю.
ты пользуешься (Ж)оперой.

--
With best regards, Alex Cherednichenko.
freemanzav
2009-12-15 13:20:10 UTC
Permalink
Post by Alex Cherednichenko
Hello, freemanzav!
 f> ޣ
 f> ? :)
.
( ) .
--
With best regards, Alex Cherednichenko.
Ничего не понятно
Alex Cherednichenko
2009-12-15 13:30:31 UTC
Permalink
f> Ничего не понятно

Не пользуйся (Ж)оперой.

--
With best regards, Alex Cherednichenko.
Игорь Горбонос
2009-12-15 13:48:15 UTC
Permalink
"freemanzav" сообщил/сообщила в новостях следующее:
Ничего не понятно

Tebe govoriat: HE polzuy Operu
:))
freemanzav
2009-12-15 14:32:15 UTC
Permalink
Post by freemanzav
Ничего не понятно
Tebe govoriat: HE polzu
Alex Cherednichenko
2009-12-15 15:00:05 UTC
Permalink
Hello, freemanzav!
You wrote on Tue, 15 Dec 2009 06:32:15 -0800 (PST):

[quot freemanzav] f> В фф так же[/quot]а в OE всё прекрасно.
news://news.gmane.org/gmane.comp.db.firebird.russian

скорее всего косяк в шлюзе между nntp-интерфейсом gmane
и web-мордой google groups.

--
With best regards, Alex Cherednichenko.
Vladimir A.Bakhvaloff
2009-12-15 18:27:43 UTC
Permalink
T24gVHVlLCAxNSBEZWMgMjAwOSAxNTo1MToxMSArMDMwMCwgQWxleCBDaGVyZWRu
aWNoZW5rbyAgDQo8Y2hlcmVkbmljaGVua28tU2d2WGdxVEQ4a2NAcHVibGljLmdt
YW5lLm9yZz4gd3JvdGU6DQoNCj4gSGVsbG8sIGZyZWVtYW56YXYhDQo+IFlvdSB3
cm90ZSAgb24gVHVlLCAxNSBEZWMgMjAwOSAwNDo0MzoxNCAtMDgwMCAoUFNUKToN
Cj4NCj4gIGY+IOEg0M/exc3VINEg18nW1SDUz8zYy88g3qPS1M/ey8kgySDawcvP
0sDey8kg1yDOxcvP1M/S2cgg08/Pwt3FzsnRyA0KPiAgZj4gzsnL1M8gzsUgzsUg
2s7BxdQ/IDopDQo+DQo+INEg2s7BwC4NCj4g1Nkg0M/M2NrVxdvY09EgKPYpz9DF
0s/KLg0KDQogICDuxSDLzMXXxd3JIM7BICXP0NDF0tUhLi4g8SDFwCDUz9bFINDP
zNja1cDT2C4uLiD306Mg18nEzs8gzs/SzdXM2C4uLg==

Continue reading on narkive:
Loading...