Re: SuperClassic
Dmitry Yemanov wrote: суперсервер за счёт единого кэша весьма эффективен и быстр Это скорее теорема, чем аксиома... Разнесённый кэш мне не ещё нравится тем, что быстро выжирает память. Различные процессы классика конкурируют и вытесняют горячие данные из кэша процессора, который нерезиновый. Давайте сделаем такую архитектуру: гибрид классика и супера Может лучше таки параллельную работу с общим кешем? Это конечно идеальный вариант, но требует больше переработок. Как я себе представляю проблема в большом количестве legacy code, который не может выполняться сразу несколькими потоками. Чисто теоретически, read only запросы при полном попадании в кэш должны очень хорошо параллелится. Что же касается вытесняющей многозадачности на одном ядре, то в идеале надо делать свой шедулер потоков и ресурсов. Потому что надо эффективно управлять приоритетом. Например, в одном соединении запускается долгоиграющий запрос, а другое соединение хочет выполнять короткие быстрые запросы. Первое соединение после n секунд выполнения запроса должно принудительно быть понижено в приоритете. Аналогично между соединениями должна по братски распределяться полоса пропускания IO, память.
FB 2.5
Привет Я все правильно путаю? FB 2.5 умеет делать гетерогенные запроссы. ткните носом где посмотреть и на пару примеров заоодно Дмитрий
Re: FB 2.5
ñ ÂÙ ÔÁË ÎÅ ×ÙÒÁÖÁÌÓÑ. ðÏÌÕÞÁÔØ ÄÁÎÎÙÅ ÉÚ ×ÎÅÛÎÉÈ ÉÓÔÏÞÎÉËÏ× - ÄÁ. óÌÉÔØ ×ÎÅÛÎÉÊ ÐÏÔÏË É ×ÎÕÔÒÅÎÎÉÊ ÍÏÖÎÏ ÞÅÒÅÚ ×ÒÅÍÅÎÎÕÀ ÔÁÂÌÉÞËÕ, ÎÁÐÒÉÍÅÒ. ñ ×ÓÅ ÐÒÁ×ÉÌØÎÏ ÐÕÔÁÀ? FB 2.5 ÕÍÅÅÔ ÄÅÌÁÔØ ÇÅÔÅÒÏÇÅÎÎÙÅ ÚÁÐÒÏÓÓÙ. ÔËÎÉÔÅ ÎÏÓÏÍ ÇÄÅ ÐÏÓÍÏÔÒÅÔØ É ÎÁ ÐÁÒÕ ÐÒÉÍÅÒÏ× ÚÁÏÏÄÎÏ
Re: FB 2.5
Привет Я бы так не выражался. Получать данные из внешних источников - да. Слить внешний поток и внутренний можно через временную табличку, например. Пока смотрю тут http://www.firebirdsql.org/rlsnotesh/rlsnotes25.html#rnfb25-psql-extqry А залить во внешний источник? Т.е. я к репликации веду :-) Дмитрий
Про RDB-домены
Это опять я. Есть хранимая процедура с параметром CREATE PROCEDURE SP (A INTEGER) Имя у домена этого параметра - RDB$123 Создаем новую хранимую процедуру CREATE PROCEDURE SP1(A RDB$123) Сервер (FB2.5) создает SP1 без проблем. Удаляем SP1. Коммитим. --- Смотрим в базу - SP имеет параметр, который ссылается на несуществующий домен. Это известная хрень или где? --- IBE - маладца. По-всей видимости, юзает left join для пересечения PROCEDURE_PARAMETERS и FIELDS. Поэтому список параметров убитой SP все равно показывает корректно. Коваленко Дмитрий. PS. Не виноватая я!
Re: Про RDB-домены
On 10.12.2009 19:48, Kovalenko Dmitry wrote: Это известная хрень или где? В трекере разберутся :-) -- Дмитрий Еманов
Re: Про RDB-домены
Это известная хрень или где? В трекере разберутся :-) Ага, понял. Щас нацарапаю туда хэлло пиплы :) Коваленко Дмитрий.
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 новыми дисками :) [стучу по дереву] Но щас пересел на суперклассик. И пруся от нереальной загрузки процессора :) Вот. Коваленко Дмитрий.
Re: Про RDB-домены
Kovalenko Dmitry wrote: Это известная хрень или где? В трекере разберутся :-) Ага, понял. Щас нацарапаю туда хэлло пиплы :) мы еще предыдущее не закрасили, а ты опять царапать? А ну брось гвоздь.
Re: FB 2.5
þÅÒÅÚ ES ÍÏÖÎÏ ÏÂÅÒÎÕÔØ ÌÀÂÏÊ ÏÐÅÒÁÔÏÒ, ÎÅ ÔÏÌØËÏ SELECT. ðÏËÁ ÓÍÏÔÒÀ ÔÕÔ http://www.firebirdsql.org/rlsnotesh/rlsnotes25.html#rnfb25-psql-extqry á ÚÁÌÉÔØ ×Ï ×ÎÅÛÎÉÊ ÉÓÔÏÞÎÉË? ô.Å. Ñ Ë ÒÅÐÌÉËÁÃÉÉ ×ÅÄÕ :-)
Нагрузочная способность сер вера
Добрый день! У меня такой вопрос. А существует ли формула по определению нагрузочной способности сервера где установлен FB. Использую FB 2.1.3 CS, ОС - Linus SUSE Entr. 10.3 с 32 Гб опры, размер базы около 25 Гигов, размер страницы 16к. Я уже думал может как то связать это с формулой определения размера Кэша (PAGE_SIZE * DefaultCachePages * количество коннектов)? Подскажите если кто знает :)
Re: FB 2.5
Пока смотрю тут http://www.firebirdsql.org/rlsnotesh/rlsnotes25.html#rnfb25-psql-extqry А тут смотрел http://firebirdsql.su/doku.php?id=execute_statements[]=execute
Re: Нагрузочная спосо бность сервера
Hello, Lobster! Lobster wrote: У меня такой вопрос. А существует ли формула по определению нагрузочной способности сервера где установлен FB. Использую FB 2.1.3 не существует. Я уже думал может как то связать это с формулой определения размера Кэша (PAGE_SIZE * DefaultCachePages * количество коннектов)? это теоретический размер потребляемой памяти, причем очень далекий от реальности. Повторяться не буду, на эту тему тут недавно обсуждение было. нагрузочная способность это вообще фиг знает что, наверное, еще и с производительностью дисковой системы связано, но вот ее нагрузочную способность определить сложно. Ну и, коннект коннекту рознь. Один может вяло данные перекидывать, а другой может считать гигантский отчет, третий - массово вставлять или обновлять данные, и т.п. -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Re: Нагрузочная способность с ервера
, . , . , , , . , . , , - , . . Да уж ...рисунок шедевр, если криво задал вопрос можно просто написать...
Re: Нагрузочная способность сервера
On Fri, 11 Dec 2009 09:53:29 +0300, Lobster maalex26-re5jqeeqqe8avxtiumw...@public.gmane.org wrote: , . , . , , , . , . , , - , . . Да уж ...рисунок шедевр, если криво задал вопрос можно просто написать... Не знаю, что у тебя за хрень, а у меня всё нормально видно: === Hello, Lobster! Lobster wrote: У меня такой вопрос. А существует ли формула по определению нагрузочной способности сервера где установлен FB. Использую FB 2.1.3 не существует. Я уже думал может как то связать это с формулой определения размера Кэша (PAGE_SIZE * DefaultCachePages * количество коннектов)? это теоретический размер потребляемой памяти, причем очень далекий от реальности. Повторяться не буду, на эту тему тут недавно обсуждение было. нагрузочная способность это вообще фиг знает что, наверное, еще и с производительностью дисковой системы связано, но вот ее нагрузочную способность определить сложно. Ну и, коннект коннекту рознь. Один может вяло данные перекидывать, а другой может считать гигантский отчет, третий - массово вставлять или обновлять данные, и т.п. ===
