Basmach
-
Публикации
20 -
Зарегистрирован
-
Посещение
Сообщения, опубликованные пользователем Basmach
-
-
Гм, ключи объеденили, эт наверное сеть сегментировали а на сервак две карточки сетевые поставили? Я правильно понимаю? А реструктуризация это вообще то backup/restore простой. Вернее сначала backup/restore делается, а потом для нужд нового екзешника новые поля в таблички добавляются.
О пользе данного действия я уже писал. У баз сильно индексы едут, тока backup/restore и помогает.
-
И как у вас, ПС3 без тормозов работает?
Кеширование записи сильно помогает?
Пробовал ради эксперимента выключать. Скорость записи падает до 10 Мб/сек, чтение остается на уровне 80 - 120 Мб/сек. Разницы особой не видно. База работает достаточно быстро, особенно если она меньше гига по объему. Разрастись мы ей не даем, периодически выгружаем данные. Дело тут все в том, что для того, чтоб базу реструктурировать ее надо тащить на другую машину. И локально это делать. А ОЗУ на офисных машинах не хватает к сожалению... Не покупать же еще один сервер для реструктуризации...
-
А это более детально. Это график за период с пятницы до понедельника. Хорошо видно как в пятницу при интенсивной работе база кушает память. Есть еще график сетевой активности, показательно, что он повторяет график загрузки процессора.
-
Хотелось бы ещё увидеть графики загрузки дисковой подсистемы (очередь команд) и использования ОЗУ.
А что ещё крутится на серваке, кроме Файрбёрда? И какая ОС? Файрбёрд классик или суперсервер?
На серваке Линукс, кроме Птички ничего не крутится. Птичка в варианте классик. График дисковой активности показывать смысла не имеет потому как работает раид с кэшированием записи. Т.е данные считаются записанными как только они попали в кэш контроллера. Использование ОЗУ выкладываю:
-
Маленький наглядный материал. Сервер 2х3.0 ГГц Xeon, 8 Гб ОЗУ. На нем три базы Firebird каждая по гигу или больше. С базами работает ПФ3. Пользователей штук 35, график загрузки процов:
-
Не собираюсь быть здесь рупором ПрофСегмента, но хочу заметить следующее:
1. Свою собственность и свой кусок хлеба каждый охраняет в меру своих умений, знаний и склада характера - можно подумать, что кто-то спрашивает мнение соседа когда покупает замок для своей двери?
2. простая критика типа: "...Механизм авторизации пользователей никуда не годится..." - сама никуда не годится т.к. не несет в себе конструктива. просто констатация факта.
3. Если есть какие-либо мысли, предложения, пожелания и т.д. - компания ПрофСегмент открыта для диалога (знаю по своему опыту).
По поводу инструментов удаленной работы с базой совершенно согласен, не всегда сисадмин я вляется админом ПС - обновление с реструктуризацией - проблема. Но по адресу ли претензия, не относится ли это к разработчикам FireBird? (не спец я по базам, не знаю...)
Этот замок в виде гениальной защиты мешает нормально работать! Я не говорил, что защиту надо убрать вовсе, ее надо переработать!
Насчет механизма авторизации поясню:
Все пользователи работают в базе от пользователя 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-ах. Но кое что сообрзю Действительно полезная штука. Жаль тока ПР от этого быстрее работать не очень то будет.
Парочка рычажков:
в firebird.conf
DefaultDbCachePages = 10000
количество закэшированных страниц базы в ОЗУ. Хоть для Классика и не рекомендуют ставить больше 1024, по моим субъективным наблюдениям так лучше.
TcpRemoteBufferSize = 30720
Размер буфера приема/передачи, по умолчанию стоит 8192, если выставить максимум работать не будет. Если сетка хреновая лучше не трогать.
LockHashSlots = 1024
Не совсем понял зачем это, но народ рекомендует ставить больше чем по умолчанию.
ну и последнее клиентов базе надо подключать по TCP/IP т.е. строчка подключения должна выглядеть след образом:
ip_сервера:диск:путь\до\базы.gdb
надеюсь все так делают? а то я видел, что народ подключает базы через сетевые диски...
После правки firebird.conf, FB надо перезапустить. Если это классик на Линуксе то не надо.
-
У меня сервак это:
Страницу изменил на 8192. Пока ниче не заметил. мож какие будут советы. БэкАп/Ресторе каждый день по расписанию.
Профсегмент нам сообщал, что один терминальный клиент займет в памяти 50 мегов. Это только процесс ПФ3. Еще система сожрет и сама база. Я полагаю 2 Гб ОЗУ вам маловато будет если много подключений. Гляньте сколько памяти расходуют приложения. Потом дисковые операции от каждога клиента, одни на систему другие на базу, IDE шина не многопотоковая. Запросы будут становиться в очередь. САТА проблему не решит. Решит или RAID0, 0+1, 10, 5 или SCSI. Есть смысл базу отделить от терминала. Еще один момент. За один расчет между серваком и клиентом пробегает где то 200 метров данных. Поэтому мы в критичных отделах использовали гигабитку.
Вот ссылка на прогу которой можно проанализировать базу http://ibase.ru/download/ibanalyst_r.zip.
Она бесплатная и весьма полезная.
-
Однозначно помогает, после увеличения до 4K пару месяцев назад полегчало, может стоит увеличить еще больше (8-16K)
Старейшая транзакция 3.6 дней, бд работает 9 дней.
Автоматическая сборка мусора может стартовать 14 раз в день (маленький sweep interval)
Что мешает пофиксить эти мелочи Профсегменту?
Я выставил 16К, жрать память стало безбожно. Но у нас сервак хороший, мы сначала подразумевали терминальное решение. Поэтому и купили 8Гб ОЗУ. Теперь там только Жар Птичка живет и больше половины пямяти занимает. Зато полет нормальный.
-
Работает точно также как и на 1,5. и Профокна с ним работают по сети. Тормоз все тот же.
ПР2 на FB работает так же как и работал, так что причем тут влияние на скорость работы FB?
Н-е-е-е-т. Дело в другом. Или ядро ПР3 много жрет, или ключ... плюс все-таки и FB тоже кое что добавил.
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).
-
Вот :Firebird-2.0.0.12724-0-Win32 на ней ПР3 работает точно!
но не поддерживает gfix. Поставил посмотрел, удалил. Глубоко не копал.
Глянул щас , а ведь это кандидат 4
Странно, у меня при открытии проекта выдает ошибку с неизвестным кодом. Уж весь гугл перерыл ничего не нашел. Шас качну последний релиз, покопаюсь, может, что то изменилось?
-
Да, именно оттуда и брал. Не стал испытывать до конца , как только увидел что мой настроеный БэкАп на ентой версии уже не работает .
На энтой версии ПФ3 уже не работает. Начиная эдак с RC3.
-
Так он же вроде уже вышел(FB2) Я тут пробовал его ставить. Дистриб скачал с их сайта. Разницы никакой. Я так и не понял. Это что НЕ официальный релиз, типа бета версии. Или что..ЭТО
Ответ на ваш вопрос можете узнать тут http://www.firebirdsql.org/. Всякие там RC1 - RC2 и тд, это релиз кандидаты. Можно сказать, что беты. График красноречивый правда? Релиз кандидат ставить на боевой сервер, занятие сомнительное, с моей точки зрения. Вот выйдет релиз тогда и посмотрим.
А обзор новшеств ожидаемых в Firebird 2.0 можно узнать тут http://www.opennet.ru/opennews/art.shtml?num=5212
-
Для чего тогда Super server? И что все таки лучше ставить на 2-х ядерный сервак.
Где то видел я дистрибутив FireBird именно для двух-процессорных серваков, но где не помню и что за релиз был. Или у меня уже крыша съезжает. Давно было. не придал значения. не нужен был ни FB тем более сервака такого не предвиделось.
Для опеределенных задач Super Server лучше. Например на винду рекомендуется ставить именно его. Хоть Classic есть и для Винды. Разработчиков можно понять, какой смысл в классике, если Винда не умеет как следует распределять системные ресурсы между процессами. Один зависший процесс может сожрать все системные ресурсы. В Юниксе такого никогда не может произойти. Разве, что найдется такой идиот, что запустит сервер под рутом. Вот они и написали сервер в виндовом стиле. Поддержка многопроцессорности в Супере ожидается даже после выхода Firebird 2.0. Это будет В Vulcan, когда ее закончат незнаю. Может года через два.
-
Я смотрел загрузку ОЗУ и CPU при работе с ПС3. Никогда не видел больше 50% CPU и больше 30% (вместе со всеми другими службами и ядром ОС) ОЗУ (у меня два гига). Но и клиентов у меня пока почти в 10 раз меньше, чем у вас. А тормоза всё равно есть. Отсюда могу сделать один вывод - диски.
У меня RAID1 на базе SATA-дисков (7200 оборотов). Пока не смотрел системным монитором загрузку дисков. Посмотрю - попробую сварганить что-то типа RAM-диска и поместить в него базу.
Спасибо за рекомендации по настройке FB, попробую и отпишусь.
Насчёт документации согласен, у MySQL очень полная и подробная документация. Наверное тут сыграл роль тот факт, что MySQL стоит на 90% web-серверах, а FB такого распространения не получил.
Все верно больше 50% и не увидите. Я так понял у вас Super Server и проц новый, т.е HT (Hipertreading) он делать умеет? А это всеравно, что два проца в системе. Как я уже говорил, Super Server не умеет работать более чем на одном процессоре, а Classic Server на Windows ставить резона нет. Объясню почему.
Классическая схема Unix состот в следующей реализации: на каждое подключение создается копия сервера. Т.е если есть процесс firebird слушающий порт 3050, то при коннекте клиента к этому порту будет создана копия процесса Firebird которая будет работать только с этим соединением, и так для каждого клиента. От этого и жадность до ОЗУ у такой схемы. Приходится плодить копии серверов для КАЖДОГО поключения, со своим кэшем. Super Server работает иначе. Есть один процесс для всех подключений, и для каждого клиента создается отдельный поток. Причем кэш один на всех. Т.е все подлкючения упакованы в один процесс. Так вот, Windows делать копии процессов не умеет. Архитектура Classic Server в ОС Windows будет тормозить (это мои наблюдения). Поэтому при планировании надо решать сразу, сколько у вас будет рабочих мест, какая архитектура для этого нужа, и какое железо вы для этого в состоянии выделить.
В заключении могу сказать СУБД Firebird не смотря на все ее недостатки, является хорошим решением. При соответствующем тюнинге она может адаптироваться под любые требования. Основной ее недостаток - отсутствие хорошей документации. Большая часть документации по ней предназначена разработчикам. У меня ушло много времени на поиск того, что мне нужно. Да и ПФ3 далеко не идеальная программа. Например Профсегмент не смог внятно ответить, почему из базы нельзя выгрузить конструктив, если таблица которая его содержит имеет большой объем. Может всем это и пофиг, а для нас это проблема. Если кто знает как это сделать поделитесь плз.
-
что-то разговор далеко в сторону отошёл от проблемы скорости работы ПС3.
Давайте подведём итог отчего же появляются тормоза ПС3 при работе по сети:
1) Скорость работы Firebird
2) Постоянные запросы к аппаратному ключу защиты.
3) Качество сетевого оборудования и загруженность сети.
Третий пункт для себя я сразу отметаю, потому что сеть у меня загружена слабо, а сетевое оборудование вполне приличное. Да и к тому же локально (на той же машине, что и Файрбёрд) ПС3 тормозит точно также.
По второму пункту понятно, что сделать ничего нельзя - разработчики боятся, что их труд украдут.
По первому пункту, как утверждают некоторые участники форума, можно перейти на версию Fb для Linux, которая работает быстрее, но для большинства участников дискуссии этот способ неприемлем в связи с необходимостью установки отдельного сервера (от 1000$ если покупать что-то уровня Pentium D 920, 1 Гб озу, и 2 жёстких диска в конфигурации RAID1) и наличием СА с достаточно глубоким знанием Linux.
Следовательно, нужно выяснить, как повысить производительность Firebird на Windows-системах.
Давайте подумаем в этом направлении.
Немного отойдя от темы, я хочу рассказать об опыте работы с 1С по сети.
Если почитать форумы об 1С, то можно прийти к выводу, что оптимальная схема работы с этой системой - Terminal Services + 1C с dbf-базами.
Известно, что с файловой системой работа происходит быстрее, чем c SQL-сервером, но при работе по сети огромное количество файлов (штук 350 на каждого клиента в конфигурации Торговля+Склад 1С) создаёт большой тормоз из-за отслеживания блокировок. В терминальном режиме с dbf-базами 1С работает быстрее всего.
Мне кажется, если бы разработчики оставили выбор использовать ли IB или DBF на наше усмотрение, решилось бы много проблем.
На самом деле 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 естественно делать. Пользователи подключены гигабитным линком к серверу.
Итог всей нашей деятельности.
Более тридцати пользователей работают одновременно без тормозов.
Скорость работы ПР3 по сети.
в ПрофСегмент
Опубликовано:
Из ком строки backup/restore по идее можно сделать из под пользователя. Для этого надо явно указать ключи -user и -password, соотвественно надо иметь разрешения на запуск файлика gbak на уровне файловой системы.
Изменения в таблички ПС3 автоматически не делает. Факт вполне проверенный. Чтоб их делать без реструктуризации, надо знать, что поменялось в базе и руками писать скрипт. Профсегмент естественно такой информации не дает. Было бы очень неплохо если бы они изменили такой подход. Вместо реструктуризации присылали скрипты. Тогда было бы видно что меняется.
Запускать ПС3 под Wine никакого смысла нет, он под виндой то работает не очень, а тут столько глюков будет!!! Первое что в голову приходит драйвера к хаспу, потом отчеты заточены под ослика ИЕ, импорт экспорт опять же, RAR нужен а он под Линукс не бесплатный, WinZip с gzip не дружит. Короче сумма гиморов совершенно не адекватна. Ну разве, что на вас наехали за нелицензионную винду. Такое бывает конечно, но мы ведь тут все люди честные, конрафактом не пользуемся