← На главную

Длительное проведение документов перемещения и списания товаров — одна из наиболее распространенных проблем в конфигурациях «1С:Управление производственным предприятием» (особенно редакции 1.2) при длительной эксплуатации базы данных. Документы могут выполняться по несколько сотен секунд или вызывать полную блокировку работы пользователей. Разберем по шагам, почему возникает эта проблема и какие методы позволяют вернуть системе нормальное быстродействие.

Шаг 1. Локализация узких мест через замер производительности

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

1. Запустим сеанс «1С:Предприятие» в режиме отладки на копии рабочей базы данных.
2. В конфигураторе откроем меню Отладка — Замер производительности.
3. Проведем проблемный документ ПеремещениеТоваров.
4. Остановим замер производительности и отсортируем результаты по колонке времени выполнения.

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

Шаг 2. Отключение оперативного проведения по партиям

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

1. Перейдем в настройки параметров учета: Сервис — Настройка учета — Параметры учета.
2. Снимем флаг Списывать партии при проведении документов.
3. Перенесем списание себестоимости на регламентную обработку ПроведениеПоПартиям.
4. Настроим запуск этой обработки по расписанию во внерабочее время (ночью) либо периодически в течение дня отдельным фоновым потоком.

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

Шаг 3. Актуализация итогов регистров накопления

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

1. В режиме 1С:Предприятие откроем обработку Управление итогами (в меню «Операции» — «Управление итогами»).
2. Выделим регистры накопления складского и партионного учета (ТоварыНаСкладах, ТоварыОрганизаций, ПартииТоваровНаСкладах).
3. Нажмем Установить период рассчитанных итогов и выберем конец текущего или следующего месяца.
4. Включим регламентное задание по ежемесячному автоматическому сдвигу границы итогов вперед.

Шаг 4. Настройка регламентных процедур MS SQL Server

Временное ускорение проведения после перезагрузки сервера указывает на проблему с кэшем планов выполнения (Plan Cache) и неактуальной статистикой распределения данных. Настроим регламентное обслуживание СУБД:

1. Обновление статистики: настроим регулярный план обслуживания на стороне SQL Server с выполнением команды полного сканирования для таблиц базы: EXEC sp_updatestats; Или для конкретных тяжелых таблиц движений: UPDATE STATISTICS _AccumRgTxxxx WITH FULLSCAN;
2. Дефрагментация индексов: настроим еженедельную реорганизацию (REORGANIZE) или перестроение индексов (REBUILD), чтобы исключить разрастание индексных страниц.
3. Ограничение параллелизма (MAXDOP): в свойствах экземпляра SQL Server зададим параметр Max Degree of Parallelism = 1 (или по числу ядер на одном NUMA-узле) и увеличим Cost Threshold for Parallelism до 50, чтобы сложные запросы не вызывали взаимных ожиданий потоков CXPACKET.

Шаг 5. Переход на управляемые блокировки и разделение итогов

По умолчанию конфигурация УПП 1.2 работает в автоматическом режиме блокировок (уровень изоляции Serializable в MS SQL). Это вызывает эскалацию блокировок до уровня целых таблиц регистров. Проанализируем архитектурные доработки для устранения блокировок:

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

   
   Блокировка = Новый БлокировкаДанных;
   ЭлементБлокировки = Блокировка.Добавить("РегистрНакопления.ТоварыНаСкладах");
   ЭлементБлокировки.Режим = РежимБлокировкиДанных.Исключительный;
   ЭлементБлокировки.ИсточникДанных = ТабличнаяЧастьТовары;
   ЭлементБлокировки.ИспользоватьИзИсточникаДанных("Номенклатура", "Номенклатура");
   ЭлементБлокировки.ИспользоватьИзИсточникаДанных("Склад", "СкладПолучатель");
   Блокировка.Заблокировать();
   

Архитектурная альтернатива: переход на РАУЗ или чистую базу

Если база данных накопила десятилетнюю историю с большим числом незакрытых партий и остатков с отрицательными значениями, оптимизация старых запросов с подзапросами в УПП 1.2 может потребовать несоразмерных затрат времени. В этом случае наиболее эффективным решением является переход на редакцию 1.3 с использованием режима РАУЗ (Расширенная аналитика учета затрат), где онлайн-расчет партий полностью исключен из документов движения, либо перенос актуальных остатков в новую чистую информационную базу.