Вопрос повышения производительности при проведении больших массивов документов — одна из самых сложных и обсуждаемых тем в сообществе 1С. Часто мы сталкиваемся с тем, что стандартное перепроведение за длительный период занимает часы, а то и дни. В этой статье мы подробно разберем, можно ли распараллелить проведение документов, какие технические преграды стоят на этом пути и как оптимизировать систему на уровне платформы и базы данных.
Прежде чем приступать к написанию кода для запуска фоновых заданий, проанализируем ситуацию с точки зрения архитектуры данных. Основная проблема параллельного проведения заключается не в запуске нескольких потоков, а в блокировках. Когда несколько сеансов одновременно пытаются изменить данные в одних и тех же таблицах (например, таблицы остатков регистров), возникают конфликты.
Разберем основные факторы, которые делают многопоточное проведение нетривиальной задачей:
Для реализации собственного механизма многопоточности мы будем использовать объект ФоновыеЗадания. Рассмотрим подробнее алгоритм эффективного распределения нагрузки. Не стоит создавать отдельное фоновое задание на каждый документ — это породит огромные накладные расходы на запуск сеансов.
Правильный подход заключается в пакетной обработке. Проанализируем примерную схему работы:
Пример структуры кода для запуска параллельной обработки:
// Пример инициализации потоков
ПараметрыЗапуска = Новый Структура("СписокДокументов", ПакетДокументов);
ФоновыеЗадания.Выполнить("ОбработкаПроведения.ВыполнитьПроведениеПакета", ПараметрыЗапуска);
Выясним причину, по которой это может не сработать. Если документы в разных пакетах «пересекаются» по ключевым аналитикам (один и тот же склад, номенклатура, организация), потоки будут стоять в очередях ожидания блокировок. Чтобы этого избежать, используйте логическое секционирование: распределяйте документы по разным потокам так, чтобы в одном потоке были документы по Организации А, а в другом — по Организации Б.
Рассмотрим штатные возможности платформы 1С, которые помогают в многопоточной среде. Одним из важнейших свойств регистров накопления и бухгалтерии является РазделениеИтогов. Если это свойство включено, платформа создает несколько записей итогов вместо одной. Разберем по шагам, как это работает: разные сеансы пишут в свои «ячейки», а при чтении остатков система суммирует данные из всех ячеек. Это критически важно для снятия блокировок при записи.
Также в современных конфигурациях (ERP 2.5, УТ 11) реализовано двухфазное (отложенное) проведение. Посмотрим, как это ускоряет работу:
Часто узким местом является не код 1С, а настройки СУБД. Проанализируем влияние режима Read Committed Snapshot Isolation (RCSI) в MS SQL Server. Включение этого режима позволяет читающим запросам не блокироваться пишущими. Это значительно снижает вероятность возникновения Deadlocks (взаимоблокировок) при массовом проведении, когда один поток пытается рассчитать остатки (читает), а другой в этот момент записывает движения.
Также важно обратить внимание на TempDB. При многопоточном проведении 1С генерирует огромное количество временных таблиц. Если база TempDB расположена на медленном диске, вся мощь процессоров будет нивелирована дисковыми задержками. Рекомендуется располагать TempDB на максимально быстрых NVMe-накопителях и настраивать количество файлов базы данных равным количеству ядер процессора.
Вопрос ускорения трудоемких операций в Бухгалтерии Предприятия 3.0 стоит особенно остро. Поскольку восстановление последовательности требует строгой хронологии, классическое распараллеливание здесь практически невозможно. Однако мы можем применить следующие методы:
Если программные методы исчерпаны, остается путь оптимизации инфраструктуры. Посмотрим на критические точки:
Shared Memory включен — это ускорит передачу данных между процессами без использования сетевого стека.В заключение отметим: многопоточное проведение — это не «волшебная кнопка», а сложный инструмент, требующий глубокого понимания структуры данных вашей конфигурации. Перед внедрением параллельной обработки всегда проводите замеры в копии базы на предмет появления логических ошибок в остатках и себестоимости.