← На главную

Рассмотрим распространенную и крайне неприятную ситуацию: при выгрузке или загрузке данных в 1С процесс «зависает» на начальном этапе (например, на 10%), после чего индикатор прогресса останавливается, а процесс 1cv8.exe продолжает активно использовать процессор и наращивать потребление оперативной памяти. Проанализируем причины такого поведения платформы и разберем проверенные способы восстановления штатной работы обмена.

Анализ причин зависания процесса обмена

Выясним, почему платформа может блокировать запись данных или входить в затяжную обработку большого пакета XML:

1. Большой размер единой транзакции. Если в настройках узла обмена параметр «Количество объектов в транзакции» равен нулю или имеет слишком высокое значение, платформа пытается записать весь массив изменений единым блоком. Это приводит к длительным блокировкам таблиц и колоссальному перерасходу памяти.
2. Ограничение 32-разрядного клиента. Разрядность процесса 1cv8.exe ограничена адресным пространством (порядка 2–3 ГБ). При чтении и создании объемного DOM-дерева XML-файла память исчерпывается, и процесс бесконечно перекладывает данные в файл подкачки.
3. Особенности распределенных информационных баз (РИБ). В РИБ зарегистрированные изменения документов и их движений тесно связаны. При попытке нештатно разбить файл или снять с регистрации часть объектов нарушается целостность учета.
4. Блокировки временных файлов и конфликты в файловом режиме. Антивирусное ПО или работа кассиров/пользователей во время фонового обмена в файловой базе может приводить к взаимным блокировкам таблиц информационного комплекса.

Способ 1. Изменение количества объектов в транзакции

Разберем самый эффективный штатный инструмент управления обменом — варьирование размера порции данных, записываемых в рамках одной транзакции.

По умолчанию в настройках обмена значение количества объектов в транзакции может быть установлено в 0 (что означает запись всех объектов в одной транзакции). Это вызывает пиковое потребление ресурсов. Чтобы изменить этот параметр, выполним следующие шаги:

1. Откроем перечень настроек обмена данными (узлы плана обмена).
2. Перейдем в настройки нужного узла или сценария обмена.
3. В поле «Количество объектов в транзакции» установим значение 1 или 100.
4. Сохраним настройки и повторим попытку обмена.

Установка значения, например, 100 позволяет достичь оптимального компромисса между параллельностью работы пользователей и целостностью данных. Если установить 1, каждый объект будет записываться и фиксироваться в базе отдельно. Это существенно снижает требования к объему оперативной памяти и предотвращает падение процесса при загрузке тяжелых файлов, хоть и может незначительно увеличить общее время передачи за счет частых транзакционных вызовов.

Почему нельзя просто отключить регистрацию части объектов в РИБ

В процессе поиска решения у некоторых разработчиков возникает идея вручную снять с регистрации часть изменений, выгрузить первую половину, а затем зарегистрировать остаток. Проанализируем, почему такой подход критически опасен для РИБ:

В распределенных информационных базах регистрация изменений документов и связанных с ними движений по регистрам выполняется автономно. Если выключить регистрацию для части объектов, возникнет рассинхронизация: документ может уйти в узел без своих движений, либо наоборот. В дальнейшем придётся вручную искать потерянные данные и писать вспомогательные обработки для восстановления структуры.

Именно поэтому корректнее управлять процессом через штатный механизм транзакций, не затрагивая таблицы регистрации изменений (ЗарегистрироватьИзменения).

Способ 2. Очистка кэша и работа под 64-разрядной платформой

Если настройка размера транзакции не сняла проблему целиком, разберем дополнительные технические шаги по оптимизации:

1. Переход на 64-разрядную платформу. Запуск сеанса обмена через 64-битный клиент 1С полностью снимает проблему нехватки адресов оперативной памяти при разборе больших XML-файлов.
2. Очистка временных каталогов. Перед выполнением обмена полностью очистим папку %TEMP%, а также кэш платформы 1С. Это исключит ошибки распаковки входящих ZIP-архивов.
3. Настройка исключений защитного ПО. Добавим каталог информационной базы и папку временных файлов в исключения антивирусного сканера.
4. Монопольный режим. Если база работает в файловом режиме (например, на кассовом узле), обмен рекомендуется запускать при завершенных сеансах пользователей и отключенных фоновых заданиях, чтобы избежать конфликта блокировок файлов 1Cv8.1cd.
5. Проверка целостности базы. Выполним автономное тестирование файла базы данных с помощью встроенной утилиты chdbfl.exe, находящейся в каталоге bin установленной платформы.