Смотрю где можно ускорить УПП.

Заметил в модуле объекта переменную мУдалятьДвижения. Но у 1C сделано    мУдалятьДвижения = НЕ ЭтоНовый();.
Получается, что удаление движений запускается даже если документ не был не проведен.

Более правильно, чтобы было написано

мУдалятьДвижения = НЕ ЭтоНовый() или Проведен.

Это косяк у 1C или есть тайный смысл?
На запись пустого набора записи при удалении у меня уходит 54% времени

(0) не всё так просто. Флажок Проведен - это состояние документа в будущем. Документ не проведен на самом деле, а флажок Проведен уже стоит. Так что его проверять нет никакого смысла. Посмотрите в БП 2.0 как сделано, это более свежая конфа, чем УПП, там уже оптимизировано.

(0)
1. Включите версионник если SQL,
2. Перейдите хотя бы на 8.3.16.хххх,
3. Проанализируйте запросы и кое-где добавьте ВТ и Индексы или переделайте на РС.
4. Кое-где добавьте массивы, для кэша значений и оптимизируйте расчёты,
5. Исключите ненужные ветки алгоритмов и фоновые задания (ЕГАИС и ЭДО) и разную проверочную фигню.

Большего от УПП не требуйте, будет работать в три раза быстрее чем ЕРП и ладно.

(0)
1.версионник особо не поможет, если блокировки не переписать на управляемые

+3 к (2)

(0) В добавление к (2). Есть известные места в партионном учете(если, конечно, используется именно партионный учет), которые несколько ускоряют проведение по партиям. Насчет удаления движений - есть такое дело. Насчет тайного смысла - а часто вы именно распроводите документы полностью, а потом проводите заново? Я - нет. Движения при желании можно немного пофиксить - например, закэшировать метаданные, которые используются с тем или иным типом документов, и очищать только те регистры, которые используются. Т.к. стандартная очистка пробегает все возможные регистры, за небольшим исключением, навроде СвободныеОстатки и не помню еще каким. Можно сделать например так: http://catalog.mista.ru/1c/articles/330072/. Вообще, инфы по улучшайзингу УПП достаточно много. Например: http://catalog.mista.ru/1c/articles/252798/. Осталось только выяснить, что из этого применить с учетом современных реалий. Т.к. на факт, что на современной платформе УПП прямо-таки улетит в космос, напротив, может оказаться проще сидеть на 8.2.

исходные данные:
В базе стоит режим допроведения документов т.е движения по РАУЗ (и бух соответственно) создаются регламентным заданием ДопроведениеДокументов.
Движения по РН УчетЗатрат (упр.) отключены.
Флаг СтруктураШапкиДокумента.ОтражатьВБухгалтерскомУчете стоит в значение ложь из-за режима допроведения документов (см. ПодготовитьКПроведениюПоВидамУчета.ПодготовитьКПроведениюПоВидамУчета).

Делаю анализ производительности по Отчет производства за смену. 80% времени уходит на выполнение запроса в СформироватьТаблицуАналитики.

Движения по УчетЗатрат и УчетЗатратРегл не формируются т.к флаги ОтражатьВБухгалтерскомУчете и ОтражатьВУправленческомУчете имеют значение ложь.
Получается что в процедуре  УправлениеПроизводствомДвиженияПоРегистрам.ДвиженияПоРегистрамРаспределениеЗатрат  ни в одну процедуру не заходит ((м. СформироватьДвиженияПоРаспределениюМатериалов,СформироватьДвиженияПоРаспределениюПрочихЗатрат и т.д).
Т.е данные запроса, на который уходит 80% времени, ни на что не используются и ни на что не влияют.
Отключил выполнение запроса - движения в ОПЗС не изменились.
Движения по УчетЗатратРегл формируются нормально в механизме допроведения.

Стандартный вопрос - в чем подвох? Почему 1C не оптимизировала этот блок, ведь несколькоми строками кода можно повысить скорость на 80%

(6) дык, бросают же они конфы и пилят новые..ерп жешь на марше

Судя по всему ТС заняться нечем совершенно.

(8) заняться как раз есть чем. Просто проблема производительности припрекла.
А удивляет (и пугает), что то что лежит на поверхности и дает макс. результат не было сделано. Вот и ищу подвох

(9) Сколько пользователей и документов в базе? В какой момент ощущаете проблемы?

(10) около 200. Всегда тормозит когда все работают. Вес базы около 200 гб

Заметил, что происходят блокировки после перезакрытия месяца.
Это просходит из-за того, что слетают таблицы итогов?

(12) Что такое "слетают" таблицы итогов?

(13) что надо выполянять пересчет итогов у таблиц регистров т.к перепроводятся документы за несколько месяцев

(14) и ? для этого итоги не надо пересчитывать

(14) надо после закрытия месяца выполнять регламентные операции на сервере (пересчет итогов, реиндексация)

У меня была партионка в УПП, а не РАУЗ. Сделал пункты из (2):
3. Проанализируйте запросы и кое-где добавьте ВТ и Индексы или переделайте на РС.
4. Кое-где добавьте массивы, для кэша значений и оптимизируйте расчёты
ускорил проведение на порядки. Это было 6-7 лет назад. Сам был в шоке. Когда 95% времени проведения тратилось на запрос, в котором были соединения с Выбрать и внутри этого Выбрать снова соединение с Выбрать. Т.е. то, за что сразу с экзамена на сертификат Спеца выгоняют.