Перейти к публикации
forum-okna.ru

Скорость работы ПР3 по сети.


Konstruktor

Рекомендованные сообщения

.....

А насчет всех подряд, так пусть сядут с технологом и вместе настроят, не так часто это и делается. У нас кстати прогу KLAES "админит" технолог (в кавычках потому, что нечего там админить если честно .....

А на чем работаете? на ПВХ? Так там да, там все в течении недели строится, потом за сезон все откатывается, убираются все косяки и вперед. А вот с алюминием там все иначе. Особенно если фасадку считать!

Моей базе по алюминию сейчас 5 лет. И изменения я вношу очень регулярно. Вы будете смеяться, но например в технологию PROVEDAL! (Совсем не фасадка, да?)

Ссылка на комментарий
Поделиться на других сайтах


Оконный портал tybet.ru | Подписка на новости | Бесплатные объявления | Наша телега | База оконных знаний | ОНЛАЙН-ВЫСТАВКА



  • Ответы 127
  • Created
  • Последний ответ

Top Posters In This Topic

А на чем работаете? на ПВХ? Так там да, там все в течении недели строится, потом за сезон все откатывается, убираются все косяки и вперед

 

о-о-чень не согласен :D !

С "нуля" настраивал и ПВХ и алюминий различных мастей и призводителей. Однозначно так говорить нельзя. В фасадке накручиваются варианты по соединениям, а в ПВХ в основном фурнитура,ламинат. И , поверьте, настраивать всевозможные извращения фурнитуры гораздо трудоемко чем, бесконечность вариантов соединений.

 

Лично для меня гоаздо легше и быстрее настроить алюминиевую систему чем ПВХ(особенно фурнитуру).

Речь идет о настоящей настройке, а не о поверхностной...

 

ну это мы от темы отвлеклись. :P

Ссылка на комментарий
Поделиться на других сайтах

о-о-чень не согласен :D !

С "нуля" настраивал и ПВХ и алюминий различных мастей и призводителей. Однозначно так говорить нельзя. В фасадке накручиваются варианты по соединениям, а в ПВХ в основном фурнитура,ламинат. И , поверьте, настраивать всевозможные извращения фурнитуры гораздо трудоемко чем, бесконечность вариантов соединений.

 

Лично для меня гоаздо легше и быстрее настроить алюминиевую систему чем ПВХ(особенно фурнитуру).

Речь идет о настоящей настройке, а не о поверхностной...

 

ну это мы от темы отвлеклись. :P

Фурнитура в ПВХ - согласен, сладенькая! B) А вот с цветами, это в алюминий скорее. Хотя сейчас и там и там кошмар сколько вариантов. В ПВХ с соединениями попроще, а алюминий этож конструкционный материал! крылатый металл, блин! Так, что один другого стоит. Мне правда все уши прожужжали, что в основном ПВХ-ники работают просто, без изысков, без наворотов - в основном по белому и со стандартной фурнитурой, а все остальное чуть-ли не дикость и чаще и проще вообще "от руки" вписать! Не верю, но ..... Наши по полной заморачиваются, но в этом как раз я виноват - требую.

Ссылка на комментарий
Поделиться на других сайтах

Фурнитура в ПВХ - согласен, сладенькая! :P ...

По мне фурнитура в проге, это самое простое. Забивал четыре различных фурнитурных системы для окон ПВХ, с количеством шурупов её крепящими (здесь может быть погрешность). Самое нудное все артикулы в базу забить. А так максимум неделя, только надо знать, как всё работает.

При этом самые сложные открывания, типа поворотно-откидных арок, могут никогда не понадобиться.

Ссылка на комментарий
Поделиться на других сайтах

Однако занесло же нас... :(

 

Спасибо, всем кто ответил. Были дельные советы.

Изменено пользователем Konstruktor
Ссылка на комментарий
Поделиться на других сайтах

Оракл покупать придется тогда всем, а цена не детская, причем, администрирование сей продукта само по себе требует знаний не ниже средних. Компаний наберется единицы, а остальные ... Использование "паленого" Оракла не обсуждается.

Кстати, на подходе Огненная Птица версии 2, может быть она что-то улучшит, хотя и нет сомнений, что не всё.

8-й и 9-й бесплатно, между прочим...

Ссылка на комментарий
Поделиться на других сайтах

к разработчикам нельзя придираться - программу создавали чтоб на на ней 1 заказ считать с 1артикулом рамы,импоста,створки, желательно без вставок/составов )(см. выше. о причинах тормоза). А менеджер, с...ка решил посчитать 250 изделий из фасадки. Все и встало/полетело/затормозило. Админ, паразит, почему программа тормозит! Хреново работаешь. Зря хлеб ешь, зарплаты не достоин! И вообще сидишь там весь день чем занимаешся? Считаешь? Че считаешь? Раскладку внутреннюю, а на хрена??? Как программа не может? Мы ж за нее такие бабки отдали! Почему кладовщицы жалуются, что неудобно работать! Они отчет по приходу за месяц ждали 2 часа , когда программа выведет на печать!

 

:(:):D

 

Улыбнуло.

Думаю для многих это сущая реальность :D

Ссылка на комментарий
Поделиться на других сайтах

что-то разговор далеко в сторону отошёл от проблемы скорости работы ПС3.

 

 

Давайте подведём итог отчего же появляются тормоза ПС3 при работе по сети:

 

1) Скорость работы Firebird

2) Постоянные запросы к аппаратному ключу защиты.

3) Качество сетевого оборудования и загруженность сети.

 

Третий пункт для себя я сразу отметаю, потому что сеть у меня загружена слабо, а сетевое оборудование вполне приличное. Да и к тому же локально (на той же машине, что и Файрбёрд) ПС3 тормозит точно также.

 

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

 

По первому пункту, как утверждают некоторые участники форума, можно перейти на версию Fb для Linux, которая работает быстрее, но для большинства участников дискуссии этот способ неприемлем в связи с необходимостью установки отдельного сервера (от 1000$ если покупать что-то уровня Pentium D 920, 1 Гб озу, и 2 жёстких диска в конфигурации RAID1) и наличием СА с достаточно глубоким знанием Linux.

Следовательно, нужно выяснить, как повысить производительность Firebird на Windows-системах.

Давайте подумаем в этом направлении. :blink:

 

 

Немного отойдя от темы, я хочу рассказать об опыте работы с 1С по сети.

Если почитать форумы об 1С, то можно прийти к выводу, что оптимальная схема работы с этой системой - Terminal Services + 1C с dbf-базами.

Известно, что с файловой системой работа происходит быстрее, чем c SQL-сервером, но при работе по сети огромное количество файлов (штук 350 на каждого клиента в конфигурации Торговля+Склад 1С) создаёт большой тормоз из-за отслеживания блокировок. В терминальном режиме с dbf-базами 1С работает быстрее всего.

Мне кажется, если бы разработчики оставили выбор использовать ли IB или DBF на наше усмотрение, решилось бы много проблем.

Ссылка на комментарий
Поделиться на других сайтах

Третий пункт для себя я сразу отметаю...

Аналогично!

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

По моему немного переуседствовали! Пустая(!) база на хорошем серваке(!), локально(!) работает медленнее(!) чем когда то ПР2 с кучей проектов , но с ключом LPT.

 

Да и к тому же локально (на той же машине, что и Файрбёрд) ПС3 тормозит точно также.

...уже высказал.

Ссылка на комментарий
Поделиться на других сайтах

что-то разговор далеко в сторону отошёл от проблемы скорости работы ПС3.

Давайте подведём итог отчего же появляются тормоза ПС3 при работе по сети:

 

1) Скорость работы Firebird

2) Постоянные запросы к аппаратному ключу защиты.

3) Качество сетевого оборудования и загруженность сети.

 

Третий пункт для себя я сразу отметаю, потому что сеть у меня загружена слабо, а сетевое оборудование вполне приличное. Да и к тому же локально (на той же машине, что и Файрбёрд) ПС3 тормозит точно также.

 

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

 

По первому пункту, как утверждают некоторые участники форума, можно перейти на версию Fb для Linux, которая работает быстрее, но для большинства участников дискуссии этот способ неприемлем в связи с необходимостью установки отдельного сервера (от 1000$ если покупать что-то уровня Pentium D 920, 1 Гб озу, и 2 жёстких диска в конфигурации RAID1) и наличием СА с достаточно глубоким знанием Linux.

Следовательно, нужно выяснить, как повысить производительность Firebird на Windows-системах.

Давайте подумаем в этом направлении. :P

Немного отойдя от темы, я хочу рассказать об опыте работы с 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.

Ссылка на комментарий
Поделиться на других сайтах

Я смотрел загрузку ОЗУ и CPU при работе с ПС3. Никогда не видел больше 50% CPU и больше 30% (вместе со всеми другими службами и ядром ОС) ОЗУ (у меня два гига). Но и клиентов у меня пока почти в 10 раз меньше, чем у вас. А тормоза всё равно есть. Отсюда могу сделать один вывод - диски.

У меня RAID1 на базе SATA-дисков (7200 оборотов). Пока не смотрел системным монитором загрузку дисков. Посмотрю - попробую сварганить что-то типа RAM-диска и поместить в него базу.

Спасибо за рекомендации по настройке FB, попробую и отпишусь.

Насчёт документации согласен, у MySQL очень полная и подробная документация. Наверное тут сыграл роль тот факт, что MySQL стоит на 90% web-серверах, а FB такого распространения не получил.

Изменено пользователем yar
Ссылка на комментарий
Поделиться на других сайтах

Я смотрел загрузку ОЗУ и 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 далеко не идеальная программа. Например Профсегмент не смог внятно ответить, почему из базы нельзя выгрузить конструктив, если таблица которая его содержит имеет большой объем. Может всем это и пофиг, а для нас это проблема. Если кто знает как это сделать поделитесь плз.

Ссылка на комментарий
Поделиться на других сайтах

У меня двухъядерный процессор без HT, графики загрузки я смотрел раздельно.

Я ставил и Superserver, и Classic. Хочу посмотреть производительность каждого на моей конкретно системе.

Субъективно, Classic несколько быстрее, но я думаю до тех пор, пока мало пользователей, то есть хватает ОЗУ на всех.

Для начала планирую покрутить буфера, а там посмотрим чего выйдет.

Ссылка на комментарий
Поделиться на других сайтах

У меня двухъядерный процессор без HT, графики загрузки я смотрел раздельно.

Я ставил и Superserver, и Classic. Хочу посмотреть производительность каждого на моей конкретно системе.

Субъективно, Classic несколько быстрее, но я думаю до тех пор, пока мало пользователей, то есть хватает ОЗУ на всех.

Для начала планирую покрутить буфера, а там посмотрим чего выйдет.

 

Для чего тогда Super server? И что все таки лучше ставить на 2-х ядерный сервак.

Где то видел я дистрибутив FireBird именно для двух-процессорных серваков, но где не помню и что за релиз был. Или у меня уже крыша съезжает. Давно было. не придал значения. не нужен был ни FB тем более сервака такого не предвиделось.

Ссылка на комментарий
Поделиться на других сайтах

Для чего тогда Super server? И что все таки лучше ставить на 2-х ядерный сервак.

Где то видел я дистрибутив FireBird именно для двух-процессорных серваков, но где не помню и что за релиз был. Или у меня уже крыша съезжает. Давно было. не придал значения. не нужен был ни FB тем более сервака такого не предвиделось.

 

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

Ссылка на комментарий
Поделиться на других сайтах

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

Так он же вроде уже вышел :((FB2) Я тут пробовал его ставить. Дистриб скачал с их сайта. Разницы никакой. Я так и не понял. Это что НЕ официальный релиз, типа бета версии. Или что..ЭТО

Изменено пользователем Konstruktor
Ссылка на комментарий
Поделиться на других сайтах

Так он же вроде уже вышел :((FB2) Я тут пробовал его ставить. Дистриб скачал с их сайта. Разницы никакой. Я так и не понял. Это что НЕ официальный релиз, типа бета версии. Или что..ЭТО

 

Ответ на ваш вопрос можете узнать тут http://www.firebirdsql.org/. Всякие там RC1 - RC2 и тд, это релиз кандидаты. Можно сказать, что беты. График красноречивый правда? Релиз кандидат ставить на боевой сервер, занятие сомнительное, с моей точки зрения. Вот выйдет релиз тогда и посмотрим.

 

А обзор новшеств ожидаемых в Firebird 2.0 можно узнать тут http://www.opennet.ru/opennews/art.shtml?num=5212

Ссылка на комментарий
Поделиться на других сайтах

Ответ на ваш вопрос можете узнать тут http://www.firebirdsql.org/. Всякие там RC1 - RC2 и тд, это релиз кандидаты. Можно сказать, что беты. График красноречивый правда? Релиз кандидат ставить на боевой сервер, занятие сомнительное, с моей точки зрения. Вот выйдет релиз тогда и посмотрим.

 

А обзор новшеств ожидаемых в Firebird 2.0 можно узнать тут http://www.opennet.ru/opennews/art.shtml?num=5212

 

Да, именно оттуда и брал. Не стал испытывать до конца :( , как только увидел что мой настроеный БэкАп на ентой версии уже не работает :thumbsup: .

Изменено пользователем Konstruktor
Ссылка на комментарий
Поделиться на других сайтах

Да, именно оттуда и брал. Не стал испытывать до конца :( , как только увидел что мой настроеный БэкАп на ентой версии уже не работает :thumbsup: .

 

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

Ссылка на комментарий
Поделиться на других сайтах

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

 

Вот :Firebird-2.0.0.12724-0-Win32 на ней ПР3 работает точно!

но не поддерживает gfix. Поставил посмотрел, удалил. Глубоко не копал.

 

Глянул щас , а ведь это кандидат 4

Изменено пользователем Konstruktor
Ссылка на комментарий
Поделиться на других сайтах

Вот :Firebird-2.0.0.12724-0-Win32 на ней ПР3 работает точно!

но не поддерживает gfix. Поставил посмотрел, удалил. Глубоко не копал.

 

Глянул щас , а ведь это кандидат 4

 

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

Ссылка на комментарий
Поделиться на других сайтах

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

 

Работает точно также как и на 1,5. и Профокна с ним работают по сети. Тормоз все тот же.

ПР2 на FB работает так же как и работал, так что причем тут влияние на скорость работы FB?

Н-е-е-е-т. Дело в другом. Или ядро ПР3 много жрет, или ключ... плюс все-таки и FB тоже кое что добавил.

Изменено пользователем Konstruktor
Ссылка на комментарий
Поделиться на других сайтах

Работает точно также как и на 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).

Ссылка на комментарий
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.

  • Сейчас на странице   0 пользователей

    • Нет пользователей, просматривающих эту страницу.



×
×
  • Создать...

Важная информация

Условия и правила использования форума Правила.