Почему долго проводятся документы в 1С:УТ 11 и как ускорить этот процесс?

Многие разработчики и администраторы систем на базе 1С сталкиваются с проблемой, когда привычная операция «Записать и закрыть» начинает занимать критически много времени. Особенно остро это ощущается в конфигурации 1С:Управление торговлей 11 при работе с расходными кассовыми ордерами, перемещениями и другими документами, которые активно используют подсистему взаиморасчетов. Давайте вместе проанализируем, где скрывается «бетон для пловца» и как оптимизировать работу системы.

Выясняем причину: почему система «думает» при проведении?

Первым делом нужно понять, на каком этапе происходит задержка, используя замеры в профиле производительности (APDEX). Часто мы ошибочно грешим на сервер или настройки PostgreSQL, но проблема может лежать на поверхности — в самом алгоритме проведения. Если замер производительности показывает, что время уходит на выполнение запросов к РегистрСведений.АналитикаУчетаПоПартнерам, значит, система пытается найти или создать уникальную комбинацию аналитик для каждого движения документа.

Главная «болезнь» многих типовых или доработанных механизмов — это выполнение тяжелых запросов внутри цикла. Представьте: в документе 10 строк, и для каждой строки система запускает запрос, который объединяет несколько таблиц, использует ЛЕВОЕ СОЕДИНЕНИЕ и проверяет наличие записи в регистре. Это создает колоссальную нагрузку на СУБД.

Анализируем проблемный код

Рассмотрим фрагмент кода, который часто становится виновником задержек. Когда мы используем конструкцию запроса, подобную приведенной ниже, внутри цикла, мы заставляем сервер 1С и СУБД выполнять одну и ту же вычислительную работу многократно:

ЗапросПоАналитикам.Текст = ЗапросПоАналитикам.Текст + \" |ВЫБРАТЬ РАЗЛИЧНЫЕ ... 
ИЗ Документ.РасходныйКассовыйОрдер.РасшифровкаПлатежа КАК ТаблицаРасшифровкаПлатежа 
ВНУТРЕННЕЕ СОЕДИНЕНИЕ ТаблицаОбъектовРасчетов КАК ТаблицаОбъектовРасчетов 
ПО ТаблицаРасшифровкаПлатежа.Заказ = ТаблицаОбъектовРасчетов.Заказ 
ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.АналитикаУчетаПоПартнерам КАК Аналитика 
ПО ТаблицаОбъектовРасчетов.Организация = Аналитика.Организация ...
ГДЕ ТаблицаРасшифровкаПлатежа.Ссылка = &Ссылка ...\";

Использование ОБЪЕДИНИТЬ ВСЕ в сочетании с ЛЕВОЕ СОЕДИНЕНИЕ при поиске аналитики — это очень дорогая операция. Если запрос выполняется для каждой строки документа отдельно, время проведения растет в геометрической прогрессии при увеличении табличной части.

Пошаговый алгоритм оптимизации

Чтобы ускорить проведение документов, рекомендуем придерживаться следующих правил оптимизации:

1. Выносите запрос из цикла. При настройке контроля остатков это самое важное правило. Вместо 10 запросов для 10 строк, подготовьте один запрос, который соберет все необходимые данные по всем строкам документа сразу.
2. Используйте временные таблицы. Соберите все уникальные комбинации аналитик из табличной части в массив или временную таблицу ТаблицаОбъектовРасчетов. Затем выполните один запрос к регистру АналитикаУчетаПоПартнерам для всей выборки целиком.
3. Проверьте индексы. Чтобы не допускать расхождения товаров на складах, если проблема все же кроется в СУБД, проанализируйте план выполнения запроса через Explain Analyze в PostgreSQL. Убедитесь, что поиск по ключу аналитики идет через Index Scan, а не через полное сканирование таблицы (Seq Scan).
4. Регламентные операции СУБД. Не забывайте про обновление статистики в PostgreSQL с помощью команды ANALYZE. Устаревшая статистика может заставлять оптимизатор СУБД выбирать неэффективные планы выполнения, даже если запрос написан правильно.
5. Минимизируйте блокировки. Используя отключение контроля по организациям, при активной работе пользователей (особенно 20 РМК) запись в регистр сведений может вызывать блокировки. Убедитесь, что ваша версия платформы актуальна — в более свежих релизах 1С механизмы блокировок работают значительно эффективнее.

Заключение

Оптимизация работы 1С — это всегда поиск баланса между функциональностью и нагрузкой. Если вы видите, что при нажатии кнопки «Провести» система задумывается, не спешите менять серверное «железо». Начните с анализа запросов: если вы обнаружили сложный SELECT с JOIN внутри цикла — это ваша главная цель. Перепишите его так, чтобы он работал с набором данных, а не с каждой строкой по отдельности, и вы увидите, как время проведения документа сократится в разы.

Помните: каждый запрос, который вы пишете, должен быть эффективным с точки зрения объема данных. Меньше обращений к базе — быстрее отклик системы!