Re: superclassic win x64
On 28.07.2010 23:16, Дмитрий Еманов пишет: Случайность или 64-битный супер-классик не отработан ? Отработан. Более того, он только на 64-битах и имеет смысл :-) А можно ссылочку где почитать про основные отличия и смысл :) ? --- Евгений Виноградный
Re: superclassic win x64
А можно ссылочку где почитать про основные отличия и смысл :) ? http://www.sinatica.com/blog/en/index.php/articles/firebird-superserver-classicserver-or-superclassic
Re: superclassic win x64
А можно ссылочку где почитать про основные отличия и смысл :) ? http://www.sinatica.com/blog/en/index.php/articles/firebird-superserver-classicserver-or-superclassic
Re: superclassic win x64
On 29.07.2010 13:40, Andrei wrote: http://www.sinatica.com/blog/en/index.php/articles/firebird-superserver-classicserver-or-superclassic Спасибо за ссылку.
superclassic win x64
В письме от Wed, 28 Jul 2010 18:07:10 +0400, Andrei gs1...@gmail.com сообщал: и еще в догонку: сервер SuperClassic. Кстати, при установке FB 2.5 rc2 win x64 предлагаются варианты SS и C, СуперКлассик не предлагается. А для Win x86 предлагается Случайность или 64-битный супер-классик не отработан ? -- Написано в почтовом клиенте браузера Opera: http://www.opera.com/mail/
Re: superclassic win x64
28.07.2010 21:35, Arioch пишет: Кстати, при установке FB 2.5 rc2 win x64 предлагаются варианты SS и C, СуперКлассик не предлагается. Выбираешь классик, через два экрана у тебя появляется галка суперклассик. Что не так? Случайность или 64-битный супер-классик не отработан ? Отработан. Более того, он только на 64-битах и имеет смысл :-) -- Дмитрий Еманов
Re: SuperClassic
А почему я вижу только чёрточки и закорючки в некоторых сообщениях никто не не знает? :)
Re: SuperClassic
Hello, freemanzav! You wrote on Tue, 15 Dec 2009 04:43:14 -0800 (PST): f А почему я вижу только чёрточки и закорючки в некоторых сообщениях f никто не не знает? :) я знаю. ты пользуешься (Ж)оперой. -- With best regards, Alex Cherednichenko.
Re: SuperClassic
On 15 дек, 15:51, Alex Cherednichenko cheredniche...@post.cz wrote: Hello, freemanzav! You wrote on Tue, 15 Dec 2009 04:43:14 -0800 (PST): f ޣ f ? :) . ( ) . -- With best regards, Alex Cherednichenko. Ничего не понятно
Re: SuperClassic
f Ничего не понятно Не пользуйся (Ж)оперой. -- With best regards, Alex Cherednichenko.
Re: SuperClassic
freemanzav сообщил/сообщила в новостях следующее: Ничего не понятно Tebe govoriat: HE polzuy Operu :))
Re: SuperClassic
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.
Re: SuperClassic
On Tue, 15 Dec 2009 15:51:11 +0300, Alex Cherednichenko cherednichenko-sgvxgqtd...@public.gmane.org wrote: Hello, freemanzav! You wrote on Tue, 15 Dec 2009 04:43:14 -0800 (PST): f А почему я вижу только чёрточки и закорючки в некоторых сообщениях f никто не не знает? :) я знаю. ты пользуешься (Ж)оперой. Не клевещи на %опперу!.. Я ею тоже пользуюсь... Всё видно нормуль...
Re: SuperClassic
Dmitri Kuzmenko wrote: В общем, ты бы для начала подковался по архивам fb-devel, Не читал, но осуждаю. что сделано в 2.5, и что делается в 3.0. А потом с предложениями приходил бы. Про 2.5 вроде всё ясно. Про 3.0 где можно увидеть поподробнее, акромя fb-devel?
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: 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
Re: SuperClassic
Dmitry Yemanov wrote: суперсервер за счёт единого кэша весьма эффективен и быстр Это скорее теорема, чем аксиома... Разнесённый кэш мне не ещё нравится тем, что быстро выжирает память. Различные процессы классика конкурируют и вытесняют горячие данные из кэша процессора, который нерезиновый. Давайте сделаем такую архитектуру: гибрид классика и супера Может лучше таки параллельную работу с общим кешем? Это конечно идеальный вариант, но требует больше переработок. Как я себе представляю проблема в большом количестве legacy code, который не может выполняться сразу несколькими потоками. Чисто теоретически, read only запросы при полном попадании в кэш должны очень хорошо параллелится. Что же касается вытесняющей многозадачности на одном ядре, то в идеале надо делать свой шедулер потоков и ресурсов. Потому что надо эффективно управлять приоритетом. Например, в одном соединении запускается долгоиграющий запрос, а другое соединение хочет выполнять короткие быстрые запросы. Первое соединение после n секунд выполнения запроса должно принудительно быть понижено в приоритете. Аналогично между соединениями должна по братски распределяться полоса пропускания IO, память.
Re: SuperClassic
Hello, Alexey! Alexey Popov wrote: Насколька я понял, сабжевая архитектура - это объединение процессов классика в один процесс? не совсем. Но это всё ещё не то, чего хочется. Сейчас проблема в том, что суперсервер из за кривизны кода плохо параллелится по разным потокам. он вообще не параллелится, и не из-за кривизны, а из-за архитектуры. Давайте сделаем такую архитектуру: гибрид классика и супера. ты бы пару лет назад это написал. А теперь уже поздно. Первое соединение после n секунд выполнения запроса должно принудительно быть понижено в приоритете. с какого буя? С приоритетами уже баловались, на классике. В общем, я из лесу вышел... :-) -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
~Re: SuperClassic
Но это всё ещё не то, чего хочется. Сейчас проблема в том, что суперсервер из за кривизны кода плохо параллелится по разным потокам. он вообще не параллелится, и не из-за кривизны, а из-за архитектуры. На супере 2.5 независимые базы нормально параллельно работают. Я года назад очень активно с этим игрался. А потом, когда замутил многопоточную тестовую систему - перешел на одну базу. И то, если мне не изменяли глаза, супер умудрялся выжирать чуть больше одного ядра (~30% на четырехядернике). При 8 тестовых потоках. Честное пионерское. Мне сказали - возможно это асинхронное I/O. Да и по любому - в рамках одной базы одно время были грабли с многопоточностью. Значит он (супер) таки что то там делает параллельно. Грабли исчезли где то с начала прошедшей оcени. Причем все - и у FB, и у Висты c новыми дисками :) [стучу по дереву] Но щас пересел на суперклассик. И пруся от нереальной загрузки процессора :) Вот. Коваленко Дмитрий.
SuperClassic
Насколька я понял, сабжевая архитектура - это объединение процессов классика в один процесс? Плюсы: многопоточная работа с базой, потенциально более масштабируем чем классик. Но это всё ещё не то, чего хочется. Сейчас проблема в том, что суперсервер из за кривизны кода плохо параллелится по разным потокам. Тем не менее суперсервер за счёт единого кэша весьма эффективен и быстр. Давайте сделаем такую архитектуру: гибрид классика и супера. 1) Каждый процесс классика будет обрабатывать произвольное количество соединений как сейчас суперсервер делает в режиме сериализации с псевдопараллелизмом. 2) Заранее запускаем N экземпляров процессов классика, по числу ядер или меньше. 3) Менеджер соединений передаёт коннекты от пользователей экземплярам классика с целью равномерного распределения нагрузки. Либо такая интерпретация: доработать суперсервер так, чтобы он мог расшаривать работу с базой с другим инстансами суперсервера по принципу работы классика.
Re: SuperClassic
Alexey Popov wrote: суперсервер за счёт единого кэша весьма эффективен и быстр Это скорее теорема, чем аксиома... Давайте сделаем такую архитектуру: гибрид классика и супера Может лучше таки параллельную работу с общим кешем? -- Дмитрий Еманов
