Почему зависает проведение по партиям в 1С:Управление торговлей 10 и как его ускорить?

← На главную

Ситуация, когда регламентная обработка Проведение по партиям в конфигурации 1С:Управление торговлей 10.3 за первые месяцы года отрабатывает за час-полтора, а на следующем периоде внезапно замедляется до нескольких секунд на один документ, встречается регулярно. Переход с долей секунды на 5–10 секунд на документ превращает перепроведение месяца в многодневный процесс. Разберем по шагам, почему возникает деградация производительности и какими инструментами можно вернуть штатную скорость обработки.

Шаг 1. Проверка и сдвиг даты рассчитанных итогов

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

Проанализируем текущее состояние итогов:

Перейдем в главное меню: Операции — Управление итогами.
Проверим колонку Рассчитан по для всех регистров накопления, связанных с партионным учетом (ПартииТоваровНаСкладах, ТоварыНаСкладах и сопутствующие регистры).
Если дата итогов установлена на прошлый месяц, сдвинем ее вперед на конец обрабатываемого периода или выполним команду Установить расчет по... на конец будущего месяца.
При проведении больших периодов полезно использовать пошаговый сдвиг: провели документы за один месяц — пересчитали итоги на конец этого месяца, затем перешли к следующему периоду.

Шаг 2. Корректировка параметров порций в обработке

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

Посмотрим на настройки на форме обработки:

Откроем обработку Проведение по партиям.
Найдем параметры: Максимальное количество строк в транзакции и Максимальное количество документов в выборке.
По умолчанию в типовой конфигурации установлено значение 1000. Уменьшим оба значения до 100.

Такое уменьшение снижает размер одной транзакции, освобождает журнал транзакций СУБД и предотвращает эскалацию блокировок, позволяя серверу эффективнее освобождать оперативную память между пакетами.

Шаг 3. Оптимизация запросов списания: переход на временные таблицы

В старых релизах конфигураций на обычных формах алгоритм распределения партий формировал сложные запросы к остаткам с использованием вложенных подзапросов. Когда объем движений в базе превышает определенный порог, оптимизатор СУБД (в частности, Microsoft SQL Server) строит неоптимальный план выполнения, переходя с точечного поиска по индексу (Index Seek) на полное сканирование таблицы (Table Scan или Index Scan).

Выясним причину и локализуем проблему:

Запустим замер производительности в конфигураторе на проблемном документе.
В модуле списания партий (общий модуль ПартионныйУчет или модуль обработки) выявим три ключевых запроса: по управленческому, бухгалтерскому и налоговому учету.
Заменим конструкции с вложенными подзапросами выборки остатков на использование временных таблиц через МенеджерВременныхТаблиц.
Обязательно добавим индексацию полей соединения во временных таблицах (по полям Номенклатура, ХарактеристикаНоменклатуры, Склад).

Пример оптимизации структуры запроса в модуле:


Запрос = Новый Запрос;
Запрос.МенеджерВременныхТаблиц = Новый МенеджерВременныхТаблиц;
Запрос.Текст = 
"ВЫБРАТЬ
|	ТаблицаСписания.Номенклатура КАК Номенклатура,
|	ТаблицаСписания.Склад КАК Склад,
|	ТаблицаСписания.Количество КАК Количество
|ПОМЕСТИТЬ ВТ_ТоварыКРаспределению
|ИЗ
|	&ТаблицаДокумента КАК ТаблицаСписания
|ИНДЕКСИРОВАТЬ ПО
|	Номенклатура,
|	Склад;
|
|ВЫБРАТЬ
|	Остатки.Номенклатура,
|	Остатки.Партия,
|	Остатки.КоличествоОстаток
|ИЗ
|	ВТ_ТоварыКРаспределению КАК Товары
|	ВНУТРЕННЕЕ СОЕДИНЕНИЕ РегистрНакопления.ПартииТоваровНаСкладах.Остатки(&МоментВремени, ) КАК Остатки
|		ПО Товары.Номенклатура = Остатки.Номенклатура
|		И Товары.Склад = Остатки.Склад";

Такое разделение жестко фиксирует план выполнения запроса в СУБД и исключает спонтанное замедление именно на марте из-за накопленного объема строк.

Шаг 4. Обслуживание СУБД: реиндексация и актуализация статистики

Если код запросов не менялся, а замедление наступило на конкретном месяце, оптимизатор запросов СУБД ориентируется на устаревшую статистику распределения данных.

Проведем регламентные работы на сервере баз данных:

Реиндексация таблиц: выполним дефрагментацию и перестроение индексов по всем таблицам базы, уделив особое внимание регистру сведений СписанныеТовары и регистрам партий. В файловом варианте базы для этого достаточно выполнить процедуру Тестирование и исправление информационной базы с флагом Реиндексация таблиц.
Обновление статистики с полным сканированием: выполним команду обновления статистики в SQL Server с параметром FULLSCAN для таблиц итогов партионного учета. Автоматическая статистика часто опрашивает лишь малый процент выборки, из-за чего для нового месяца строится ошибочный план выполнения.
Контроль tempdb и журнала транзакций: убедимся, что автоувеличение (Autogrowth) файлов служебной базы tempdb и файла лога .ldf задано фиксированным размером в гигабайтах, а не в процентах. Частые мелкие приращения дискового пространства приводят к секундным зависаниям на каждом документе.

Шаг 5. Поиск отрицательных остатков и некорректных движений

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

Проанализируем данные на наличие учетных ошибок:

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

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