Галактика в вопросах и ответах

Быстродействие победили настройками MS SQL! Убрали принудительное распараллеливание по двум процессорам, так же что-то с "нитями" перенастроили.

Чтобы Галактика работала нормально (интерфейсы) - наш админ сделал кеширований таблиц в память: Prices, KatMc, GroupMc, KatOrg, SaldoMc, SklOst. Интерфейсы стали работать более-менее нормально, пользователи больше не звонят...


Теперь беда с формированием отчетов.
Формируем отчеты за месяц - все формируются оооочень долго - 1-2- часа.
Причем один и тот же отчет формируется одинаково - где бы его не запускали (на локальной машине или на сервере) - например, "реестр накладных на внутр перем со склада" формируется до 52% - с нормальной (приемлемой) скоростью (9 минут на сервере), затем зависает и висит (на сервере 25 минут висит, на лок машине говорят 15 минут висит), потом опять процесс пошел, но уже гораздо медленней, в результате отчет формируется больше часа.

В чем может быть проблема? Я так думаю - памяти оперативной не хватает???
Подскажите - где копать?

hope писал(а):Чтобы Галактика работала нормально (интерфейсы) - наш админ сделал кеширований таблиц в память: Prices, KatMc, GroupMc, KatOrg, SaldoMc, SklOst. Интерфейсы стали работать более-менее нормально, пользователи больше не звонят...

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

hope писал(а): Теперь беда с формированием отчетов.
Формируем отчеты за месяц - все формируются оооочень долго - 1-2- часа.
Причем один и тот же отчет формируется одинаково - где бы его не запускали (на локальной машине или на сервере) - например, "реестр накладных на внутр перем со склада" формируется до 52% - с нормальной (приемлемой) скоростью (9 минут на сервере), затем зависает и висит (на сервере 25 минут висит, на лок машине говорят 15 минут висит), потом опять процесс пошел, но уже гораздо медленней, в результате отчет формируется больше часа.

В чем может быть проблема? Я так думаю - памяти оперативной не хватает???
Подскажите - где копать?

Если проблема в нехватке оперативной памяти (можно определить по постоянно работающему винту через некоторое время), то можно сделать вот такие настройки:

[Database]
ExternalInMem=Off
TempTableInMem=Off
UserTableInMem=Off

Маленькие отчеты станут работать помедленнее, но зато большие не будут так тормозить.

Из кеша убрали все таблицы. Пока пользователей не было в Галактике - отчет формировался 16 минут. Как только народ зашел в Галактику - опять 1.5 часа.

Попробовала настройки поставить как у вас указано - на себя настроила - результат тот же, на 52% опять висит и уже полчаса прошло....

А это же отчет в сбыте формируется 15 минут и еще только 2 % - ужас...

1. Счетчики восстановили?
2. Все отчеты так себя ведут или только единичные?
3. Как точно называется отчет, который вы запускаете и какие вы задаете параметры запуска?

to hore: а просто выполнить Analyzing запросов SQL средствами не пробовали?

Примерно такая же фигня была. Клиенту поставили 712 на MSSQL2k, OS WIN2000ServSP4. Потом прибегает тамошний админ -- грит пошли вы нафиг со своей двухтысячкой, она скоро поддерживаться не будет,а ему потом что делать? Ну хозяин-барин. Переставили то же самое, но под 2003sp1 сервером. Сразу же пошли тормоза, субъективно стало все медленнее работать раза в два точно. Еще к тому же постоянно без причины NapServer отваливаться начал, короче мрак. Вернулись обратно к старой доброй 2k -- все залетало как и прежде.

База 20GB. Сервер Dual Xeon 3ГГц, 4Gb RAM, SCSI RAID5 (5 винтов). 50 пользователей под Citrixом. И еще десятка как толстые клиенты.

1. Счетчики не восстановили.
2.3. Пока выявлена такая глобальная проблема с отчетом "Реестры накладных" - причем в любом модуле (Сбыт, Снабжение, Склад - везде формируется очень долго, в Сбыте так вообще вчера с обеда оставили на ночь формироваться - думаем к утру будет готов). Отчеты формируем за 1 месяц - январь.
Причем провела эксперимент: в Сбыте сформировала отчет по реализации за месяц - скорость нормальная - меньше 5-ти минут. С этими же параметрами запустила отчет "Реестр накладных на продажу" - за 15 минут 2%. По сути эти два отчета должны перебирать одни и теже таблицы - почему такая разница в скорости?

После переноса Галактики на новый сервер не сделали regsvr32 atlextdb.dll (что необходимо было сделать после установки патча).
Дело в том, что на новый сервер просто скопировали exe-каталог со старого сервера на новый. Это нормально?
Сегодня сделали regsvr32 atlextdb.dll, но на скорости это никак не отразилось.

Делала полную проверку КОУ.

Analyzing запросов SQL средствами - не пробовали - ни разу не делали.

Еще раз предлагаю проверить.
Случайно NAP сервер не работает под named pipes?

Проблема с быстродействием возникла после переноса Галактики на новый сервер. Перенесли, как я поняла, простым копированием EXE и простым копированием базы (не сохраняли и восстанавливали, а просто скопировали).

Чтобы в интерфейсах Галактики заработало более-менее терпимо - убрали принудительное распараллеливание по двум процессорам, и что-то поменяли в настройках "нитей-поднитей" (я не админ - прошу строго не судить).

Выявилась проблема с формированием отчета "Реестр накладных" - по нему бухгалтера сводять данные и делают отчеты за месяц. (в лучшем случае 1.5-2 часа, в худшем 4-7 часов - зависит от параметров отчета, но все отчеты формируются за месяц, только по разным складам, по разным дескрипторам).

Вообще в чем может быть проблема?

1. В данных в таблицах Галактики (База MS SQL). - что может быть с данными - что отчеты так медленно формируются? Могут слететь индексы, может быть зацикливание, что еще ? Какие есть варианты это проверить? как это можно вылечить?

2. В настройках MS SQL - что может быть? какие настройки посмотреть? и как они д.б. настроены?

3. В самом сервере. Что может быть с сервером?

4. В сети. - я считаю, что сеть тут ни при чем - так как скорость формирования отчета на лок компьютере и на клиенте терминалов - одинаковая.

5. проблема с правами пользователей - это вообще больная тема для Галактики на платформе MS SQL - пользователям даем полные права на базу - тогда работает.

Люди! подкиньте какие-нибудь идеи!

Снести все: Галу, SQL, ОС, и переставить заново, по-человечески, через инсталляторы, базу поднять через восстановление.
Потому что: "хотели как лучше, а получилось как всегда"

Anton Bobrov! - это уже показатель!!! (наши пользователи тоже хотят на старый сервер!!! - так и говрят).
А есть у кого-нибудь положительный опыт эксплуатации Галактики на 2003 сервере?

Sim! - я бы тоже так сделала! Только вот теперь я сомневаюсь - может база уже корявая - и восстанавливать нормально уже и не поможет???

И еще, как нужно ставить Галактику на новый сервер:
1) устнавливаем Галактику с пустой базой, накатываем патчи, которые стояли на старом сервере, затем восстанавливаем рабочую базу.
2) Или таким образом: устнавливаем Галактику, затем восстанавливаем рабочую базу, накатываем патчи, которые уже стояли на старом сервере.
3) Или все-таки достаточно будет переписать EXE каталог? и восстановить базу.

Polimer! Нет, NAP сервер не работает под named pipes. Говорят - тут все нормально.

И еще - мы не переустанавливали клиентов Галактики, просто поменяли путь на базу. Не осталось ли где-нибудь что-нибудь - что ходит по какому-то пути неправильному???? Надо будет попробовать установить локально Галактику с нового сервера!

Всем большое спасибо!!! Предложения еще принимаются!

Здравствуйте все!

Это тот самый админ, который админит тот самый сервер с тормозной Галкой.

Сейчас полетят в меня помидоры...

Сносить ВСЕ и ставить заново - это не выход из положения - потому ка ВСЕ кроме Галки нормально и как следует фунциклирует. Драйвера-свежайшие, биос-такой же, все установлено. Вероятно, проблема заключается в какой-нибудь хитрой настройке винды или SQL-сервера.

Переносил Галактику по инструкции переноса на другой сервер. Т.е., сначала установил пустую базу вместе с Галкой из дистрибутива(инсталятором!), затем скопировал поверх старую (это вместо восстановления бэкапа-что то же самое), следом - exe каталог. Восстановил логины в SQL при помощи импорта-экспорта t$users. Единственное, не была выполнена очистка хранимых процедур и t$hashvalues. По моему, это непринципиально.

Теперь про RAID5. Скорость чтения с RAID около 35Мб/сек, запись 20-25 (Аппаратный контроллер, 128Мб кэш, Ultra 320). Диски не нагружены. Поэтому, вопросы связанные с быстродействием дисков не рассматриваю.

Восстановлены счетчики производительности для SQL сервера. Буду их исследовать. Принимаю конкретные предложения - куда смотреть.

По диспетчеру задач, SQL Server кушает где-то от 20 до 40% CPU, используется режим /3GB, память, выделенная под SQL=3Гб.

Napsrv общается по tcp/ip, клиенты - тоже по tcp/ip. В сети кроме tcp/ip других протоколов нет.

Anton Bobrov писал(а): Еще к тому же постоянно без причины NapServer отваливаться начал, короче мрак.

А вот у нас - ничего не отваливается. и причина тут могла быть скорее всего в кривых сетевых драйверах или в сетевом оборудовании.

К тому же, в Галкинской техподдержке сказали, что проблем с 2003м быть не должно.

Я почему про named pipes говорю - очень похожие тормоза на Г. у нас были с некоторыми отчетами в 7.12, причем большинство отчетов работало нормально.
Narconf показывал, что для подключения используется TCP/IP, а Enterprise Manager->Management->Process info у usera NT AUTHORITY SYSTEM\SYSTEM на нашей базе показывал Nimed Pipes в Network Library.