При работе с крупными базами данных на платформе 1С:Предприятие 8, особенно в конфигурациях типа Управление торговлей 10.3, пользователи часто сталкиваются с деградацией производительности при массовом перепроведении документов за прошлые периоды. Рассмотрим ситуацию: база растет, расчет партий усложняется, а технологическое окно для обслуживания базы данных сокращается из-за круглосуточной работы финансистов. Разберем по шагам, как можно ускорить процесс проведения документов и какие инструменты для этого использовать.
Прежде чем приступать к оптимизации, проанализируем, почему проведение может замедляться со временем. Основными факторами являются рост объема данных в регистрах накопления (особенно в таблицах итогов), фрагментация индексов в SQL Server и неактуальность статистики. Проверим также влияние партионного учета, который в типовых решениях на обычных формах является наиболее «тяжелым» узлом.
Для объективной оценки используем методику замера производительности. Не стоит полагаться на субъективные жалобы пользователей. Проанализируем показатели APDEX (Application Performance Index), чтобы понять, какая именно часть проведения занимает больше всего времени: чтение остатков, расчет партий или физическая запись движений в базу данных.
Одной из главных проблем является отсутствие регулярного обслуживания базы данных. Если индексы сильно фрагментированы, SQL Server тратит больше времени на поиск данных. Рассмотрим, какие операции по обслуживанию наиболее критичны:
Практический совет: Если у вас нет возможности выделить длительное окно для полного перестроения индексов, настройте ежедневную реорганизацию индексов и ежедневное обновление статистики с параметром FULLSCAN для наиболее нагруженных таблиц регистров накопления.
Выясним причину, по которой SQL Server может «захлебываться» при массовой записи. Выполним следующие настройки на уровне СУБД:
1. Настройка TempDB: При проведении документов 1С активно использует временные таблицы. Разделим базу tempdb на несколько файлов одинакового размера (рекомендуется количество файлов, равное количеству ядер процессора, но не более 8). Это значительно снизит конкуренцию за распределение страниц.
2. Параметр MAXDOP: Установим Max Degree of Parallelism в значение 1. Это предотвратит ситуацию, когда SQL Server пытается распараллелить простые запросы 1С, что в многопользовательской среде часто ведет к взаимным блокировкам.
Рассмотрим случай, когда перепроведение выполняется для целей управленческого учета. Часто в модулях проведения документов зашито огромное количество проверок (на наличие остатков, на заполнение реквизитов, на соответствие характеристик). При массовом перепроведении за прошлые периоды многие из этих проверок избыточны, так как данные уже проверены при первичном вводе.
Посмотрим на пример оптимизации через запись наборов записей. Вместо стандартного вызова ДокументОбъект.Записать(РежимПроведения.Проведение), который запускает весь цикл событий в модуле документа, мы можем программно формировать движения и записывать их напрямую в регистры:
// Пример упрощенной записи наборов записей регистра накопления
НаборДвижений = РегистрыНакопления.ПартииТоваровНаСкладах.СоздатьНаборЗаписей();
НаборДвижений.Отбор.Регистратор.Установить(СсылкаНаДокумент);
// Формируем таблицу движений (например, на основе рассчитанных данных)
// ... логика расчета ...
НаборДвижений.Загрузить(ТаблицаНовыхДвижений);
НаборДвижений.Записать();
Такой подход позволяет исключить выполнение кода в модулях документа и подписках на события, что может ускорить процесс в несколько раз. Однако будьте осторожны: при таком методе вы берете на себя полную ответственность за корректность данных в регистрах.
В конфигурации Управление торговлей 10.3 предусмотрен механизм отложенного проведения по партиям. Разберем, как это работает. В настройках параметров учета можно отключить флаг «Списывать партии при проведении документов». В этом случае при проведении документа формируются только движения по остаткам (оперативный учет), а тяжелый расчет себестоимости и списания партий переносится в регламентную процедуру Проведение по партиям.
Это позволяет пользователям работать быстро днем, а серверу — спокойно рассчитывать партии ночью в монопольном режиме, когда нет конкуренции за таблицы ПартииТоваровНаСкладах.
Проанализируем аппаратную часть и системные настройки сервера. Часто банальные вещи мешают производительности:
.mdf и .ldf исключены из сканирования.Simple. Это сэкономит время на записи лога транзакций и предотвратит его чрезмерное раздувание.В заключение отметим, что лучшим решением всегда является комбинация методов: грамотное регламентное обслуживание SQL Server, очистка базы от неактуальных данных и оптимизация алгоритмов проведения в самой 1С.