По роду деятельности часто приходится устанавливать firebird и не на стандартный порт + несколько инстансов на одном сервере, решил упростить задачу и с коллегой сделали установщик с помощью InnoSetup. Установщик позволяет быстро установить SuperServer Firebird 2.5.2 26540 на нужный порт и с нужным наименованием службы, для нескольких серверов в одной системе. Также он проверит существование уже существующих служб с выбранным именем и при обнаружении конфликта не даст продолжить. Удаляется установка вместе со службой и файлами.

Кому интересно - могу выслать исходники от InnoSetup

Брать тут: http:/www.palarity.com/fb_2_5_2_setup.exe

Держите.
http://www.palarity.com/FirebirdSetupSrc.rar

Добавить поле ввода пароля для sysdba - орошая идея, думаю что сегодня добавлю.
А что касается пользователей, так это действительно избыточно. Если их стандартный набор, то можно просто security2 подсунуть подготовленный или через ibexpert делать, в любом случае это нужно будет делать или в установщике или в эксперте. Так зачем велосипед изобретать, если он уже есть...

Главная идея была в том, что приходится возиться с командной строкой, создавать попапочки, копировать файлы и прочее, в том случае если нужно сделать второй инстанс... С этой задачей установщик справляется очень просто.

Симонов Денис,
Потому что под винду рекомендуют ставить супер сервер, и он ставится по умолчанию :)

http://www.firebirdsql.org/manual/ru/qsg15-classic-or-super-ru.html

kdvrpalaznikПотому что под винду рекомендуют ставить супер сервер
ШТО? :-)
суперсервер рекомендуют только когда
- мало пользователей
- пользователи выполняют легкие и короткие запросы

потому что пока супер не распараллеливается, и любой тяжелый запрос заткнет всех остальных пользователей.

Ну как это ШТО, написано же:
Classic Server : авторНа каждое пользовательское соединение создается отдельный процесс со своим кэшем. При малом количестве соединений потребляется меньше ресурсов. Т.е. при большом - много жрет, по этому ваше первое утверждение неверно. Про второе замечание не думал ни когда, но похоже оно имеет место быть. Руководствовался только рекомендацией с авторитетного ресурса где написано:
авторЕсли Вы все еще не уверены, что именно выбрать (возможно, технические подробности показались Вам чересчур сложными для «Быстрого старта») воспользуйтесь следующим правилом:

Под Windows выбирайте Superserver.
Под Linux, просто выбирайте один или другой вариант. В большинстве случаях, скорее всего, Вы не заметите разницы.

Всем спасибо за разъяснения, обоснованная критика всегда полезна. Обновили установщик, теперь можно ввести пароль sysdba и выбрать какой сервер устанавливать SS или С. (iss - http://www.palarity.com/FirebirdSetup25.rar exe - http://www.palarity.com/Firebird25.exe)

Все вышесказанное заставило задуматься и поэкспериментировать. Поставил 2 сервера на одну машинку и по очереди проделывал следующие действия: с помощью одной версии эксперта подключался к базе и выполнял условно бесконечный процесс, второй версией выполнял запрос с конечным временем и постепенно наращивал кол-во условно бесконечных процессов и получилась следующая зависимость:

SupperServer 0 подвисших - 1s 903ms, 1 подвисший - 3s 370ms, 2 - 4s 976ms, 5 - 8s 829ms 15 - 25s 756ms
ClassicServer 0 подвисших - 1s 940ms, 1 подвисший - 3s 42ms, 2 - 4s 212ms, 5 - 6s 68ms 15 - 12s 246ms

Из чего можно сделать вывод что реально Classic лучше. Еще хотелось выяснить насколько страдают все пользователи при выполнении одним одним пользователем тяжелого запроса и понять можно ли распараллелить работу SupperServer. Оказалось что татального зависона не происходит и условно можно работать дальше... Заметил что при подключении 2х клиентов с бооольшими запросами на SS происходит выделение процессу 25% всего процессорного времени, когда 2, самых загруженных ядра (из 4х) системы загружены только до половины, это может говорить, что сервер обслуживался сразу 2я ядрами системы одновременно.

При эксперименте еще заметил, что при большом числе > 10 подвисших процессов на Classic система тратит больше оперативной памяти, чем SS.

Ivan_Pisarevsky rpalaznikтехнические подробности показались Вам чересчур сложнымиЧто правда подробности так сложны? Я так полагаю Дима написал это, как в анекдоте про "а когда рецепт совсем не читается, то мы даем вот ЭТУ микстуру". А в самой статье рецепт как раз прописан вполне разборчиво.

На самом деле я не увидел, что речь идет о 1.5... И прочитав рекомендации понял что в одном случае 1 процесс и много потоков, в другом случае много процессов с одним потоком в каждом. К сожалению опыта и знаний не хватило чтобы точно понять какой вариант выбрать, по этому решил сделать по совету... Теперь, благодаря, в том числе и вам, разобрался в этом вопросе, спасибо!

И если подвести итог - т.к. проблем с распараллеливанием с версии 2.5 нет, то кол-во ядер роли не играет в выборе типа, Classic идеально подходит в базах, где могут часто встречаться тяжелые запросы, в случае небольшого кол-ва подключений и на аппаратной платформе нет проблем с оперативной памятью. SS используем там где нет большого кол-ва тяжелых процессов, при большом кол-ве подключений, и есть проблемы с памятью

В приоритете конечно тяжелые запросы, все остальное на втором плане и по умолчанию стоит использовать именно Classic, а не SS.

Ivan_PisarevskyrpalaznikВсе вышесказанное заставило задуматься и поэкспериментировать...Далее пошел не фильтрованный поток сознания.

Как говорил ДЕ, если бы одна архитектура была однозначно хорошей, никто не стал бы заморачиваться и держать параллельно 2.

rpalaznikт.к. проблем с распараллеливанием с версии 2.5 нетss в 2.5 не параллелится по ядрам. НУ почитай уже доку, ссылку ведь выше дали и форуме это обсуждалось, в том числе участим разработчиков.

Я эти доки изучил, и к сожалению, пока не докопался до истины т.к. мне кажется, что информацию из них противоречит тому, что говорите мне вы.

авторWindows Superserver defaults to using the first logical processor only, because prior to 2.5 it performed badly on SMP systems. To make use of all your processors, set the CpuAffinityMask parameter in firebird.conf to: 3 for 2 CPUs/cores; 15 for 4 CPUs/cores; 255 for 8 CPUs/cores.
Подскажите пожалуйста, как это правильно понимать? Неужели это не говорит что для распараллеливания работы SS нужно подправить конфиг, чтобы указать серверу сколько процессоров\ядер ему использовать?

Dimitry SibiryakovrpalaznikНеужели это не говорит что для распараллеливания работы SS нужно
подправить конфиг, чтобы указать серверу сколько процессоров\ядер ему использовать?

Для начала скажи где ты это нашёл.



http://www.firebirdsql.org/file/documentation/reference_manuals/user_manuals/html/qsg25-appx-architectures.html

Симонов Денисrpalaznik,

нет это говорит о том, что надо поставить такую маску чтобы SS использовал только 1 ядро процессора. Соответственно, в зависимости от маски будет зависеть какое именно. Можно конечно поставить маску так, чтобы юзались два и более ядра, только работать от этого лучше не будет.

P.S. В 2.5 это всё же имеет смысл, если SS работает более чем с одной БД.

Теперь понятно стало, спасибо! Ото пишут, что может использовать несколько ядер, только добавь правку в конфиге, а что на самом деле пользователи подключенные к одной базе будут все равно на одном коре крутиться так и не догадаешься.

Dimitry Sibiryakov, надо бы донести до них :)

Симонов Денисrpalaznik,

http://www.firebirdsql.org/file/documentation/release_notes/html/ru/rlsnotes25.html#rnfb25-engine В архитектуре SuperServer были сделаны два основных усовершествования:

При работе с несколькими базами данных потоки теперь равномерно распределяются на все доступные процессоры, т.е. потоки, работающие с разными базами данных могут выполняться на разных процессорах.

Замечание

По умолчанию параметр «CpuAffinity» по прежнему привязывает сервер в режиме SuperServer к одному процессору. Для лучшей масштабируемости при работе с несколькими базами данных необходимо изменить значение этого параметра в файле firebird.conf.

Небольшое улучшение масштабируемости при работе с одной базой данных на аппаратных средствах с поддержкой SMP.


Спасибо!

Осталось добавить возможность выбора архитектуры SupperClassic в установщик и добавить описание каждой архитектуры для подсказки админам...

Вано Сусанишвили, стандартный установщик - супер штука, но когда нужно установить сразу несколько, на определенные порты с нужным паролем sysdba, с нужным названием службы - приходится ручками все править, а тут можно быстро все сделать.

kdvDimitry Sibiryakov,

можно подумать, что люди обычно используют больше двух баз на одном сервере.
Кому надо - включит affinity. привязывать сразу при установке к нулевому (по порядку) ядру можно, конечно, но это моветон.

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

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

А что такое зоопарк? И почему нельзя выкладывать?

Доходчиво!