Ускорение расчета себестоимости УПП 1.3 в несколько раз

02.02.21

Задачи пользователя - Закрытие периода

Как определить причину медленного расчёта себестоимости в УПП 1.3, один из вариантов поиска проблем производительности с помощью инструментов 1С и ускорения расчёта средствами встроенного языка

Всем доброго времени суток! 

На днях столкнулся с задачей: долго рассчитывается себестоимость по организации за декабрь 2020 года (~40 минут), при этом в ноябре и всех прошлых месяцах она рассчитывалась ~10 минут.

Что имеем: платформа 8.3.16.1359, УПП 1.3 (1.3.152.3), PostgreSQL (тестировалось и на MS SQL), производственная организация, партионный учет, многопередельное производство. 

Если вы столкнулись с такой же или похожей проблемой, то эта статья может натолкнуть на решение и сэкономить вам время.

Первым делом, следует выполнить пересчет итогов регистров - правда в контексте этой задачи, у меня ничего не изменилось.

Далее заходим в конфигуратор, запускаем режим отладки (F5) - запускается режим предприятия - находим нужный документ расчета себестоимости - возвращаемся в конфигуратор - активируем режим замера производительности:

возвращаемся в предприятие - запускаем проведение расчета себестоимости - ждем окончания.

После того, как расчет себестоимости завершен, возвращаемся в конфигуратор и останавливаем замер производительности:

на экране появится результат замера, подробно расшифровывать не будем, кому интересно можно почитать подробнее об этом инструменте https://its.1c.ru/db/metod8dev/content/1553/hdoc .

Итак, мой результат:

В глаза сразу бросается первая строка, мы видим, что данная строка кода выполняется 32 раза, 2 268,979787 секунд (~38 минут) и занимает 85,61% всего времени выполнения проведения расчета себестоимости.

Познакомимся ближе с этой строкой, дважды щелкаем на строку в замере производительности, попадем в модуль - в место выполнения этого кода, эта строка находится в общем модуле ПроцедурыРасчетаСебестоимостиВыпуска.

Ставим точку останова на данной строке кода:

Снова возвращаемся в предприятие и еще раз проводим расчет себестоимости, пока выполнение кода не остановится на нашей точке:

Выделяем ЗапросПоЗатратамНаВыпуск нажимаем Shift + F9:

теперь, у нас есть текст выполняемого запроса и его параметры, чтобы было удобно работать с этим запросом, нам необходимо, вернуться в пользовательский режим, запустить любую консоль запросов, скопировать туда текст запроса и заполнить параметры.

Кстати параметров очень много, да еще и массивы, очень удобно использовать подсистему инструменты разработчика, чем я и воспользуюсь, подробнее здесь //infostart.ru/public/15126/ .

У меня уже встроена эта подсистема и чтобы получить запрос из отладки со всеми параметрами в пользовательском режиме, мне достаточно нажать SHIFT + F9 и написать Отладить() , указав в качестве параметра свой запрос, далее нажать вычислить:

В режиме предприятия открывается консоль запросов, уже с заполненным текстом и параметрами, остается только выполнить:

Запрос возвращает 285 строк, за 195 секунд. Я решил проанализировать прошлые месяцы, меняя параметры периода в запросе и увидел, что действительно в прошлых месяцах количество строк было примерно в 3.5 раза меньше, (вспоминаем постановку задачи, выполнялось за 10 минут, стало за 40) действительно, пропорционально увеличению записей в регистре, увеличилось и время расчета себестоимости, к слову, записи увеличились обоснованно, из-за включения серий. 

Собственно, с причиной разобрались, но неужели так и придется жить, ведь сейчас на предприятии даже не сезон, дальше будет еще дольше выполняться расчет, а один раз себестоимость редко проводится, далеко не всегда всё закрывается идеально с первого раза, сколько времени придется убить на закрытие месяца.

Это не устраивает. 

Возвращаемся к нашему запросу и анализируем его:

в качестве основной используется таблица регистра накопления, к ней соединяются 4 вложенных запроса.

Вспоминаем методику:

Фирма 1С не рекомендует использовать вложенные запросы без особой потребности и предлагает заменять их временными таблицами или соединениями таблиц, замечая при этом, что результат такого изменения может быть другим. Такая рекомендация объясняется тем, что при использовании вложенных запросов оптимизатор СУБД не всегда может правильно определить размер выборки вложенного запроса и построить оптимальный план обращений к физическим таблицам базы данных, что сильно (иногда в десятки раз) может замедлить выполнение запроса.

А здесь, еще подробнее https://its.1c.ru/db/v8std/content/655/hdoc@51ff9ba0 .

Прислушаемся к совету, модернизируем запрос, заменив все вложенные запросы на временные таблицы, проиндексировав их по полях соединений(ниже будет итоговый текст запроса):

выполняем запрос в консоли:

 

видим, что скорость выполнения увеличилась со 195 секунд до 0.5 секунд!!! то, что надо, теперь внедрим его в конфигурацию и попробуем выполнить расчет себестоимости с замером производительности, для этого в общем модуле ПроцедурыРасчетаСебестоимостиВыпуска, находим функцию СформироватьТекстЗапросаПоЗатратамНаВыпуск(), и заменяем ее, на наш запрос с временными индексированными таблицами, типовой запрос опциональный - с использованием в тексте комментариев, которые потом в зависимости от параметров учета, заменяются на строки кода, наш запрос ничем не хуже и также будет опционален.

 
Итоговый листинг функции

проводим расчет себестоимости, смотрим результаты замера:

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

так же выполняется 32 раза, но теперь за 26 секунд вместо 2 268,979787! и занимает всего 6.43% от общего расчета себестоимости, вместо 85,61%

Время выполнения этой строки увеличилось в 87 раз!

В заключении, еще хочется обратить ваше внимание на эти статьи по ускорению расчета себестоимости, возможно в вашем случае они будут более подходящими:

//infostart.ru/1c/articles/255469/

//infostart.ru/public/176644/

надеюсь, статья оказалась полезной, всем спасибо!

УПП 1.3 закрытие месяца расчет себестоимости ускорение оптимизация

См. также

Анализ расхождений выручки НДС и Налога на прибыль в декларациях (БП 3.0 ПРОФ и КОРП, КА 2, ЕRP)

Анализ учета Закрытие периода Платформа 1С v8.3 Бухгалтерский учет 1С:ERP Управление предприятием 2 1С:Бухгалтерия 3.0 1С:Комплексная автоматизация 2.х Россия Бухгалтерский учет Налоговый учет Налог на прибыль НДС Платные (руб)

Каждый бухгалтер не раз сталкивался с требованием от налоговой инспекции пояснить расхождения в показателях декларации по Налогу на прибыль («Доходы от реализации» + «Внереализационные доходы») и налоговой базой по НДС за год. Являются ли ошибкой подобные расхождения? Как пояснить налоговой их причину? Отчет «Анализ расхождений выручки НДС и Налога на прибыль в декларациях» поможет найти все расхождения.

7200 руб.

21.10.2017    83888    258    167    

254

Ускоренное проведение документов (x4), устранение ошибок 60/62 счетов и зачет авансов (Бухгалтерия 3.0)

Закрытие периода Инструменты администратора БД Корректировка данных Бухгалтерский учет 1С:Бухгалтерия 3.0 Россия Бухгалтерский учет Платные (руб)

Расширение «Оперативное проведение» в 4 раза уменьшает время проведения документов и закрытия месяца. Является комплексным решением проблем 62 и 60 счетов. Оптимизирует проведение при включенной функциональной опции «Раздельный учет НДС». Используется в более 10 организациях уже 2 года. Совместимо с конфигурацией Бухгалтерия 3.0 (+КОРП).

14400 руб.

29.04.2020    27809    82    146    

60

Помощник закрытия месяца

Закрытие периода Платформа 1С v8.3 1С:ERP Управление предприятием 2 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х Управленческий учет Платные (руб)

В современных конфигурациях УТ 11, КА 2, ERP 2 и их аналогах присутствует механизм закрытия периода. Но при ошибках учета закрыть период корректно становится практически невозможно! Давайте попробуем разобраться, как можно устранить ошибки и закрыть корректно месяц!

9000 руб.

20.03.2018    70210    266    58    

292

Обработка "Списание доходов будущих периодов" и расширение

Учет доходов и расходов Закрытие периода Платформа 1С v8.3 Бухгалтерский учет 1С:Бухгалтерия 3.0 Россия Бухгалтерский учет Платные (руб)

Решение регламентирует учет доходов будущих периодов(ДБП) в организации: сохраняет подробную информацию о объекте ДБП. По окончании месяца на основе введенной информации формируются проводки списания ДБП, отчеты для бухгалтерского и налогового учета. Подходит как для различных версий Бухгалтерии 8.3, так и для ERP и КА.

5500 руб.

09.10.2020    18809    41    18    

37

Автоматическое закрытие месяца в УНФ

Закрытие периода Платформа 1С v8.3 1С:Управление нашей фирмой 1.6 1С:Управление нашей фирмой 3.0 Россия Управленческий учет Платные (руб)

Закрытие месяца в Управлении нашей фирмой — это очень важная задача, которую надо выполнять регулярно. Как обычно, все важное и регулярное делать мы почему-то забываем =)

3600 руб.

30.09.2022    7303    13    0    

12

Исправление ошибки закрытия месяца "Обнаружены ненулевые остатки по суммам при нулевом остатке по количеству в регистре себестоимости по организации". УТ 11.4,УТ 11.5, КА 2.4,КА 2.5, ERP 2.4, ERP 2.5, КА 2 Казахстан, Управление торговлей 3 для Казахстана

Закрытие периода Корректировка данных Платформа 1С v8.3 Оперативный учет 1С:Управление торговлей 11 Управленческий учет Платные (руб)

Закрытие месяца - важный процесс в современных конфигурациях, таких как УТ 11.4, УТ 11.5, КА 2.4, КА 2.5 ERP 2.4,ERP 2.5, КА 2 Казахстан, УТ 3 Казахстан регламентные операции влияют на расчет себестоимости, и ошибки в данном расчете не дают картины деятельности организации.

2400 руб.

27.10.2021    22522    301    35    

73

Помощник исправления развернутого сальдо по видам запасов и ГТД

Закрытие периода Платформа 1С v8.3 1С:ERP Управление предприятием 2 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х Россия Бухгалтерский учет Платные (руб)

Обработка позволяет исправить развернутое сальдо по видам запасов, которое осталось после штатной обработки перепроведения документов. Подходит для конфигураций: УТ 11, КА 2, ERP

2400 руб.

15.07.2017    62622    144    45    

140
Комментарии
Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. VAAngelov 366 02.02.21 07:14 Сейчас в теме
Пригодится. Спасибо большое.
RPGrigorev; +1 Ответить
2. akR00b 22 02.02.21 09:27 Сейчас в теме
Спасибо, приятно смотреть на такой подход.
Алексей_mir2mb; VAAngelov; RPGrigorev; +3 Ответить
3. ILM 240 02.02.21 09:50 Сейчас в теме
У меня уже два года как переписаны все запросы при расчете себестоимости на ВТ, при включенном партионном учетё. Раньше на наших объемах считалось 8-12 часов, теперь меньше чем 45 минут. Индексировать нужно большие таблицы, иначе затраты на создание индекса могут быть больше чем на выборку данных. Но это в MS SQL.
RPGrigorev; +1 Ответить
4. RPGrigorev 692 02.02.21 09:55 Сейчас в теме
(3)Полностью согласен, индексы - не панацея, увеличение производительности запроса за счет индексов, иногда даже исключение, чем правило, необходимо изначально всё прикинуть, объемы выборок, СУБД, выполнить тестовые замеры
6. ILM 240 03.02.21 07:10 Сейчас в теме
(4) Да, необходима отладка каждого запроса и анализ возвращаемых данных. Ряд строк, которые потом пропускает алгоритм расчета себестоимости может отсекать в запросе, а некоторые запросы нужно усложнять, чтобы не делать снова поиск в постобработке результата.
RPGrigorev; +1 Ответить
5. RPGrigorev 692 02.02.21 09:56 Сейчас в теме
(3)однако, прирост скорости на SQL у Вас хороший, спасибо за комментарий
7. vano-ekt 124 04.02.21 11:54 Сейчас в теме
УПП еще сырая....
году так на десятом использования сервиса "Продление поддержки конфигурации УПП" может пофиксят
TerveRus; Leon75; Алексей_mir2mb; RPGrigorev; +4 Ответить
8. RPGrigorev 692 04.02.21 12:14 Сейчас в теме
(7)Все силы на ERP пущены)
TerveRus; Алексей_mir2mb; VAAngelov; +3 Ответить
9. PerlAmutor 129 06.02.21 08:30 Сейчас в теме
(8) К такой "махине" как ERP не были готовы даже разработчики платформы 1С. Платформа и по сей день к ней не готова. Объемы метаданных настолько огромны, что многие вещи происходят со скрипом. За 5 лет доработок и использования часто натыкался на стенку в вопросе "оптимизации", т.к. узкое место было не в запросах, а в ограничениях платформы. То не все ядра используются, то количество циклов кода зашкаливает за 100000 итераций, то количество рекурсивных вызовов, то объем контекстных данных форм, то количество ролей приходящееся на одного пользователя. Сам то пользователь может и 50% возможностей конфигурации не использует, но приходится "тянуть" и "перебирать" все зависимое и сопутствующее, что может быть пригодиться когда нибудь, когда включат функциональную опцию.
TerveRus; ILM; Алексей_mir2mb; RPGrigorev; +4 Ответить
10. mpeg1989 131 06.02.21 18:00 Сейчас в теме
Фирма 1С не рекомендует использовать СОЕДИНЕНИЕ с вложенными запросами, ибо оптимизатор не может определить статистику и скатывается во вложенные циклы. Если в обоих таблицах много данных, то это выполняется долго. Использование временных таблиц там, где нет никакого соединения, приводит к излишней нагрузке на tempdb.
TerveRus; RPGrigorev; +2 Ответить
11. RPGrigorev 692 06.02.21 18:03 Сейчас в теме
(10)Согласен, если соединений нет, то это уже другая дискуссия
12. Lukich66 82 07.02.21 20:14 Сейчас в теме
Вот уже 10лет как перешли на РАУЗ и не испытываем "партионных" трудностей, а так да, до 10г всю ночь вычислялось...
RPGrigorev; +1 Ответить
13. Cyberhawk 135 11.02.21 09:20 Сейчас в теме
Не хватает замера без индексирования временных таблиц
14. RPGrigorev 692 11.02.21 09:38 Сейчас в теме
(13)добрый день, в начале статьи, первый замер (скрин) - без индексирования
15. Cyberhawk 135 11.02.21 09:57 Сейчас в теме
(14) Не нашел в статье указанного "скрина"
16. RPGrigorev 692 11.02.21 10:10 Сейчас в теме
(15)далее идут скрины и объяснение, что в этом месте (наиболее затратном по времени) в запросе используются соединения с вложенными запросами, т.е. без индексирования
Прикрепленные файлы:
17. Cyberhawk 135 11.02.21 10:12 Сейчас в теме
(16)
соединение с вложенными запросами, т.е. без индексирования
Соединение с вложенными запросами = без временных таблиц, а не "без индексирования". А мой вопрос как раз про "без индексирования".
18. RPGrigorev 692 11.02.21 10:14 Сейчас в теме
(17)понял о чем вы, добавлю в статью
Cyberhawk; +1 Ответить
19. kupitv 12.01.23 13:13 Сейчас в теме
Привет, если вы реализуете то что описали в статье, напишите как в вами связаться?
20. RPGrigorev 692 12.01.23 18:48 Сейчас в теме
(19) Приветствую! Написал в личные сообщения
21. alishka777 01.02.23 21:41 Сейчас в теме
Приветствую, Руслан! Пожалуйста, напишите мне в личные сообщения. Прочёл Вашу статью (https://infostart.ru/1c/articles/1226815/) и у меня возникли некоторые вопросы по этой теме, но не могу написать Вам в личные сообщения. Если Вам нетрудно, напишите мне, пожалуйста. Спасибо заранее! С уважением Алиасхаб.
22. lada2011 06.02.23 13:44 Сейчас в теме
Не лезь туда, куда не лезет голова (народная мудрость) . Был у меня случай , переписал товарищ все запросы в документе расчета себестоимости на языке SQL. Пока база была небольшой все было хорошо, база выросла - при расчете появляется сообщение об ошибке " Недостаточно памяти". Анализируем, видим, что при выполнении запроса платформа на диске создает временный файл, при достижении размера файла 2 Гб платформа выдавала ошибку о недостатке памяти. Единственный выход - резать базу данных. Для расчета себестоимости за декабрь базу пришлось резать так, что данные остались только за декабрь. Вывод проверяйте доработки на больших объемах данных и контролируйте ограничения ОС на максимальный размер файла. Я бы сравнил временные файлы которые сформируются в стандартной и переработанной конфигурации при расчете себестоимости за одинаковые периоды. По моим наблюдениям скорость расчета себестоимости УПП определяется техническими параметрами сервера и SQL, на SQL 2019 скорость расчета возрастает.
23. RPGrigorev 692 06.02.23 14:54 Сейчас в теме
(22) Спасибо за комментарий! Хорошее замечание. Но в моем случае, проблема началась, как раз после того, как база стала большой и использование временных таблиц решило её.

Цитата, ИТС:
при использовании вложенных запросов оптимизатор СУБД не всегда может правильно определить размер выборки вложенного запроса и построить оптимальный план обращений к физическим таблицам базы данных, что сильно (иногда в десятки раз) может замедлить выполнение запроса.

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