Re: Про RDB-домены
Это известная хрень или где? В трекере разберутся :-) Ага, понял. Щас нацарапаю туда хэлло пиплы :) мы еще предыдущее не закрасили, а ты опять царапать? А ну брось гвоздь. Аааа, ну как скажете... Нам что подтаскивать, что оттаскивать - без разницы :))) Коваленко Дмитрий.
Re: SuperClassic
А потом, когда замутил многопоточную тестовую систему - перешел на одну базу. И то, если мне не изменяли глаза, супер умудрялся выжирать чуть больше одного ядра (~30% на четырехядернике). При 8 тестовых потоках. А что она тестила? CTE не пробовал джойнить с немерянными таблицами? Дмитрий
Re: SuperClassic
Dmitri Kuzmenko wrote: Но это всё ещё не то, чего хочется. Сейчас проблема в том, что суперсервер из за кривизны кода плохо параллелится по разным потокам. он вообще не параллелится, и не из-за кривизны, а из-за архитектуры. Насколько я помню из времён ковыряния к коде FB1.0 там 1) кооперативная многозадачаность. FB сам переодически переключается на другой запрос. 2) много глобальных переменных. 3) блокировки 4) нереентабельный код. В принципе на истинный параллелизм можно и забить, если бы кооперативная многозадачность работала бы более качественно. Давайте сделаем такую архитектуру: гибрид классика и супера. ты бы пару лет назад это написал. А теперь уже поздно. Никогда не поздно. Если посмотреть на перспективу, то даже если суперсервер будет идеально параллелиться по ядрам, то полезно было бы иметь возможность запускать несколько его процессов для: 1) надёжности от программных сбоев 2) загребания большего количества памяти (32бит лимит) 3) перспектив кластеризации и работы а железе где нет глобальной SMP. с какого буя? С приоритетами уже баловались, на классике. Запускаем на супере: 1) тяжёлый долгоиграющий запрос 2) в другом коннекте пускаем сверхкороткий. В результате скорость отклика на короткие запросы существенно падает. Для тяжёлого запроса пофиг сколько он будет выполняться 1 минуту, или 2. А для коротких скорость отклика критична. Поэтому введение приоритета явного или неявного напрашивается.
Re: ~Re: SuperClassic
Kovalenko Dmitry wrote: На супере 2.5 независимые базы нормально параллельно работают. Я года назад очень активно с этим игрался. Интересно насколько параллельно. Как я помню по FB1.0 банальный yacc выдавал нереентабельный парсер. А потом, когда замутил многопоточную тестовую систему - перешел на одну базу. И то, если мне не изменяли глаза, супер умудрялся выжирать чуть больше одного ядра (~30% на четырехядернике). При 8 тестовых потоках. Ну много потоков там всегда создавалось. Вопрос в том, что в большенстве случает работал только один.
Re: Нагрузочная способность с ервера
Hello, Lobster! On 11 дек, 09:53, Lobster maale...@gmail.com wrote: Да уж ...рисунок шедевр, если криво задал вопрос можно просто написать... сам виноват. прислал вопрос зачем то в base 64. Вот мой Netscape и среагировал так. Впрочем, сам я вижу свое сообщение в нормальном виде. Тут на gmane, через браузер - действительно хрень какая-то.
Re: SuperClassic
А потом, когда замутил многопоточную тестовую систему - перешел на одну базу. И то, если мне не изменяли глаза, супер умудрялся выжирать чуть больше одного ядра (~30% на четырехядернике). При 8 тестовых потоках. А что она тестила? Конвертирование текстовых данных (блобы, массивы, обычные колонки) в разных мутанских комбинациях кодовых страниц, форматов и размеров данных. Фактически, проверяется каждая буква определенного набора кодовых страниц в разных позах (WIN1251 тоже проверям :) ) То есть _дофига_ простых операций по чтению, записи и удалению. Багов они поймали ... ну типа много :) Да и щас вот ... интересную картину показывают :)) Там еще другие веселые тесты есть. CTE не пробовал джойнить с немерянными таблицами? Не, CTE я вообще ни разу не юзал :)) Максимум - это у нас юзаются EB которые проверяют какую то формулу с датами. Коваленко Дмитрий. PS. Желающим поигратсо - качаем триал провайдера (тока щас обновил, свеженький) - собираем тесты TestCode\ActiveX\IBP\oledb_test (VS2008 желательно) - генерим базу TestCode\ActiveX\IBP\test_database И насилуем FB (вместе со своим компутером) :-))) Особенно приветствуются четырех и более ядерные монстры :-)
Re: ~Re: SuperClassic
На супере 2.5 независимые базы нормально параллельно работают. Я года назад очень активно с этим игрался. Интересно насколько параллельно. Запусти и посмотри сам :) Как я помню по FB1.0 банальный yacc выдавал нереентабельный парсер. Я на днях всю линейку мучал. IB4-IB9, FB0.9-FB2.5 Жизнь начинается с IB7 / FB1.5. Коваленко Дмитрий.
Re[2]: ~Re: SuperClassic
Превед! Интересно насколько параллельно. Как я помню по FB1.0 банальный yacc выдавал нереентабельный парсер. Reentrant - если уж использовать кальку - то реентрабельный или - потокобезопасный. Ы? -- Best regards, Sergeymailto:gebele...@gmail.com
Re: SuperClassic
On 11.12.2009 12:17, Alexey Popov wrote: Никогда не поздно. Если посмотреть на перспективу, то даже если суперсервер будет идеально параллелиться по ядрам, то полезно было бы иметь возможность запускать несколько его процессов Другой разговор. Главное - определиться с приоритетами и не ставить это во главу угла. -- Дмитрий Еманов
Re: SuperClassic
Hello, Alexey! Alexey Popov wrote: ты бы пару лет назад это написал. А теперь уже поздно. Никогда не поздно. Если посмотреть на перспективу, то даже если суперсервер будет идеально параллелиться по ядрам, то полезно было бы иметь возможность запускать несколько его процессов для: в топку перспективу. Иди смотри FB 3.0. Потом возвращайся обратно. с какого буя? С приоритетами уже баловались, на классике. Запускаем на супере: 1) тяжёлый долгоиграющий запрос 2) в другом коннекте пускаем сверхкороткий. В результате скорость отклика на короткие запросы существенно падает. мочи мочало, начинай сначала... В IB2007/2009 на супере, кстати, таких проблем нет. Для тяжёлого запроса пофиг сколько он будет выполняться 1 минуту, или 2. А для коротких скорость отклика критична. Поэтому введение приоритета явного или неявного напрашивается. якобы напрашивается. В общем, ты бы для начала подковался по архивам fb-devel, что сделано в 2.5, и что делается в 3.0. А потом с предложениями приходил бы. А то получается так - чего там в 3.0 нафигачили я не знаю, но я предлагаю вот так. И разработчики быстро побежали менять архитектуру 3.0? -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
FB 2.5 RC1
Поздравляю всех! Дождались! Спасибо разработчикам! С уважением Александр Редько
Re: FB 2.5 RC1
dedRasta rex...@gmail.com сообщил/сообщила в новостях следующее: news:d971a4f2-c233-4165-9a5c-9eb0be4ee...@j4g2000yqe.googlegroups.com... Поздравляю всех! Дождались! Спасибо разработчикам! С уважением Александр Редько А я так и не пощупал это чудо природы. Как жаль :(
Re: FB 2.5 RC1
А я так и не пощупал это чудо природы. Как жаль :( Ничо так. На ощупь. Но пока есть некоторые проблемы с интенсивным сексом. Хотя, возможно, это не секс, а чисто[е липетцкое] убийство :-) --- Меня тут вот, после распития содержимого бутылки с этикеткой Девичья Башня, посетила мысль. Тесть бодяжит. Щас проще в FB допилить многопоточность, чем в IB реализовать все (зачастую, конкретные) фичи Firebird :-) Но это мои субъективные мысли :)) Коваленко Дмитрий.
Re: FB 2.5 RC1
On 11.12.2009 15:40, Kovalenko Dmitry wrote: Меня тут вот, после распития содержимого бутылки с этикеткой Девичья Башня, посетила мысль. Тесть бодяжит. Не экспортирует часом? :-) Щас проще в FB допилить многопоточность, чем в IB реализовать все (зачастую, конкретные) фичи Firebird :-) В корень зришь. -- Дмитрий Еманов
DSQL_unprepare
Подскажите с этим флагом. В чем его суть?
Re: DSQL_unprepare
Hello, Andrei! You wrote on Fri, 11 Dec 2009 09:01:54 -0800 (PST): A Подскажите с этим флагом. В чем его суть? http://groups.google.ru/group/ru-firebird/browse_thread/thread/bbac4a5ad9983dd0/63b21d2cb2f3d222 -- With best regards, Alex Cherednichenko.
Re: FB 2.5 RC1
Меня тут вот, после распития содержимого бутылки с этикеткой Девичья Башня, посетила мысль. Тесть бодяжит. Не экспортирует часом? :-) Не, это оч. эксклюзивные напитки. Но у меня в холодильнике еще одна бутылка из этой серии есть. Тебя как - подождать? Щас проще в FB допилить многопоточность, чем в IB реализовать все (зачастую, конкретные) фичи Firebird :-) В корень зришь. Дык. Останется только один :) Коваленко Дмитрий.
