Синхронизация данных между конфигурациями «Управление торговлей» (УТ 11) и «Бухгалтерия предприятия» (БП 3) — одна из самых частых и одновременно проблемных задач в экосистеме 1С. Когда объемы базы данных растут, стандартный обмен через универсальный формат EnterpriseData начинает давать сбои. Пользователи сталкиваются с тем, что файлы выгрузки размером более 100–150 МБ вызывают ошибку «Фоновый процесс завершился аварийно», а сам процесс выгрузки затягивается на долгие часы.
В этой статье мы подробно проанализируем причины этой проблемы, разберем поведение платформы 1С под нагрузкой и рассмотрим практические шаги по оптимизации обмена, которые помогут вам стабилизировать систему.
Для начала выясним причину, почему классический обмен по технологии EnterpriseData потребляет так много ресурсов и регулярно завершается аварийно. В отличие от старой технологии «Конвертации данных 2.0» (КД 2), которая использовала последовательное XML-чтение и запись (SAX-подобный метод), современный формат обмена базируется на механизме XDTO.
При использовании XDTO платформа 1С строит в оперативной памяти **полное дерево объектов** (DOM-модель). Если на диске файл обмена занимает 150 МБ, то в оперативной памяти сервера для его десериализации может потребоваться в **10–20 раз больше места** — до 2–3 ГБ на один рабочий сеанс. Это приводит к следующим системным проблемам:
Самый очевидный и рекомендуемый способ снизить нагрузку на сервер — уйти от ежемесячных или еженедельных выгрузок. Разберем, как реализовать этот подход на практике.
Многие компании отказываются от частого обмена из-за постоянных корректировок документов «задним числом». Однако частый обмен (например, каждые 10-15 минут или раз в день) не увеличивает итоговый объем передаваемых данных в долгосрочной перспективе. Напротив, он распределяет нагрузку равномерно.
Настроим расписание регламентного задания для синхронизации данных:
При такой схеме объем одной транзакции уменьшается в десятки раз. Вместо выгрузки 10 000 документов за один раз система будет передавать по 50–100 документов, с чем платформа 1С справляется за считанные секунды.
Если специфика учета категорически требует производить обмен редко, необходимо настроить порционную выгрузку данных в рамках одной сессии. Для этого используется ограничение размера пакета в планах обмена.
Проанализируем, как ограничить количество объектов в одном файле. В правилах отправки данных для узла плана обмена можно переопределить стандартный лимит выгружаемых объектов. Рассмотрим пример кода, который можно интегрировать в обработчики выгрузки для жесткого разделения данных на пакеты:
// Пример ограничения количества выгружаемых объектов в одной транзакции
ПараметрыВыгрузки = Новый Структура;
ПараметрыВыгрузки.Вставить("МаксимальноеКоличествоОбъектовВПакете", 500);
// Платформа автоматически разобьет весь массив зарегистрированных изменений
// на несколько файлов, отправляя их последовательно по квитанциям обмена.
При такой настройке база-отправитель выгрузит первые 500 документов, дождется от базы-приемника подтверждения успешного приема (квитанции) и только после этого снимет регистрацию и начнет выгрузку следующей порции. Это полностью исключит переполнение оперативной памяти на стороне сервера приемника.
По умолчанию при загрузке данных через EnterpriseData конфигурация БП 3 пытается провести загружаемые документы сразу в процессе чтения файла. Это колоссальная нагрузка на СУБД и оперативную память.
Рекомендуется отключить автоматическое проведение документов при загрузке. Выясним, как это сделать:
ГрупповоеПерепроведениеДокументов в БП 3 на выполнение в ночное время, когда пользователи не работают в базе данных.Как справедливо заметили участники обсуждения на форуме, старая добрая технология Конвертации данных 2.0 работает в разы быстрее на монолитных больших объемах выгрузки. Если выгрузка через EnterpriseData занимает 6 часов, то правила КД 2.0 могут обработать этот же объем за 15–20 минут за счет потокового формирования XML без развертывания тяжелых XDTO-объектов в памяти.
Рассмотрим порядок перехода на КД 2.0 для «тяжелых» документов:
РеализацияТоваровУслуг).УниверсальныйОбменДаннымиXML.Важное предостережение: использование КД 2.0 требует регулярной поддержки правил при обновлениях релизов конфигураций УТ 11 и БП 3. Используйте этот метод только для критически нагруженных объектов метаданных, оставив справочники и мелкие документы на типовом обмене.
Если вы хотите оставить типовой обмен EnterpriseData, но сделать его стабильным, необходимо скорректировать настройки кластера серверов 1С:
rphost.exe до 10–15. Это позволит локализовать падение процесса. Если один из процессов упадет от нехватки памяти при обмене, это не затронет сессии других пользователей.comcntr.dll. Запуск обмена через 32-битный COM-коннектор на 64-битных серверах — одна из самых частых скрытых причин падения фоновых заданий.Проанализировав все способы, мы видим, что проблема стабильности обмена крупными объемами данных решается комплексным подходом: увеличением частоты сеансов синхронизации, переводом проведения документов в асинхронный фоновый режим и тонкой настройкой рабочих процессов сервера 1С.