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

Всем привет!
Может кто подскажет как ускорить данный процесс. От каких параметров он может сильно зависеть (количество МЦ в картотеке, кол-во спецификаций ордеров, период...). Какие из вышеперечисленных сильно тормозят процесс или так криво написана эта функция и легче написать свою. У нас данный расчет выполняется 4 часа, при этом остальные пользователи практически не могут работать (Сервак 4-х процессорный Xeon 700 и 4Гб ОЗУ). Процессоры загружены лишь на 20%, но у пользователей тормоза ЖУТКИЕ. В чем засада?
Версия Галки 5.84

Тормоза в дисковой подсистеме. Посмотри журнал изменений.

>Тормоза в дисковой подсистеме.
Вроде стоят совсем не старые SCSI-винты и конроллер не старье. Серверу всего 1,5 года.

А как это проверить?

>Посмотри журнал изменений.
Галактический или какой?

И еще в базе 700 карточек МЦ по которым нет движений, если их грохнуть хочь чуточку быстрее будет?

Пересчет средних цен процесс, который следует запускить вечером. После работы. И данные будут корректнее и мешать никому не будет.

>Пересчет средних цен процесс, который >следует запускить вечером. После работы.
Мы так и делали, но возникают ситуации когда ждать до вечера - пустая трата времени, а сроки бух.отчетности горят. К тому же пусть процесс хоть 10 часов работал бы, но при этом не так сильно тормозил другие процессы. Например, в тоже время разносили банковскую выписку и запустили распределение платежа по товарным позициям, дык это распределение работало 3,5 часа (пока не расчитались средние цены). Самое обидное, что главбуха я предупреждал, что процесс этот тяжелый и долгий, она все стояла на своем, а теперь жалуется руководству, что Галка работает медленно.

Главбух прав - процесс этот в Г. действительно очень медленно работает. Тому есть несколько причин, как мне кажется :
- в 5.8 по сравнению с 5.7 изменлся принцип работы с сальдовыми остатками. САми, знаете, что теперь в БД хранятся записи по остаткам на любой день проведения операции прихода/расхода. Раньше же хранились тока на определенную дату, рассчитанную пользователем. Т.о., думается, при пересчете цен, происходит постоянный update saldomc...
- функция универсальна для всех методов учета по складу.
- написана она была давно и как сказал один из разработчиков :... Над этим алгоритмом работали несколько лет - там столько наворотов по оптимизации, что пальцы устанут по клавишам стучать...
- сам Атланитис такой. Все модификаторы отрабатывают на клиенте..Вот он и загружен по полной программе. Остается ждать 8-ки с его новой архитектурой.

на серваке не пробовал запускать?
сервак то мощный - разгрузишь сеть капитально.
кроме того отключи из журнализации sporder,saldomc,saldofnd - это тоже притормажывает(вообще практика такая - если пользователи жалуются на тормоза, то заходишь в журнал и вычисляешь какая машина и с какой таблой усиленно производит работу - может там проблемы с сетью или просто комп не соотв. объему перелопачиваемой информации, а может нужно и таблу вырубить из журнализации). а вообще конечно такие вещи нужно делать по ночам. а днем если и делать, то только с фильтром по матцености, или по крайней мере запрещать делать оприходывание.

Да не мучайтесь с определением в чем проблема таких тормозов - она одна и совершенно не зависит от железа. Это в галке так все написано...Мучались, мучались с этим делом, да написали свой пересчет, естественно получив информацию и заручившись поддержкой бухгалтеров. Пересчет за месяц занимает, если не соврать минут 40 по готовой продукции - примерно 4000 позиций(правда на серваке). И никому не мешает, и запускают бухгалтера в удобное для них время.
Уверяю что написать лучше самим, потратите неделю зато все будет летать

Почуму по ночам ... еслу бухгалтер сделал свою работу в 9.00 почему он должен ждать когда все закончат свою работу. Журнализации по этим таблицам не веду. На сервере запускал - результат 3.20, а на локальной машине (3.40). На мой взгляд проблема в том, что этот процесс мало кто использует и соответственно он "грубо" реализован.

Ну ты не прав...почти все используют. Так как всгеда есть ситуации, когда приходы забивуают задним числом.

При включении партионного учета, никого пересчета средних цен не надо!

Когда у юзеров начинаются жалобы на медленную работу того или иного процесса, мы обычно анализируем запросы, индексы, которые этот запрос юзает и добавляем свой индекс (Oracle), в результате процесс который занимал 6-8 часов, начинает отрабатывать за 1-2 минуты. А вообще в Галактике при использовании КОУ, КБУ, и Зарплаты, процентов 60 индексов таблиц БД не используется вообще. Если их грохнуть то update будет идти быстрее.

P.S. Microsoft Excel рулит !

А зачем ты часто пересчитываеши цены во всей картотеке, приучи бухгалтеров, что если делают изменения заднив числом, то пусть сразу в этой карточке складского учета пересчитывают цены (локальное меню), этот вопрос есть разобран в базе "Вопросы и ответы" учебного центра.