При переносе данных и переходе с конфигурации 1С:Управление торговлей 10.3 на 1С:Управление торговлей 11 специалисты нередко сталкиваются с ситуацией, когда стандартная загрузка через XML-файл зависает или выполняется десятки часов. Особенно остро эта проблема проявляется на базах с обширным каталогом номенклатуры — от 100 000 до 300 000 позиций, с характеристиками, свойствами и дополнительными реквизитами. Разберем основные причины крайне медленной загрузки объектов и подробно рассмотрим комплекс мер по оптимизации процесса.
1. Аппаратные ограничения и среда выполнения
Выполнение массивной загрузки на рабочем ноутбуке или слабом ПК с медленным жестким диском (5400 RPM) — одна из главных причин падения скорости до 1–2 объектов в секунду. Проанализируем, как подготовить окружение:
Перенос процесса на производительный сервер: Загрузку сотен тысяч объектов следует производить на серверном оборудовании или мощной рабочей станции с быстрыми накопителями NVMe/SSD.
Использование 64-разрядного клиента: Чтение единого тяжелого XML-файла (размером от 500 МБ и выше) в 32-разрядном клиенте 1С быстро исчерпывает адресное пространство памяти (лимит около 2–4 ГБ), что приводит к критическому замедлению из-за своппинга или аварийному завершению работы с ошибкой нехватки памяти.
Исключения антивируса и RAM-диск: Для файловых баз (.1CD) необходимо добавить каталог базы данных и системную папку временных файлов в исключения антивирусного монитора либо временно развернуть файловую базу на виртуальном диске в оперативной памяти (RAM-диске).
2. Отключение фоновых и служебных механизмов в базе-приемнике
В типовой конфигурации УТ 11 по умолчанию активировано множество подсистем, которые перехватывают запись каждого объекта и создают колоссальную нагрузку. Перед началом загрузки выполним обязательную подготовительную настройку базы-приемника:
Блокировка регламентных заданий: Отключим выполнение всех регламентных и фоновых заданий через консоль администрирования или параметры запуска базы, чтобы исключить конкурентную нагрузку на таблицы.
Отключение версионирования объектов: Если в базе включена подсистема версионирования (хранения истории изменений), платформа при создании каждой позиции номенклатуры и характеристик будет дополнительно генерировать и записывать полные снимки версий. Полностью выключим версионирование на время загрузки.
Отключение полнотекстового поиска: Постоянное обновление очереди индексации полнотекстового поиска при непрерывной вставке сотен тысяч записей блокирует таблицы. Отключим полнотекстовый поиск данных и очистим его индекс.
Минимизация журнала регистрации: Запись каждого события создания объекта в журнал регистрации перегружает дисковую подсистему. Установим уровень детализации журнала регистрации на «Только ошибки» или временно отключим его ведение.
Отключение регистрации изменений на узлах обмена: Если база включена в планы обмена (РИБ, синхронизация с бухгалтерией), перед загрузкой следует отключить авторегистрацию изменений, чтобы избежать разрастания таблиц регистрации.
Отключение динамической сегментации: В настройках номенклатуры отключим автоматический расчет динамических сегментов, чтобы система не выполняла ресурсоемкие запросы при записи каждого элемента.
3. Настройка параметров универсальной загрузки данных
При использовании обработки Универсальный обмен данными в формате XML стандартные параметры не рассчитаны на пакетную загрузку сотен тысяч записей без предварительной настройки. Разберем по шагам ключевые параметры:
Размер транзакции: По умолчанию каждый объект может записываться в отдельной транзакции, что создает огромные накладные расходы на дисковые операции и блокировки. Установим параметр Количество объектов в транзакции равным от 500 до 1000.
Режим загрузки данных: Убедимся, что загрузка выполняется в режиме обмена данными. Это обеспечивает установку свойства ОбменДанными.Загрузка = Истина, что отключает прикладные проверки в модулях объектов.
Индексация полей поиска: Если в правилах конвертации сопоставление номенклатуры выполняется по реквизитам Артикул, Наименование или дополнительным реквизитам, эти поля обязательно должны быть проиндексированы в метаданных. Поиск по неиндексированному полю в таблице на 200 000 записей выполняет полное сканирование всей таблицы для каждого входящего объекта, из-за чего скорость загрузки падает в геометрической прогрессии.
Загрузка под полными правами без RLS: Загрузку необходимо запускать исключительно под учетной записью с административными правами, у которой отключены ограничения доступа на уровне записей (RLS).
4. Оптимизация программного кода при загрузке
Посмотрим на пример правильной обработки события перед записью объектов в модулях конфигурации или обработчиках правил обмена. Проверим, чтобы типовые алгоритмы не выполняли избыточных действий:
Процедура ПередЗаписью(Отказ)
Если ОбменДанными.Загрузка Тогда
Возврат;
КонецЕсли;
// Вторичные проверки и расчеты выполняются только при интерактивной работе
СформироватьРабочееНаименование();
КонецПроцедуры
Для переноса экстремально больших массивов номенклатуры (более 200 000 позиций) наиболее эффективным подходом является отказ от единого тяжелого XML-файла в пользу выгрузки данных частями по группам справочника либо использование прямого программного переноса через COM-соединение или промежуточный формат JSON с пакетной записью в транзакциях.