Пересчет цен в расходных ордерах

[Саша Г.]

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

[Forsit_]

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

[Саша Г.]

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

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

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

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

[m0p3e]

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

[Саша Г.]

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

[Den]

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

[edward_K]

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

[ALEKS123]

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

[Саша Г.]

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

[Den]

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

[B_A]

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

[Multik]

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

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

[Изабель]

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