При работе с распределенными информационными базами (РИБ) многие администраторы и разработчики сталкиваются с неприятной ситуацией: после штатного обновления конфигурации в центральном узле (ЦУ) первый же файл обмена для периферийных узлов (ПУ) вырастает до огромных размеров (от 600 МБ до 1 ГБ и выше). Если торговые точки подключены через узкие каналы связи, такая выгрузка может «положить» сеть или просто никогда не дойти до адресата из-за обрывов соединения.
В этой статье мы подробно проанализируем, почему это происходит, разберем внутренние механизмы платформы 1С:Предприятие 8.3 и рассмотрим несколько способов решения этой проблемы: от организационных до глубоко технических.
Рассмотрим первопричину. Многие ошибочно полагают, что в файл обмена попадает только разница (дельта) в программном коде или новые реквизиты. Однако это не совсем так. Основной объем файла обмена при обновлении занимает конфигурация поставщика.
Проанализируем ситуацию подробнее: современная типовая конфигурация (например, «1С:Розница» или «1С:Управление торговлей») — это сложный объект. Когда вы выполняете «Обновление конфигурации» через поддержку, платформа обновляет не только основную конфигурацию базы данных, но и внутреннее хранилище конфигурации поставщика (файл .cf внутри базы). При первой синхронизации после обновления система помечает объект «Конфигурация» как измененный. Поскольку метаданные в РИБ передаются крупными блоками, платформа зачастую включает в пакет обмена практически всё содержимое конфигурации поставщика, чтобы гарантировать идентичность узлов.
Ситуация осложняется тем, что пока периферийный узел не загрузит этот файл и не пришлет в ответ сообщение с подтверждением (номер принятого сообщения), центральный узел будет продолжать пытаться отправить эти данные в каждом следующем файле обмена. Выясним, как с этим бороться.
Первое, что мы должны проверить, — это факт получения ответа от периферийного узла. Как было замечено в обсуждении, если ответ не пришел, ЦУ будет «пихать» конфигурацию в каждый пакет.
Если канал связи настолько слаб, что передача 600-900 МБ через стандартный механизм 1С невозможна, мы можем применить метод «ручного» обновления метаданных. Разберем этот процесс по шагам:
Шаг 1. В центральном узле выгрузим конфигурацию в файл (Конфигурация — Сохранить конфигурацию в файл...). Получим файл 1cv8.cf.
Шаг 2. Снимем ограничение РИБ на периферийном узле. Для этого в коде или через специальную обработку выполним команду:
ПланыОбмена.УстановитьГлавныйУзел(Неопределено);
Шаг 3. Теперь, когда база «отвязана», откроем ее в режиме Конфигуратора и выполним «Загрузить конфигурацию из файла», выбрав наш 1cv8.cf. Внимание: используйте именно «Загрузить», а не «Сравнить/Объединить», чтобы обеспечить полную идентичность.
Шаг 4. Обновим конфигурацию базы данных (F7).
Шаг 5. Снова установим связь с главным узлом:
УзелОбъекта = ПланыОбмена.Розница.НайтиПоКоду("ЦУ"); // Код центрального узла
ПланыОбмена.УстановитьГлавныйУзел(УзелОбъекта);
После этих действий конфигурации станут идентичными. При следующем обмене данными система поймет, что метаданные обновлять не нужно, и передаст только измененные документы и справочники.
Рассмотрим более радикальный метод, который упоминался как «создание рабочей конфы на своей поставке». Суть заключается в том, что огромный объем занимает именно типовая конфигурация поставщика от 1С.
Если полностью снять базу с поддержки, файл обмена может уменьшиться в несколько раз. Однако это лишит вас возможности автоматического обновления в будущем. Проанализируем компромиссный вариант:
Стандартный механизм сжатия в 1С использует формат .zip, который не всегда эффективен для огромных XML-структур метаданных. Посмотрим, как можно оптимизировать передачу трафика сторонними средствами:
.xml (без автоматического архивирования средствами платформы).7-Zip с алгоритмом LZMA2 или Zstandard).Практика показывает, что 7-Zip может сжать XML-файл конфигурации гораздо сильнее, чем встроенный Zip-движок 1С, что может сократить объем передаваемых данных на 20-30% дополнительно.
Иногда проблема кроется не только в метаданных. Выясним, не спровоцировало ли обновление массовое изменение данных. Часто в новых релизах запускаются обработчики обновления, которые пересчитывают остатки, заполняют новые реквизиты во всех документах или перезаписывают справочники.
Чтобы проверить это, воспользуемся стандартной обработкой «Регистрация изменений для обмена»:
Резюмируем: Основная причина гигантских файлов — конфигурация поставщика и особенности механизма РИБ в платформе 8.3. Самым надежным способом для очень плохих каналов связи остается «ручной занос» файла конфигурации на точку и временное снятие признака главного узла для загрузки .cf. В долгосрочной перспективе единственным системным решением является расширение каналов связи или переход на работу через тонкий клиент/терминальный сервер, где обмен данными как таковой отсутствует.