Ошибка производительности при проведении этапа 2.2 в ERP 2.4 и ERP 2.5

06.12.21

База данных - HighLoad оптимизация

Хочется поделиться одним подводным камнем, с которым могут встретиться другие пользователи ERP. Искал решение в интернете, но ничего похожего не нашел. Поэтому решил создать эту тему.

Некоторое время назад пользователи стали встречаться с ошибками ожидания блокировки при проведении этапов производства. С помощью технологического журнала выяснили, что виновником блокировки является проведение этапа в фоновом задании "Обработка очереди <Задания к обработке этапов производства>". Поскольку проведение объемных этапов делалось в фоне (инициировано проведением документа "Производственная операция"), проблему с производительностью заметили не сразу. На первом скриншоте видно, что время выполнения задания (по сути все время занимает проведение этапа) неприемлемо долгое.

Анализ показал, что время проведения зависит от количества строк в табличных частях документа. Причем увеличивается крайне нелинейно. Виновником является запрос в процедуре "ПроверитьРеквизитыШапки" модуля менеджера Этапа производства2_2. На втором скриншоте показаны 4 замера. При количестве строк в ТЧ "Расход" в 4-5 тысяч строк практически все время занимает выполнение запроса (4-5 часов).

Главным виновником найден пакет запроса "ВТКоличествоСтрокВТЧ" (результаты на третьем скриншоте). Этот пакет формируется отдельной функцией "ТекстЗапросаКоличествоСтрокВТЧДляПроверкиЗаполнения". Она переписана и вынесена в расширение.

В результате проведение этапа в 6000 строк в ТЧ "Расход" выполнялось около 40 секунд (бОльшую часть занимают другие объемные процедуры).

В тексте представлен альтернативный вариант процедуры "ТекстЗапросаКоличествоСтрокВТЧДляПроверкиЗаполнения". Соединения таблиц заменил на объединение.

   

 

Данная проблема присутствует (проверено) в релизах 2.4.13.103; 2.5.6.81; 2.5.6.118; 2.5.6.137; 2.5.6.144; 2.5.6.171.

P.S. Проблема скорее всего актуальна и для других релизов 2.4. Там текст запроса аналогичен.

 
 Текст исходной процедуры

 

Вступайте в нашу телеграмм-группу Инфостарт

ERP производительность этап производство

См. также

HighLoad оптимизация Программист 1С 8.3 1С:ERP Управление предприятием 2 Бесплатно (free)

Использование оператора «В» для полей или данных составного типа (например, Регистратор) может приводить к неочевидным проблемам.

10.11.2025    7663    ivanov660    48    

52

HighLoad оптимизация Программист 1С:Предприятие 8 1C:ERP Бесплатно (free)

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

18.02.2025    9712    ivanov660    39    

61

HighLoad оптимизация Технологический журнал Системный администратор Программист Бесплатно (free)

Обсудим поиск и разбор причин длительных серверных вызовов CALL, SCALL.

24.06.2024    12216    ivanov660    13    

64

HighLoad оптимизация Программист 1С:Предприятие 8 Бесплатно (free)

Метод очень медленно работает, когда параметр приемник содержит намного меньше свойств, чем источник.

06.06.2024    18701    Evg-Lylyk    73    

46

HighLoad оптимизация Программист 1С:Предприятие 8 1C:Бухгалтерия Бесплатно (free)

Анализ простого плана запроса. Оптимизация нагрузки на ЦП сервера СУБД используя типовые индексы.

13.03.2024    9151    spyke    29    

54

HighLoad оптимизация Программист 1С:Предприятие 8 Бесплатно (free)

Оказывается, в типовых конфигурациях 1С есть, что улучшить!

13.03.2024    12652    vasilev2015    22    

47
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. tl_pj 07.12.21 18:56 Сейчас в теме
А можете добавить текст процедуры до изменений?
Для тех у кого нет под рукой ЕРП, но все равно интересно
2. Rokky78 42 08.12.21 08:56 Сейчас в теме
(1) Добавил в конец статьи.
3. DyGer 08.12.21 10:09 Сейчас в теме
ERP 2.5.7.226 функция не поменяла код. Так что кочует данный код из релиза в релиз.
4. roman72 404 10.12.21 14:11 Сейчас в теме
Снижение времени работы функционала с 5 часов до 40 секунд - великолепное решение!

Но в целом что получается.....
40 секунд - это на один этап.
Если в расчёт идут 10 000 этапов, то время их пересчёта даже с оптимизированным кодом составит более 100 часов.
Получается 1С ERP не подходит для предприятий с многопоточным производством (большим количеством этапов).
5. Rokky78 42 13.12.21 12:04 Сейчас в теме
(4)
Тут нужно сказать, что документы такого объема даже для нашего предприятия это было скорее исключение. Насколько мне известно, больше таких заказов не было.
40 секунд - это для этапа с несколькими тысячами строк. БОльшую часть времени занимает выполнение запроса в модуле набора записей РН "СебестоимостьТоваров". До какого то момента этот запрос всегда является "лидером" по времени. При увеличении количества строк в разных ТЧ пальма первенства переходит запросу о котором я написал в статье.
Судя по тому, что я ничего не нашел в интернете, у народа нет документов с таким количеством строк. А значит и запрос в модуле набора записей РН "СебестоимостиТоваров" выполняется порядком быстрее.
6. roman72 404 13.12.21 15:40 Сейчас в теме
(5) Тогда можно сказать что этому проекту "повезло".
Но тем не менее, согласитесь, сомнения в производительности ERP на крупных производствах есть.
Впрочем, это давно уже известно, и даже к 1С ERP добавляют продукты от иностранных вендоров, которые занимаются расчетом производственной программы.
Да и у этих систем начинаются проблемы при приближении к порогу 10 000 этапов/заказов.
Для отправки сообщения требуется регистрация/авторизация