Basmach

Из ком строки backup/restore по идее можно сделать из под пользователя. Для этого надо явно указать ключи -user и -password, соотвественно надо иметь разрешения на запуск файлика gbak на уровне файловой системы. Изменения в таблички ПС3 автоматически не делает. Факт вполне проверенный. Чтоб их делать без реструктуризации, надо знать, что поменялось в базе и руками писать скрипт. Профсегмент естественно такой информации не дает. Было бы очень неплохо если бы они изменили такой подход. Вместо реструктуризации присылали скрипты. Тогда было бы видно что меняется. Запускать ПС3 под Wine никакого смысла нет, он под виндой то работает не очень, а тут столько глюков будет!!! Первое что в голову приходит драйвера к хаспу, потом отчеты заточены под ослика ИЕ, импорт экспорт опять же, RAR нужен а он под Линукс не бесплатный, WinZip с gzip не дружит. Короче сумма гиморов совершенно не адекватна. Ну разве, что на вас наехали за нелицензионную винду. Такое бывает конечно, но мы ведь тут все люди честные, конрафактом не пользуемся

Гм, ключи объеденили, эт наверное сеть сегментировали а на сервак две карточки сетевые поставили? Я правильно понимаю? А реструктуризация это вообще то backup/restore простой. Вернее сначала backup/restore делается, а потом для нужд нового екзешника новые поля в таблички добавляются. О пользе данного действия я уже писал. У баз сильно индексы едут, тока backup/restore и помогает.

Пробовал ради эксперимента выключать. Скорость записи падает до 10 Мб/сек, чтение остается на уровне 80 - 120 Мб/сек. Разницы особой не видно. База работает достаточно быстро, особенно если она меньше гига по объему. Разрастись мы ей не даем, периодически выгружаем данные. Дело тут все в том, что для того, чтоб базу реструктурировать ее надо тащить на другую машину. И локально это делать. А ОЗУ на офисных машинах не хватает к сожалению... Не покупать же еще один сервер для реструктуризации...

А это более детально. Это график за период с пятницы до понедельника. Хорошо видно как в пятницу при интенсивной работе база кушает память. Есть еще график сетевой активности, показательно, что он повторяет график загрузки процессора. graph_image.php.png

На серваке Линукс, кроме Птички ничего не крутится. Птичка в варианте классик. График дисковой активности показывать смысла не имеет потому как работает раид с кэшированием записи. Т.е данные считаются записанными как только они попали в кэш контроллера. Использование ОЗУ выкладываю: graph_image.php.png

Маленький наглядный материал. Сервер 2х3.0 ГГц Xeon, 8 Гб ОЗУ. На нем три базы Firebird каждая по гигу или больше. С базами работает ПФ3. Пользователей штук 35, график загрузки процов: graph_image.php.png

Этот замок в виде гениальной защиты мешает нормально работать! Я не говорил, что защиту надо убрать вовсе, ее надо переработать! Насчет механизма авторизации поясню: Все пользователи работают в базе от пользователя SYSDBA у которого пароль masterkey, со всеми возможными вытекающими... По последнему пункту претензия по адресу. Никто не мешает написать скрипт для того чтоб его на сервере запускать.

Насчет выключения ПФ2 это правда! Причем профсегмент предупреждал нас заранее об этом. Мы договорились о продлении, нам выслали новый .exe файл который благополучно показал ошибку хаспа как раз в тот день, когда должен был вырубиться старый екзешник. У нас в тот момент уже был ПФ3, но базы! Баз под него еще не было! Был конечно вариант крячить все это, но мы ведь люди порядочные! Стали звонить в Профсегмент, там застали совершенно невменяемого типа который ничего объяснить не мог. Фирма в этот момент стояла. Проблема конечно решилась, через пару часов нам выслали нормальный екзешник. Наверное как раз за это время скомпилировали. Но этот случай показателен. Вообще профсегменту надо от жадности лекарство принимать. Из-за их паранойи фирма понесла убытки, а запас здоровых невных клеток нашего техотдела значительно сократился. Вообще эта их политика вечных обновлений мне не нравится. Чувствуешь себя бета тестером. А ведь тестерам ПО деньги платить надо между прочим! Ключ работает отвратительно, фактически живет своей жизнью. Святым рандомом по ошибке хаспа может вылететь любой. Вроде уже nethasp.ini всюду положил. Не помогает. Причем сеть нормальная. Продолжать могу долго... Выводы: ПФ3 программа не стабильная. Политика обновлений должна быть пересмотрена. Механизм защиты надо переработать. Крайне желательно создать инструменты для работы с базой удаленно, а то всякий раз приходится при обновлении екзешника тащить базу на локальную машину. Механизм авторизации пользователей никуда не годится. Есть конечно и положительные стороны в ПФ3, но о них и так все знают.

Небольшие пояснения в моему вышеизложенному посту: DefaultDbCachePages = 10000 это сильно влияет на потребление сервером ОЗУ. Для классика это число уноженное на размер страницы БД даст размер ОЗУ на один коннект. Для Супера кэш общий. TcpRemoteBufferSize = 30720 вот что написано в документации: Объяснение InterBase производит упреждающее чтение для клиента и может посылать несколько строк данных в одном пакете. Чем больше размер пакета, тем больше данных пересылается за один раз. Показания к изменению параметра Сильно загруженная сеть. С ПФ3 сеть загружена по любому. Так что пробуйте. LockHashSlots = 1024 это я давно искал и скажу сразу, что насоветовал вам неправильно, о чем сильно сажалею. Объяснение Представьте себе, что хэш-таблица – это одномерный массив с цепочками, которые «свисают» из каждой ячейки этого массива. Менеджер блокировок хэширует имя объекта и затем вычисляет остаток от целочисленного деления этой величины на число хэш-слотов в массиве – таким образом он определяет ячейку, на которую надо «подвесить» блокировку данного объекта. Когда менеджер блокировок ищет определенную блокировку, он определяет ячейку хэш-массива аналогичным образом, а затем спускается вниз по цепочке, «подвешенной» к данной ячейке, и ищет объект с правильным именем. Если находится более одного объекта с этим именем, он проходит по цепочке «однофамильцев», которая подвешивается к первому объекту, который соответствует искомому имени. OK, got that? Чем длиннее будут цепочки, подвешенные к каждому слоту, тем медленнее будет работать менеджер блокировок. В среднем каждая цепочка должна иметь не более 10 ячеек. Показания к изменению параметра Первым признаком для изменения этого параметра должна быть общая низкая производительность системы с большим количеством пользователей и страниц в кэше. Запустите инструмент iblockpr из директории %INTERBASE%\Bin для печати блокировок. Если средняя длина более 10, увеличьте число хэш-слотов для этого параметра. Для начала умножьте среднюю длину цепочек на текущее число слотов и поделите на 9, а затем возьмите простое целое число, большее полученного значения (но меньшее 2048). Если вы производите подобную настройку на SuperServer’е, то необходимо также увеличить размер таблицы блокировок. Так что 1024 не катит. Число должно быть ПРОСТЫМ!

Парочка рычажков: в firebird.conf DefaultDbCachePages = 10000 количество закэшированных страниц базы в ОЗУ. Хоть для Классика и не рекомендуют ставить больше 1024, по моим субъективным наблюдениям так лучше. TcpRemoteBufferSize = 30720 Размер буфера приема/передачи, по умолчанию стоит 8192, если выставить максимум работать не будет. Если сетка хреновая лучше не трогать. LockHashSlots = 1024 Не совсем понял зачем это, но народ рекомендует ставить больше чем по умолчанию. ну и последнее клиентов базе надо подключать по TCP/IP т.е. строчка подключения должна выглядеть след образом: ip_сервера:диск:путь\до\базы.gdb надеюсь все так делают? а то я видел, что народ подключает базы через сетевые диски... После правки firebird.conf, FB надо перезапустить. Если это классик на Линуксе то не надо.

Профсегмент нам сообщал, что один терминальный клиент займет в памяти 50 мегов. Это только процесс ПФ3. Еще система сожрет и сама база. Я полагаю 2 Гб ОЗУ вам маловато будет если много подключений. Гляньте сколько памяти расходуют приложения. Потом дисковые операции от каждога клиента, одни на систему другие на базу, IDE шина не многопотоковая. Запросы будут становиться в очередь. САТА проблему не решит. Решит или RAID0, 0+1, 10, 5 или SCSI. Есть смысл базу отделить от терминала. Еще один момент. За один расчет между серваком и клиентом пробегает где то 200 метров данных. Поэтому мы в критичных отделах использовали гигабитку. Вот ссылка на прогу которой можно проанализировать базу http://ibase.ru/download/ibanalyst_r.zip. Она бесплатная и весьма полезная.

Я выставил 16К, жрать память стало безбожно. Но у нас сервак хороший, мы сначала подразумевали терминальное решение. Поэтому и купили 8Гб ОЗУ. Теперь там только Жар Птичка живет и больше половины пямяти занимает. Зато полет нормальный.

FB и не причем. ПФ3 оставляет открытые транзакции в немерянном количестве. Вот отчет IBAnalyst: Некоторые транзакции активны слишком долгое время. Самая старая транзакция Oldest active стартовала 109152 транзакций назад, в то время как среднее число транзакций в день примерно равно 320178. Это может быть сигналом, что имеет смысл проверить текущую схему обработки транзакций в ваших приложениях. Убедитесь, что транзакции завершаются commit/rollback после использования, и не находятся в активном состоянии долгое время без необходимости. Не стартуйте много ненужных транзакций. Также имеет смысл посмотреть на динамику количества транзакций в зависимости от активности клиентских приложений. Одной из причин большого числа активных транзакций может быть потеря transacton handle в коде приложения. То есть, приложение стартует транзакцию, но не завершает ее по commit/rollback. Другой причиной может быть использование BDE при отсутствии явного управления транзакциями, и параметр алиаса SQLPASSTHROUGH = SHARED NOAUTOCOMMIT. Старейшая активная транзакция Oldest active стартовала примерно 0.3 дней назад. Читаем далее... В вашей базе данных номер транзакции Oldest Snapshot меньше номера Oldest. Это происходит когда приложения попеременно стартуют транзакции snapshot. Также во всех серверах кроме IB7.1/7.5 это может происходить при конкурентном запуске транзакций Read Committed - они могут удерживать номер Oldest Snapshot точно так же как транзакции snapshot. Это приводит к задержкам старта автоматического сборщика мусора, бесполезности запуска sweep (gfix -sweep), и вообще к неуборке мусорных версий кооперативным сборщиком мусора. Седьмой день работы после последнего рестора между прочим. Может этот отчет разработчику показать? Пусть репу почешет... Правда слабо верится, что они что либо исправят! А как немного ускорить читайте выше. Помогает изменение размера страницы базы данных. Вот рекомендация из той же софтины: Размер страницы базы данных. Маркируется красным, если меньше 4096. Для улучшения производительности увеличьте размер страницы до 4 или 8 килобайт через backup/restore (с ключом -page n). (Firebird и InterBase 7.5 могут менять размер страницы до 16K).

Странно, у меня при открытии проекта выдает ошибку с неизвестным кодом. Уж весь гугл перерыл ничего не нашел. Шас качну последний релиз, покопаюсь, может, что то изменилось?

На энтой версии ПФ3 уже не работает. Начиная эдак с RC3.

Ответ на ваш вопрос можете узнать тут http://www.firebirdsql.org/. Всякие там RC1 - RC2 и тд, это релиз кандидаты. Можно сказать, что беты. График красноречивый правда? Релиз кандидат ставить на боевой сервер, занятие сомнительное, с моей точки зрения. Вот выйдет релиз тогда и посмотрим. А обзор новшеств ожидаемых в Firebird 2.0 можно узнать тут http://www.opennet.ru/opennews/art.shtml?num=5212

Для опеределенных задач Super Server лучше. Например на винду рекомендуется ставить именно его. Хоть Classic есть и для Винды. Разработчиков можно понять, какой смысл в классике, если Винда не умеет как следует распределять системные ресурсы между процессами. Один зависший процесс может сожрать все системные ресурсы. В Юниксе такого никогда не может произойти. Разве, что найдется такой идиот, что запустит сервер под рутом. Вот они и написали сервер в виндовом стиле. Поддержка многопроцессорности в Супере ожидается даже после выхода Firebird 2.0. Это будет В Vulcan, когда ее закончат незнаю. Может года через два.

Все верно больше 50% и не увидите. Я так понял у вас Super Server и проц новый, т.е HT (Hipertreading) он делать умеет? А это всеравно, что два проца в системе. Как я уже говорил, Super Server не умеет работать более чем на одном процессоре, а Classic Server на Windows ставить резона нет. Объясню почему. Классическая схема Unix состот в следующей реализации: на каждое подключение создается копия сервера. Т.е если есть процесс firebird слушающий порт 3050, то при коннекте клиента к этому порту будет создана копия процесса Firebird которая будет работать только с этим соединением, и так для каждого клиента. От этого и жадность до ОЗУ у такой схемы. Приходится плодить копии серверов для КАЖДОГО поключения, со своим кэшем. Super Server работает иначе. Есть один процесс для всех подключений, и для каждого клиента создается отдельный поток. Причем кэш один на всех. Т.е все подлкючения упакованы в один процесс. Так вот, Windows делать копии процессов не умеет. Архитектура Classic Server в ОС Windows будет тормозить (это мои наблюдения). Поэтому при планировании надо решать сразу, сколько у вас будет рабочих мест, какая архитектура для этого нужа, и какое железо вы для этого в состоянии выделить. В заключении могу сказать СУБД Firebird не смотря на все ее недостатки, является хорошим решением. При соответствующем тюнинге она может адаптироваться под любые требования. Основной ее недостаток - отсутствие хорошей документации. Большая часть документации по ней предназначена разработчикам. У меня ушло много времени на поиск того, что мне нужно. Да и ПФ3 далеко не идеальная программа. Например Профсегмент не смог внятно ответить, почему из базы нельзя выгрузить конструктив, если таблица которая его содержит имеет большой объем. Может всем это и пофиг, а для нас это проблема. Если кто знает как это сделать поделитесь плз.

На самом деле Firebird хорошо работает как на Windows так и на Linux. Мы затеяли крутить базу на Linux только из-за преимуществ Classic архитектуры, да и под большими нагрузками Linux работает лучше. Если количество клиентов не велико, нет никакой разницы какую ОС использовать. Вообще Firebird отличает от других СУБД отсутсвие внятной документации. Что вообще-то не свойственно открытым проектам. Взять тот же mysql к примеру. Ну да ладно. Есть хороший ресурс по Interbase/Firebird - http://forum.ibase.ru. Просматривая сообщения этого ресурса, можно найти много интересного. Что касается ПФ3. Анализируя базу, легко понять, что разработчики подсовывают нам базы сделанные в Interbase. Размер страницы у таких баз 1 килобайт. Это не серьезно. Firebird умеет работать с базой размер блока которой 16К. Расплата за это - резкое увеличение потребления ОЗУ. Для примера, у нас 30 - 35 клиентов, процессы Firebird в ОЗУ занимают 5.5 Гиг. Один клиент примерно 160 Мегабайт. Архитектура Super Server более экономичная в этом плане, но не умеет работать на двух процессорах. Для однопроцессорных машин это тоже актуально потому, что становится не возможно использовать HT. Для винды имеет смысл установить размер блока в 4К, это равно размеру кластера NTFS. Вообще размер блока подбирается методом научного тыка. Выставишь большим - начнет свопить и производительность резко упадет. ОЗУ никогда лишьним не бывает правда ведь? Изменить размер блока можно утилитой gbak. Читайте к ней описание. Сначала надо сделать бэкап базы, потом рестор с с параметром -Р 4096. Еще один момент. ПФ3 работает с базой очень интенсивно, а по умолчанию в базах включена кооперативная уборка мусора через 20000 транзакций. Может получиться так, что чистка начнется как раз тогда когда вы что то расчитываете. Это надо вырубить. Ставим sweep interval 0. И делаем свип по расписанию ночью. Ну и самое последнее когда уж ничего не помогает, поможет бэкап/ресторе. Анализировать базу можно средством IBAnalyst. Взять можно на www.ibase.ru.

Могу рассказать как мы решили этот вопрос у себя на предприятии. Базу надо крутить на хорошем железе. У нас для этого стоит двухголовый Xeon 3 ГГц с быстрым RAID контроллером. Установлена ОС Linux Slackware, kernel 2.6.13 с поддержкой SMP и HT. Сетевой стек заточен под гигабитный линк (рекомендации можно найти на www.opennet.ru). Firebird в варианте classic, дабы использовать многопроцессорность, суперсервер умеет работать только на одном процессоре. Linux выбран как раз потому, что classic вариант на Венде жутко тормозит. Затем был проведен анализ файлика firebird.conf, и в него были внесены соответственные изменения, после чтения документации к базе данных. Эти бесценные данные можно взять на сайте разработчиков Firebird. Ну и самое последнее, базу надо регулярно реструктурировать, по возможности выгружать из нее старые проекты. Ну backup-restore естественно делать. Пользователи подключены гигабитным линком к серверу. Итог всей нашей деятельности. Более тридцати пользователей работают одновременно без тормозов.