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

ЗУП 2.5
Платформа 8.3
==============
С какого-то времени, с месяц назад, сдельные наряды стали очень медленно проводиться. В среднем, в сдельном наряде около 20 тех.операций и около 20 исполнителей.
Начала копать, делаю замер производительности и вижу, что 97% времени уходит на такую глупость в процедуре "УдалитьДвижения()" в модуле документа. А именно, в строчке "Движения.ЕСНОсновныеНачисления.Записать();". Ага, думаю, регистр этот расчетный надо бы подробнее рассмотреть. Оказалось, что количество записей там почти миллион и увеличивается ежемесячно на 100 тысяч, а каждый сдельный наряд генерирует около 1500 записей.
Помогииите, пожалуйста, оптимизировать! Или неужели с нового года придется обрезать базу ?

Оптимизировать "наряды", не? Заместо "Дворник Петров: подметание в понедельник", "... подметание во вторник", и т.д. по всем дням недели (с указанием дождика, снега, прочих трудностей" просто "Подметание"?
Или даже (была-не была!) на оклад перевести, а?
У вас серьезно кто-то анализирует эти 100000 операций ежемесячно?

0-KyasLis > СУБД укажи для начала, там посмотрим.

(Извините за молчание, но только вчера зарегистрировалась, потому один день карантин.)

[b]VZ[/b]
на окладах они уже сидели, причем на 25 счете, никаких проблем не было, но начальство (а с ними и экономисты) захотело, чтобы для начала было хотя бы по изделиям, а в дальнейшем и по тех. операциям. А в каждом изделии этих самых ТО будет штук по 20. Что-то боюсь я, учитывая уже нынешние проблемы с производительностью (когда упрощенно считается 1 изделие = 1 ТО), что это все фантазии.

[u]Reaper[/u]
Сначала была файловая. Там один наряд проводился по 2 минуты. Перевели на MS SQL, теперь по 30 сек.

Делала замер производительности по процедурам - буквально, начало/окончание. Вышло что на удаление движений 50% времени, на собственно проведение тоже 50%. Странно все это! Ну ладно, я понимаю, что проведение, но удаление почему так долго ?
Пыталась подсмотреть в sql-профайлере, видно, что сначала делаются insert'ы в тайм-тейбл, затем эта временная таблица инсертом переносится в таблицу регистра. Вот этот insert и занимает самое большое время.

Ребятки, ну что делать ? Помогайте! Съедят ведь меня расчетчики :(

а нахрена на 2.5 платформа 8.3?

сделай в мс скл стандартные хрени, переиндексация, чистка процедурного кэша

обычно сильно помогает, но если есть rls то не сильно

[b]Дебилы[/b]
Проблема проявила себя еще когда была 8.2. А 8.3 была поставлена не мной, потому как на этом сервере есть и другие базы.
Все стандартные действия с скл админом уже проведены, именно после этого время с первоначальной минуты упало до 30 сек. Но все-равно это очень дооолго, расчетчицы очень недовольны.
Мне другое непонятно: делала статистику по базе, есть и другие таблицы, которые перевалили далеко за миллион, но проблем с ними нету. Ведь смешное же количество записей - миллион!
А что будет, если перейти на учет непосредственно технологических операций ? И что, все кто внедряли ЗУП или УПП на крупных производственных предприятиях с многопередельным производством, усаживали всех сдельщиков на оклад ? Ну смешно же.

7-KyasLis > Вообще-то платформы могут работать параллельно. Установка 8.3 вовсе не предписывает снос 8.2, и не запрещает запуск одной и той же конфы на разных релизах. Разумеется, если в конфигурации не задействован функционал различающийся/отсутствующий в какой-то платформе.
Еще крайне не рекомендуется задействовать разные релизы движка в многопользовательском режиме.
А так, ЗУП2.5 вполне можно оставить на движке 8.2.

[b]VZ[/b]
Пробовала переносить ЗУП на другой сервер с скл. Результат точно такой же, с поправкой на разницу в производительности серверов.

+8 И тем не менее вопрос "[em]У вас серьезно кто-то анализирует эти 100000 операций ежемесячно?[/em]" остается.
Если ответ отрицательный, то это означает, что выхлоп от заведения этих операций единственный: толстенькие пачки бумаги, которые "экономисты" предъявляют руководству как доказательство спиноломной работы, и неисчислимых бедствий, которые обрушатся на предприятие, если им дать под зад коленом.

(10) Давайте разобьем вопрос на две части:
1. Эти 100тыс. записей анализирует как минимум документ, который считает налоги с ФОТ. Я так думаю, что для того регистр расчета ЕСН по основным начислениям и существует.
2. Да, сделка нужна чтобы честно посчитать зарплату сдельщикам. Сделал 10 изделий - получи (расценка за изделие)x10. Это честно. Иначе, как на большинстве предприятий, как я видела: дали бригадиру сумму за месяц, бригадир поковырялся носом в пальце и разделил - этому столько, а этому столько. Потом сунули все это на счет 25 и аккуратно размазали ровным слоем по себестоимости выпущенных изделий. А дальше возникает ряд вопросов: а почему зарплата основных рабочих садите на 25, а не на 20 ? а сколько зарплаты в структуре себестоимости конкретных позиций изделий ? и т.д. по возрастающей.
В идеале, я понимаю, что надо бы расценивать технологические операции и отражать именно ТО.
Если так пошло, тогда почему вообще используют спецификации на выпуск продукции ? Можно ведь списать сырье котловым методом и опять же размазать результат по выпуску ? Фин.рез. ведь от того не изменится ? Конечно, не изменится.
Я к тому, что если у такой проблемы нет решения, тогда 1С и вправду исключительно для автоматизации ларьков :( Грустно :(((

11-KyasLis > Насколько я понял из ответа, анализом этих 100 тыщь записей никто не занимается. Понятно, чО :)
Но мысль о полезности анализа сравнительной себестоимости изделий сама по себе здравая. Но затратная.

3-KyasLis > Ну вот. Проведение ускорилось в 4 раза. Для дальнейшего расследования нужно больше информации. Хотя бы список 10 самых длительных операций в процессе проведения с их временем выполнения и процентом по отношению к длительности процесса проведения.

(13) Есть даже конкретная строчка: "Движения.ЕСНОсновныеНачисления.Записать();" в процедуре "УдалитьДвижения()".

14-KyasLis >Сохрани движения документа в Excell, закомментируй эту строчку, перепроведи документ и сравни движения с сохраненными ранее. За результат не ручаюсь, но шансы есть.

Ннну проверьте может перед записью или при записи чегог-нибудь делается?
Или это именно физически запись в регистр? В таком случае и остальные регистры тормозили бы, раз тормозит только этот - похоже что обработчик или подписка.
Исхожу из того, что ТиИ и dbcc отработано всё.

(15) Да, конечно, если закомментировать строчку, то результат есть, но это конечно же неправильно, это не решает проблему. Ведь этот документ не умеет сам удалять свои движения, поэтому и есть процедура, которая это делает.
(16) Подписки я посмотрела в первую очередь, их там штук 6, но все они безобидные и отнимают исчезающе малое время.
У самого регистра есть процедура набора записей "ПриЗаписи", но она опять же очень мало чего делает и делает это очень быстро. Тормозит именно физическая запись в регистр, я об этом в (3) уже писала и в профайлере уже подглядывала - insert в таблицу происходит долго. Кстати, в инсерте есть соединение с какой-то другой таблицей и по тем полям, по которым есть условия "ON ..." я сделала индекс отдельный. Не помогло :(

А ТиИ, dbcc и chdbfl (для файловой) конечно же делала - никаких проблем не обнаружено :(

[quote=KyasLis;37208232]но это конечно же неправильно[/quote]
Обоснуй? Я там пока не увидел потребности в очистке движений по проблемному регистру при перепроведении. При отмене проведения - да, зачем при перепроведении это делать - не понял.

(18) Попробую обосновать за разработчиков 1С. Наверное, нужно очищать движения регистра по документу, чтобы не получить удвоение записей регистра по документу. Нет ? Ведь если не очищать, тогда останутся старые движения плюс добавятся движения от проведения ? Потому как у самого документа в настройках стоит, что "Удаление движений" - "Не удалять автоматически". Это наверное для того, чтобы самим контролировать процесс удаления движений. С какой-то не очень нам, простым смертным, понятной логикой. Я думаю, что факт этот надо принять как данность. И я не уверена, что автоматическое удаление движений не будет делать такой же записи набора движений.

19-KyasLis > Для исключения дублирования достаточно очистки наборов записей (привет, документация!). Запись движений, выполняемая платформой для документов с настройкой "записывать модифицированные" выполняется с перезаписью движений. Автоматическое удаление не используется из-за ограничений некоторых версий MS SQL, которое не позволяет использовать более 256 таблиц в одном запросе. Ты уже сделаешь эксперимент, или тебе надо чтобы тебя уговаривали?

(20) О, вот это дело! Спасибо! Буду экспериментировать :)

Докладываю: у документа сделала автоматическое удаление движений, а процедуру удаления движений закомментировала. Время проведения документа увеличилось вдвое :(

22-KyasLis > А я что просил сделать?

Киас, сравни пожалуйста время трёх операций:
1. Отмена проведения.
2. Проведение непроведённого документа.
3. Перепроведение ранее проведённого документа.

[quote=KyasLis;37210385]Докладываю: у документа сделала автоматическое удаление движений, а процедуру удаления движений закомментировала. Время проведения документа увеличилось вдвое :( [/quote]
это мне напомнило анекдот:
[quote]- Далеко-о ли до Таллина-а?
- О, теперь оч-чень, оч-чень далеко-о...[/quote]

sweet little girl...
you're too young to realize...

(24) Я не сдаюсь!
На файловой версии:
1. 35 сек.
2. 36 сек.
3. 67 сек.
Но это лишь подтверждает ранее мною открытое, т.е. на удаление движений уходит почти такое же время, что и на проведение. И время это равно времени записи набора движений в регистр расчета "ЕСН основные начисления".

Я бы вот еще что хотела бы узнать: есть ли у кого-нибудь база с количеством записей в этой таблице больше миллиона ? Все ли в порядке с записью в этот регистр ? Со временем проведения документов ?

Или вот так: есть ли у кого-нибудь база, в которой есть начисление зарплаты сдельными нарядами и примерно с такими же объемами, т.е. каждый день по 5-10 подразделениям делаются наряды, в каждом из которых 20 тех.операций и 20 исполнителей ? Или это все фантастика ? Или на всех производственных предприятиях используют котловой метод начисления зарплаты повременкой на окладах c премиями ?

Киас, сделай пожалуйста замер производительности проведения непроведённого документа и расскажи, кто там у нас лидер.

(30)
1. Строка "Выборка = Запрос.Выполнить().Выбрать();" из функции "Функция ПолучитьГрафикСотрудникаНаДату(Сотрудник, ДатаПолученияГрафика)" - 47%.
2. Строка "Выборка = Запрос.Выполнить().Выбрать();" из процедуры "Процедура ЗарегистрироватьПерерасчетыПоФактическойВыработке()" - 35%.

При отмене проведения лидер тот самый, о котором я и говорила в начале: "Движения.ЕСНОсновныеНачисления.Записать();" в процедуре "Процедура УдалитьДвижения()" - 94%.

Кроме того, отмена движений отрабатывает еще и при проведении проведенного документа.

Рекомендации, что можно сделать простого, не углубляясь:

1. Разобраться, какого лешего так долго получаются графики, оптимизировать. В случае непреодолимых затруднений хотя бы кэшировать.
2. Если перерасчеты не применяются в реальной работе - можно попробовать нафиг убрать их регистрацию. Но придётся внимательно проверять, что ничего не упало. Ну либо оптимизировать запрос ясен пень :).
3. Убрать движения и удаление движений ЕСНОсновныеНачисления из сдельных нарядов. Регистратором оставить конечно. Написать обработку, которая добавляет эти движения во все сдельные наряды за месяц. При желании сделать регламентное задание.

Ещё можно попробовать странную вещь (вместо пункта 3): в регистре ЕСНОсновныеНачисления поставить свойство "индексировать" у измерений Сотрудник и ФизЛицо.

Эх, оптимизация SQL сервера помогла! Не я оптимизировала, а сисадмин. Теперь в 10 сек укладывается перепроведение документа. Всем большущее спасибо за участие!

... и вот так всю жизнь.
Пожалуйста! Обращайтесь! :)

[filolog]йопть[/filolog]

35-Дебилы > и не говори