Переход с платформы 1С 7.7 (например, с конфигурации «Торговля и Склад») на современную 1С:Управление торговлей 11.4 часто сопровождается шоком от падения производительности. Если в старой системе документы проводились мгновенно, то в новой Реализация товаров и услуг из трех позиций может «зависать» на минуту и более. Проанализируем причины этой проблемы и разберем по шагам методы оптимизации системы.
Одной из главных причин медленной работы УТ 11.4 является механизм распределения расчетов. В конфигурации существует два режима ведения взаиморасчетов: «Онлайн» и «Офлайн». Рассмотрим подробнее, как это влияет на скорость.
В режиме «Онлайн» система при проведении каждого документа пытается в реальном времени рассчитать распределение оплаты по конкретным накладным и заказам. Это требует выполнения тяжелых запросов к регистру РасчетыСКлиентамиПоДокументам. Если база содержит сотни тысяч записей, проведение превращается в мучение.
Решение: перейдем в раздел НСИ и администрирование -> Казначейство и взаиморасчеты и установим режим «Офлайн (отложенное проведение)». В этом случае сложные расчеты будут вынесены в отдельное фоновое регламентное задание, а документы начнут проводиться значительно быстрее.
Проанализируем ситуацию, когда таблица итогов (физическое имя в SQL обычно начинается с AccumRgT) в разы или даже в десятки раз превышает размер таблицы самих движений (AccumRg). В 1С 8.3 это часто связано с использованием разделителя итогов и высокой уникальностью измерений.
Рассмотрим пример регистра РасчетыСКлиентамиПоДокументам. Одним из его ключевых измерений является ОбъектРасчетов, в роли которого выступает конкретный документ. Поскольку каждый документ уникален, итоги по этому регистру не могут «свернуться». В результате система хранит записи итогов на каждую дату актуальности. Если данные за прошлые годы были загружены «пачкой» без соблюдения хронологии и последующего закрытия периодов, таблица итогов разрастается до гигантских размеров, что парализует работу СУБД.
Для исправления ситуации выполним следующие действия:
Часто проблема кроется не в коде 1С, а в настройках сервера баз данных. Выясним, какие параметры критичны для УТ 11.4. Проанализируем параметр Max Degree of Parallelism (MAXDOP). Для систем на базе 1С крайне рекомендуется устанавливать значение 1. Рассмотрим, почему это важно:
Если SQL-сервер пытается распараллелить один тяжелый запрос (например, расчет остатков по партиям) на 16 или 32 ядра, это часто приводит к взаимным блокировкам (deadlocks). Вместо ускорения мы получаем очередь ожиданий. Установка MAXDOP = 1 заставляет один запрос выполняться в рамках одного процессорного потока, что делает работу системы предсказуемой и стабильной.
Также проверим режим управления блокировками. Для конфигурации УТ 11.4 должен быть установлен только «Управляемый» режим. Если после переноса данных из 7.7 в свойствах базы на уровне метаданных остался «Автоматический» или «Смешанный», это фатально скажется на параллельной работе пользователей.
В УТ 11 реализована сложная система отложенных расчетов. Существуют специальные регистры сведений, выполняющие роль «очереди»:
ОчередьДокументовДляРасчетаПартийЗатратОчередьРаспределенияЗапасовОчередьРаспределенияВзаиморасчетовРазберем ситуацию: вы загрузили данные за весь 2018 год. В эти очереди попали сотни тысяч записей. При попытке провести любой текущий документ система может обращаться к этим очередям. Если регламентные задания по закрытию месяца и расчету партий не запускались, очереди переполнены. Это и вызывает задержку в 1 минуту при проведении реализации.
Рекомендация: после массовой загрузки данных необходимо выполнить процедуру «Закрытие месяца» для всех исторических периодов. Это очистит очереди и актуализирует итоги.
Многие руководители требуют переносить в новую базу историю продаж за 5 и более лет. Посмотрим на это с технической стороны. УТ 11.4 — это сложная ERP-подобная система с тяжелыми механизмами контроля лимитов и остатков. Запросы вида:
РегистрНакопления.ЗаказыКлиентов.Обороты(,, РЕГИСТРАТОР, )
ГДЕ ЗаказыОстатки.Регистратор <> &Регистратор
начинают работать крайне медленно, когда в виртуальных таблицах накоплены миллионы записей за прошлые пятилетки. Для аналитики продаж за 5 лет правильнее использовать внешние системы (BI-аналитику или простую копию старой базы 7.7), а в рабочую УТ 11.4 переносить только остатки и незавершенные цепочки документов (открытые заказы, неоплаченные накладные).
После массового импорта данных индексы SQL-базы подвергаются сильной дефрагментации, а статистика распределения данных становится неактуальной. Оптимизатор SQL-сервера начинает выбирать неверные планы запросов (например, вместо быстрого поиска по индексу Index Seek выполняется полное сканирование огромной таблицы Table Scan).
Проанализируем необходимые операции обслуживания:
Соблюдение этих правил позволит превратить «медленного монстра» УТ 11.4 в отзывчивый инструмент, способный быстро обрабатывать большие объемы данных даже при наличии сложного партионного учета и детализированных взаиморасчетов.