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

Polimer · Сообщение **Polimer** » 09 окт 2009, 13:21

Последние полгода отмечаем заметное снижение быстродействия в г. в некоторых режимах. Пытаемся разобраться вместе с ТП, пока не получается.
1. Версия 8.1 текущая, MS SQL 2000, смешанная авторизация
2. Объем базы 70 гб.
3. Используется КОУ, КБУ, УПЛ, зарплата, кадры
4. Одновременно работающих пользователей - до 40, терминал/локал - 60/40.
Проблемы:
1. Некоторые отчеты в з/п стали формироваться в 50-100 раз медленнее, в частности ведомость распределения начисленной з/п работает почти 2 суток.
2. Время списания накладной на приход ГП в УПЛ составляет 4-5 минут(хотя, может это было всегда)
3. Заполнение инвентаризации одной позиции ~ 10-15 сек. (300 позиций)
Делали все возможные проверки. Остались три версии (у нас):
1. Текущая версия г.
2. Сочетание SQL, размера базы, возможностей железа.
3. Кривизна базы.
Просьба откликнуться у кого схожие параметры. Есть или нет проблемы с быстродействием.

edward_K · Сообщение **edward_K** » 09 окт 2009, 14:18

да уж - долговато. ТП надо бы напрячь насчет отладочного реса для тестирования быстродействия. Данных для сравнения тоже маловато - lдля ОВР скажем нужно кол-во записей в nachisl , perevodtek после расчета зарплаты. К тому же там куча галочек - можно выяснить какая именно тормозит. Скажем сводить налоги на фот с бухсправками точно затормозит. Остальное тоже нужно разбиратся в каждом конкретном случае. Опять же без точной информации как было на такой то момент и чего ж потом менялось в железе тоже не скажут. А может банально chkmssql прогоните с перестройкой индексов и все будет нормально.
Если есть возможность попробуйте кроссплатформенным конвертором перегнать все на другой сервер(ну может что то там подправить придется - чтоб журнал не тащить) - дело может быть и в железе.

Polimer · Сообщение **Polimer** » 09 окт 2009, 14:29

edward_K писал(а):да уж - долговато. ТП надо бы напрячь насчет отладочного реса для тестирования быстродействия. Данных для сравнения тоже маловато - lдля ОВР скажем нужно кол-во записей в nachisl , perevodtek после расчета зарплаты. К тому же там куча галочек - можно выяснить какая именно тормозит. Скажем сводить налоги на фот с бухсправками точно затормозит. Остальное тоже нужно разбиратся в каждом конкретном случае. Опять же без точной информации как было на такой то момент и чего ж потом менялось в железе тоже не скажут. А может банально chkmssql прогоните с перестройкой индексов и все будет нормально.
Если есть возможность попробуйте кроссплатформенным конвертором перегнать все на другой сервер(ну может что то там подправить придется - чтоб журнал не тащить) - дело может быть и в железе.

Спасибо за ответ. По пунктам:
1. Результаты отладочного реса уже отдал. (ИМХО, там ничего не видно)
2. Результат работы профайлера отдавал - ничего не нашли.
3. Железо не менялось. Тесты провожу на двух разных серверах.
4. Чекскл был 1 пунктом в проверках
5. Индексы на скуле проверял.

edward_K · Сообщение **edward_K** » 09 окт 2009, 15:13

Ну начните с с галочек в ОВР, наверное для вашего объема где то час за один месяц. Налоги на фот должны раз в 5 дольше собираться чем начисления (без упомянутой галки).

Polimer · Сообщение **Polimer** » 09 окт 2009, 15:45

Может быть мы про разные ведомости говорим.
"Отчеты", "Отчеты в разрезе бухгалтерских проводок", "Контрольный журнал по оплате труда", "Ведомость распределения начисленной з/п". Там настраивать нечего.
ЗЫ. ОВР формируется ~5 мин.

Masygreen · Сообщение **Masygreen** » 09 окт 2009, 16:01

сам не люблю такие ответы - но по sql много гвоорлось .. го на sql.ru да и здесь
в общих чертах примерно так ..
райд для данных
райд логов
райд tempdb
райд на систему
райд системный файл подкачки
райд на SQL
переход на sql2005
chek
трехзвенка с гиговым каналом между бд и сервером приложений ..

У Вас это реализовано???

Polimer · Сообщение **Polimer** » 09 окт 2009, 16:18

Masygreen писал(а):сам не люблю такие ответы - но по sql много гвоорлось .. го на sql.ru да и здесь
в общих чертах примерно так ..
райд для данных
райд логов
райд tempdb
райд на систему
райд системный файл подкачки
райд на SQL
переход на sql2005
chek
трехзвенка с гиговым каналом между бд и сервером приложений ..

У Вас это реализовано???

Это новые системные требования к г. 8.10

ЗЫ. Может кто-нибудь ( у кого скл и база > 50 гб) запустить этот отчет? Начинает сильно тормозить на подразделениях более 200 чел.

Masygreen · Сообщение **Masygreen** » 09 окт 2009, 16:45

это не требования галактики - это требования субд .. SQL так будет веселее работать на ваших объёмах .. (вы кстати просили тех. совет)

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

сформировал. база 40 Гб .. по нескольким подразделениям .. несколько сотен сотрудников .. ну пара тройка минут .. (правда это тестовая и на ней один пользователь йа)
визуально чуть дольше чем ОВР[/img]

Polimer · Сообщение **Polimer** » 09 окт 2009, 17:02

Masygreen писал(а): "Отчеты", "Отчеты в разрезе бухгалтерских проводок", "Контрольный журнал по оплате труда", "Ведомость распределения начисленной з/п"

сформировал. база 40 Гб .. по нескольким подразделениям .. несколько сотен сотрудников .. ну пара тройка минут .. (правда это тестовая и на ней один пользователь йа)
визуально чуть дольше чем ОВР

Спасибо. А можете посмотреть кол. записей в NACHISL и PEREVODTEK ?

thor · Сообщение **thor** » 09 окт 2009, 17:42

А че за железка на SQL стоит...
Скока оперативки, как ее инстанс использует, динамически или статически?
Индексы на уровне SQL не пробовали перестраивать с Fillfactor, отличным от того, что по умолчанию в Галке используется...?

Masygreen · Сообщение **Masygreen** » 09 окт 2009, 18:09

NACHISL и PEREVODTEK около 3000...
а размер базы здесь .. хз .. разные модули приводят к разному размеру ...

Polimer · Сообщение **Polimer** » 09 окт 2009, 18:41

Masygreen писал(а):NACHISL и PEREVODTEK около 3000...
а размер базы здесь .. хз .. разные модули приводят к разному размеру ...

Ну и где ваши "несколько сотен сотрудников" ?
При наших 620 сотрудниках: Nachisl - 23000, Perevodtek - 145000.

Masygreen · Сообщение **Masygreen** » 09 окт 2009, 18:52

Nachisl,PEREVODTEK - таблица текущих начислений - которая чистится каждый месяц, тут наверно не запускались еще расчеты..эээ... йа не бухгалтер запускать не могу

Polimer · Сообщение **Polimer** » 09 окт 2009, 18:53

thor писал(а):А че за железка на SQL стоит...
Скока оперативки, как ее инстанс использует, динамически или статически?
Индексы на уровне SQL не пробовали перестраивать с Fillfactor, отличным от того, что по умолчанию в Галке используется...?

Память - 4 гб на рабочей базе, 2 гб на тестовой, используется динамически, на обоих аппаратные рейды. Пока не хотел бы углубляться в тонкости настроек скл и железа. Если отчет работал до июля 30 мин., а сейчас 30-40 часов, то, я думаю, дело не в этом.

LaaLaa · Сообщение **LaaLaa** » 17 окт 2009, 09:47

Коллеги извините, что встреваю в разговор. Но чтобы сократить время работы отчета нужно для начала разобраться, на что это время тратиться.

Гадать в слепую - это задача экстрасенсов - не наш метод.

Чтобы решить проблему всего лишь нужно измерить это время, и разложить его на составляющие.

В данном случае технологический стек в упрощенном виде выглядит так:

1) прикладной код Галактики, функции расчета и построения отчета
2) системный код Атлантиса, исполнение VIP функции генератора отчетов
3) функционал СУБД - в данном случае MS SQL
4) Операционная система и железо

Какие в данном случае могут пригодиться средства для измерения?

1) Профилировщик VIP кода (встроенная в отладчик VIP функция).
2) Профилировщики бинарного кода С++ и Pascal (например AQTime)
3) Профилировщик MS SQL, журналы трассировки
4) Мониторы производительности ОС

Получить профилировку MS SQL и грамотно ее проанализировать вы с можете и сами. По результатам анализа вы сможете понять где проблема в софте (1 и 2) или в платформе (3 и 4). Если в платформе то понятно - пригодятся выше описанные методы махинации с желеом.

Если в софте - то нужно нужно просто сделать прфилировку VIP и бинарного кода. Отладочные резы, это конечно хорошо. Но извините меня это детский лепет. Разработать грамотный отладочный рез с правильной детализацией это не халява. Одной итерацией здесь не обойдешься. Просто вы и разработчик потеряете кучу времени на переписку через ОТП и изобретение велосипедов .

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

Без программистов написавших код вы ничего не сможете сделать. А программисты без доступа к вашей БД тоже ничего не смогут сделать.

Чтобы решить проблему. Нужно всего лишь вашу тестовую БД передать в отдел разработки на исследование. Либо программисту приехать к вам с исходными кодами и отладочной информацией.

Базу передать по моему проще

PS: По методам оптимизации еще читайте книгу, рекомендованные в ней методы годятся на самом деле к любой платформе
http://www.tyumbit.ru/gal_forum/viewtop ... 3979#43979