Как ускорить проведение документов в 1С:ERP, если запись движений занимает слишком много времени?

В процессе эксплуатации высоконагруженных систем на базе 1С:ERP Управление предприятием часто возникает ситуация, когда время проведения документа становится критическим. Проблема часто локализуется в модуле проведения, где стандартный метод Объект.Движения.Записать() может выполняться десятки секунд (в нашем примере — 43 секунды). Рассмотрим подробно, почему это происходит и как мы можем оптимизировать этот процесс, опираясь на технические особенности платформы и архитектуру конфигурации. Для изучения дополнительного практического кейса можно использовать материал с примером решения проблем быстродействия в ERP.

Анализ проблемы и диагностика

Первым делом проанализируем результаты замера производительности. Если основное время уходит именно на Движения.Записать(), это означает, что проблема не в программном коде подготовки данных (формировании таблиц значений для движений), а в физической записи данных в таблицы СУБД и пересчете итогов. Выясним причину такой длительной работы через технологический журнал или средства мониторинга SQL. Как показывает практика, в подобных случаях система генерирует огромное количество мелких запросов (десятки тысяч) к одной и той же таблице, например, к регистру РегистрНакопления.РасчетыСКлиентами. Для сбора данных технологического журнала и диагностики контура подойдёт инструмент для замера производительности и поиска узких мест.

Причина 1. Механизм онлайн-взаиморасчетов в ERP

Разберем, как работает современная ERP (начиная с версий 2.4.11 и 2.5). По умолчанию в системе может быть включен режим «Онлайн-взаиморасчеты». Его суть заключается в том, что в момент проведения документа система пытается мгновенно распределить оплаты по накладным, рассчитать курсовые разницы и определить сроки погашения задолженности. Если вы меняете документ «задним числом» или работаете в цепочке с большим количеством связанных документов, 1С начинает пересчитывать всю «цепочку распределения». Это порождает лавинообразный рост операций записи (те самые 34 000 операций вставки и обновления).

Решение: Пересмотрим архитектуру ведения расчетов. В настройках системы (НСИ и администрирование — Казначейство — Взаиморасчеты) можно переключить режим на «Оффлайн». В этом случае:

• При проведении документа данные записываются только в «оперативные» регистры.
• Сложные расчеты распределения (по объектам расчетов и срокам) выполняются отдельным регламентным заданием в фоновом режиме.
• Скорость записи документа Движения.Записать() возрастает в разы, так как исключается пересчет всей цепочки документов в транзакции проведения.

Причина 2. Состояние таблиц итогов и «раздувание» данных

Проанализируем ситуацию с точки зрения СУБД. Регистрам накопления свойственно накопление итогов. Если в регистре РасчетыСКлиентами (или его техническом аналоге в SQL AccumRgT29391) таблица итогов значительно больше основной таблицы движений, это явный признак проблемы. Рассмотрим возможные причины:

1. Неуникальность измерений: Если в регистр записываются данные с пустыми измерениями или «битыми» ссылками, итоги не могут эффективно свернуться.
2. Ошибочные даты: Проверим базу на наличие документов с датами из далекого прошлого или будущего (например, 0020 год или 2050 год). При записи таких данных системе приходится пересчитывать итоги за огромный интервал периодов, что блокирует таблицу.
3. Актуальность итогов: Выполним стандартную процедуру «Пересчет итогов» через консоль управления или в режиме «Конфигуратор». Это поможет физически пересобрать таблицу итогов, удалив из нее лишние записи.

Причина 3. Настройки SQL Server и блокировки

Если база работает в клиент-серверном режиме, выясним, настроены ли планы обслуживания. Для ERP критически важна правильная работа с индексами и статистикой. Рассмотрим необходимые шаги:

Обновление статистики: Убедимся, что статистика обновляется регулярно (ежедневно или даже чаще для нагруженных таблиц). Если SQL Server использует устаревшую статистику, он строит неэффективный план запроса для вставки данных.

Включение RCSI (Read Committed Snapshot Isolation): Это фундаментальная настройка для 1С на MS SQL Server. Она позволяет читающим транзакциям не ждать завершения пишущих. Без включенного Snapshot Isolation запись документа на 40 секунд может полностью остановить работу других пользователей с этим же регистром.

Посмотрим на полезную команду для сброса процедурного кэша, если SQL «зациклился» на плохом плане выполнения:

-- Выполнять с осторожностью на рабочей базе в часы минимальной нагрузки
DBCC FREEPROCCACHE;

Причина 4. Производительность дисковой подсистемы

Проанализируем аппаратную часть. При выполнении метода Записать() происходит активное взаимодействие с базой TempDB и файлами данных/логов основной БД. Если дисковая подсистема имеет высокие задержки (latency), никакая оптимизация кода не поможет.

• Рекомендуется перенос базы данных (особенно TempDB) на высокоскоростные накопители NVMe (например, Intel P4800X или Samsung PM1735).
• Проверим очередь к диску. Если она стабильно выше 1–2, диски не справляются с потоком IOPS, возникающим при массовой записи движений.

Причина 5. Влияние функциональных опций и расширений

Выясним, не замедляют ли процесс дополнительные проверки. В ERP часто включены опции «Запрет отгрузки при наличии задолженности» или «Контроль лимитов кредитования». Эти механизмы срабатывают именно в момент фиксации движений. Проверим:

1. Нет ли в системе расширений, которые подписаны на событие ПриЗаписи или ПередЗаписью данного регистра. Сторонний код в этих подписках выполняется внутри транзакции проведения документа.
2. Если замер показывает, что время тратится внутри типовых механизмов контроля, стоит рассмотреть возможность перехода на «отложенный контроль» или оптимизацию прав доступа.

Резюме и план действий

Подводя итог, для исправления ситуации выполним следующие шаги:

1. Проверим режим взаиморасчетов: Если включен «Онлайн», попробуем переключить на «Оффлайн» на тестовой копии и сравним скорость.
2. Проведем аудит итогов: Выполним поиск записей с некорректными датами и запустим пересчет итогов.
3. Обслужим СУБД: Обновим статистику со 100% сканированием (FullScan) и выполним дефрагментацию индексов для таблицы AccumRgT29391.
4. Мониторинг железа: Убедимся, что задержки дисковой системы при записи не превышают допустимых значений (5–10 мс).

Применение этих мер в комплексе обычно позволяет сократить время выполнения Записать() с десятков секунд до приемлемых 1–2 секунд, что значительно повышает комфорт работы пользователей в 1С:ERP.