Перенос данных из исторических систем (таких как УПП 1.3) в современные решения на базе 1С:ERP — это сложнейший технический процесс, особенно когда речь идет о крупных предприятиях. Ситуация, когда файл объемом в 3 ГБ загружается несколько дней, а общий объем выгрузки достигает 60 ГБ, сигнализирует о критических проблемах в архитектуре обмена. Разберем подробно, почему это происходит и как мы можем кардинально ускорить процесс.
Прежде чем приступать к оптимизации, выясним, почему стандартный механизм Универсальный обмен данными XML работает медленно. Основная проблема заключается в том, что процесс чтения XML-файла и создание объектов в базе данных — это ресурсозатратные операции, которые по умолчанию выполняются в один поток. Даже если у сервера 128 ГБ оперативной памяти и 32 ядра процессора, загрузка одного файла будет использовать только одно ядро.
Рассмотрим основные факторы замедления:
Номенклатура) ERP выполняет десятки проверок, записывает данные в дополнительные регистры, обновляет индексы и запускает подписки на события.Первым делом подготовим «почву» на уровне СУБД. Без правильной настройки SQL-сервера никакие изменения в коде 1С не дадут существенного прироста.
Переводим базу в модель восстановления Simple: По умолчанию базы данных часто находятся в режиме Full, что заставляет SQL записывать каждое действие в .ldf файл. Для периода миграции переключим режим:
Это позволит SQL-серверу не накапливать гигантские логи транзакций, которые тормозят дисковую подсистему.
Настраиваем TempDB: Процесс загрузки активно использует временные таблицы. Убедимся, что файлы TempDB расположены на самом быстром диске (NVMe SSD) и их количество соответствует количеству ядер процессора (но не более 8).
Современные конфигурации перегружены «сервисными» механизмами, которые крайне полезны в работе, но вредны при первоначальной загрузке данных. Проанализируем, что нужно отключить:
Отключение полнотекстового поиска: Каждая новая запись в справочнике заставляет систему ставить задание на обновление индекса ППП. Перейдем в НСИ и администрирование -> Поддержка и обслуживание -> Полнотекстовый поиск и снимем флаг Полнотекстовый поиск данных. После загрузки индекс можно будет перестроить одной регламентной операцией.
Версионирование объектов: Если в системе включено хранение истории изменений, то при каждой записи справочника Контрагенты или Номенклатура создается запись в регистре сведений ВерсииОбъектов. Это удваивает нагрузку. Отключим версионирование для всех объектов на время загрузки.
Дата запрета редактирования: Проверим, чтобы для пользователя, под которым идет загрузка, не действовала дата запрета. В противном случае платформа будет выполнять дополнительные проверки прав доступа при каждой записи объекта.
Если мы используем типовые правила из комплекта поставки, они часто содержат избыточные обработчики. Посмотрим на ситуацию глазами разработчика 1С.
Поиск по Уникальному Идентификатору (GUID): Убедимся, что в правилах для справочников включен поиск по UID. Если поиск идет по наименованию или ИНН/КПП, система на каждом объекте делает запрос к базе, что при миллионах записей убивает производительность. Поиск по GUID — самый быстрый, так как это индексированное поле на уровне СУБД.
Отключение «тяжелых» обработчиков: В правилах конвертации (ПКО) часто прописаны алгоритмы в событии ПослеЗагрузки. Например, пересчет цен или заполнение доп. реквизитов. Рассмотрим возможность временного комментирования этих участков кода. Пример кода, который может замедлять загрузку:
// Пример ресурсозатратного обработчика "ПослеЗагрузки"
Если НЕ Объект.ЭтоГруппа Тогда
// Поиск цен, создание договоров и прочее
Справочники.ДоговорыКонтрагентов.СоздатьДоговорПоУмолчанию(Объект);
КонецЕсли;
Такие действия лучше выполнить один раз после загрузки всех данных с помощью групповой обработки объектов.
Это самый эффективный метод. Поскольку один процесс 1С грузит 3 ГБ три дня, мы разделим эти данные на 10 частей и запустим их параллельно.
Как правильно разделить данные:
Номенклатура можно выгрузить десятью файлами, настроив фильтр в УПП (например, по группам или по первой букве наименования).Запуск параллельных сессий: Запустим несколько экземпляров 1С под разными пользователями. Каждый экземпляр будет обрабатывать свой XML-файл. При этом важно настроить количество объектов в транзакции в обработке Универсальный обмен данными XML. Оптимальное значение — от 500 до 1000. Слишком большая транзакция может привести к блокировкам, слишком маленькая — к избыточным обращениям к диску.
В Сообщении 10 и 11 правильно отмечено, что справочники могут весить гигабайты из-за присоединенных файлов (картинок, сканов договоров). Стандартный XML-обмен кодирует бинарные данные в формат Base64, что увеличивает их объем на 33% и создает огромную нагрузку на процессор при парсинге.
Рекомендация: Исключим присоединенные файлы из основной выгрузки НСИ. Их лучше перенести отдельным этапом через Fast Infoset или просто скопировать файлы на уровне томов хранения (если используется хранение в томах на диске).
Проанализировав ситуацию, мы понимаем, что «железо» редко является единственной причиной тормозов. Для ускорения загрузки справочников из УПП в ERP выполним следующие действия:
Simple, быстрый диск под TempDB.Следуя этой методике, мы сможем сократить время загрузки с нескольких месяцев до нескольких дней, обеспечив стабильный переход предприятия на новую систему учета.