Быстродействие

[shurik--1]

Возможно эта нема уже не раз всплывала на форуме, но все же:
какие есть реальные способы ускорения работоспособности Галактики?

При расчете сальдовых остатков, например в акте на списание, по одному участку расчет идет несколько часов. Помогает ли ускорить этот процесс операция "Пересчет сальдовых остатков" в модуле "Учёт в производстве"?
Возможно ли ускорение работы Галактики с помощью операций над базой данных в SQL-сервере ,например дефрагментация индексов?

[edward_K]

Если расчет идет дольше 5 минут - это ошибка. Не важно чья - галактики, слабого сервера, или еще чего.
Как миниум есть смысл написать в ТП.
Зачем в акте на списание вообще считать сальдо? Вы не написали в какой момент это происходит, сколько позиций в ордере и т.п.
Что творится при этом в журнале?
Всю эту инфу следует отправить в ТП + отчет о рабочей станции.
Дефрагментация как то поможет. Помогут и другие рекомендации по оптимизации сервера - типа разнести файлы базы на разные раиды(разные физические диски). Я обычно файл данных и индексов кладу на один раид, журнал, логи на другой.
Но это все полумеры - ну выиграете 30-40 % - но это все равно мало.
можно еще врубить UserTablesLocalCache=On - снизите нагрузку на сервер. Ну временные файлы на локале хранить и так далее.
Но скорей всего в данном случае ошибка в коде или в очень большом движении по этому складу(в последнем случае нужно убрать старое движение, например заведя акт об излишках и убрав все старые ордера - штатного механизма нет - но это тоже полумера) .

[shurik--1]

Спасибо за советы!
На счет акта на списание: при добавлении новых позиций по F3 происходит операция "Расчет сальдовых остатков". Вот эта операция и происходит более 5 часов.
В таблице Saldomc более 5 млн. записей. Галактика 7.12

[spark]

Если расчет идет дольше 5 минут - это ошибка. Не важно чья - галактики, слабого сервера, или еще чего.
Как миниум есть смысл написать в ТП.
Зачем в акте на списание вообще считать сальдо? Вы не написали в какой момент это происходит, сколько позиций в ордере и т.п.
Что творится при этом в журнале?
Всю эту инфу следует отправить в ТП + отчет о рабочей станции.
Дефрагментация как то поможет. Помогут и другие рекомендации по оптимизации сервера - типа разнести файлы базы на разные раиды(разные физические диски). Я обычно файл данных и индексов кладу на один раид, журнал, логи на другой.
Но это все полумеры - ну выиграете 30-40 % - но это все равно мало.
можно еще врубить UserTablesLocalCache=On - снизите нагрузку на сервер. Ну временные файлы на локале хранить и так далее.
Но скорей всего в данном случае ошибка в коде или в очень большом движении по этому складу(в последнем случае нужно убрать старое движение, например заведя акт об излишках и убрав все старые ордера - штатного механизма нет - но это тоже полумера) .

Интересно, а в трехуровневой архитектуре UserTablesLocalCache лучше включать или выключать? При условии что и БД и сервер приложений находятся на одном серваке.

[edward_K]

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

[spark]

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

Не, у меня версия 8.1, я просто вклинился в вашу беседу...
Так как Вы думаете, 3-хуровневой это поможет?

[edward_K]

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

[LaaLaa]

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

[KATZ]

Новую тему заводить не стал, решил здесь спросить, т. к. проблема всё та же - быстродействие.

Обновили "Галактику". В "Зарплате" запускаю печать справки о расчете больничного (больничный уже рассчитан, только печать справки). Жду, жду, жду... Минуты через 3 справка, наконец, появляется. Думаю, надо посмотреть, что происходит. Запускаю монитор Pervasive, потом снова печать справки. Когда справка появилась на экране, смотрю в монитор, и получается, что для печати одной справки по одному человеку "Галактика" прочитала из БД 1 млн. 255 тыс. записей! Осмелюсь предположить, что это раз в 1000 больше, чем действительно требуется для печати справки. Стоит патч Z_SREDN_RES_8101250.

Это только у нас так, или кто-нибудь еще сталкивался?

[edward_K]

ну 3 минуты это вообще долго - обычно секунд 20-30 - что при условии что отпуск считается за 3 с тоже долго.

[KATZ]

Понятно, что долго. С прежними патчами такого не было. Дело даже не в 3-х минутах, а в миллионе обращений к БД.

Г-да разработчики! Не хотите высказаться по этому поводу и что-нибудь пояснить?

[edward_K]

а по каким таблам не удалось выяснить?
А к разработчикам надо на минском форуме обращаться.

[KATZ]

а по каким таблам не удалось выяснить?

В Pervasive, конечно, можно включить трассировку, но для обработки трассировочных файлов надо специальный парсер писать... Да и, зная название таблицы, своими силами всё равно не поправить. Самый вероятный диагноз - в алгоритме появилась выборка с атрибутом NoIndex, вот программа какую-нибудь таблицу и сканирует от начала до конца.

[LaaLaa]

Коллеги, еще раз повторюсь. Также писал про это в смежной ветке Быстродействие.

К сожалению проблемы производительности в Галактике в частности (и в программах вообще) возникают именно в условиях эксплуатации системы на площадке конкретных заказчиков. На проблему могут влиять огромное количество разных факторов: это и сам код программы, и объем данных заказчика, и особенности распределения данных, и конфигурация оборудования, и топология сети, и количество активных пользователей, и особенности методики учета, и т.д., и т.п.

Наш отдел разработки и тестирования на собственных тестовых площадках, не может физически повторить все возможное сочетания этих факторов. Несмотря на все усилия всегда находится какая то особенность у заказчика, которая приводит к замедлению. По этому проблему нужно решать с учетом тех конкретных условий в которых она возникает. Мерить температуру и делать рентген нужно конкретному пациенту, а не его манекену в испытательной лаборатории.

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

Метод который вам предлагаю состоит в следующем:
1) Выявить пользовательские операции, требующие ускорения с точки зрения бизнеса.
2) Получить детальные диагностические данные, относящиеся к конкретному периоду времени или конкретной операции, которые позволят идентифицировать причины задержек.
3) Передать это материал в отдел разработки (чрез тех поддержку)
4) На основе этих данных будут выработаны рекомендации или улучшения в программе, которые дают наилучший эффект по оптимизации.

Для выполнения тестовых измерений рекомендую применить доработанные протокольные модули Атлантиса. Которые формируют детальный протокол работы ядра Атлантиса и записывают его в формате SIL (Smart Inspect Log). В протоколе, с точностью до микросекунд, фиксируются: все события, все вызовы функций VIP, все сточки кода VIP, все обращения к базе данных, и т.д. Расшифровывая данный протокол, разработчики могут во всех деталях понять, что именно дела программа в заданный промежуток времени и почему так долго. Таким образом, можно поставить точный диагноз и выработать решение которое действительно поможет.

Сборка протокольных модулей в настоящий момент доступна для следующих версий Атлантиса 5.4.36.2, 5.4.37.0 и 5.4.38.3. Сами модули и инструкции по сбору данных можно скачать по следующей ссылке: ftp://ftp.galaktika.ru/pub/support/temp ... Protocols/

PS: Посмотреть содержимое протокола "*.sil" перед отправкой, можно с помощью программного обеспечения "SmartInspect Redistributable Console" http://www.gurock.com/smartinspect/resources.

[shurik--1]

кстати расчет сальдовых остатков пошел нормально после перезапуска sql-служб!