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.