В практике поддержки информационных баз 1С мы нередко сталкиваемся с ситуацией, когда обмен данными, работавший как часы, внезапно перестает выполняться. Особенно сложными для диагностики являются случаи, когда процесс не выдает явных ошибок, а просто «зависает» или бесконечно выполняется, пока его принудительно не завершат. В этой статье мы подробно разберем ситуацию с зависанием синхронизации между «1С:Управление Торговлей» (УТ 11) и «1С:Бухгалтерия Предприятия» (БП 3), работающей через универсальный формат (EnterpriseData).
Мы проанализируем симптомы, пройдем путь диагностики от стандартных методов до анализа Технологического журнала и выясним, как некорректные данные могут "повесить" серверные процедуры.
Давайте рассмотрим исходные данные ситуации, с которой мы можем столкнуться. Синхронизация настроена через универсальный формат, обмен односторонний (из УТ в БП). Все работало по расписанию, но внезапно обмен перестал завершаться.
Характерные признаки, на которые нам стоит обратить внимание:
Такое поведение часто указывает не на проблему соединения или блокировки СУБД, а на зацикливание алгоритма внутри встроенного языка 1С.
В процессе поиска решения мы можем предположить несколько вариантов, включая регистрацию или удаление объектов из плана обмена вручную. Давайте разберем, что стоит проверить, но что может не являться истинной причиной:
Блокировки в консоли сервера. Мы можем увидеть блокировки транзакций. Однако, как показывает практика, они часто являются следствием, а не причиной. Если процесс висит часами, он, естественно, удерживает ресурсы, но снимать блокировки бессмысленно, если алгоритм продолжает крутиться в цикле.
Кэш и временные файлы. Стандартная процедура очистки кэша или смена каталога обмена (если обмен идет через файл) редко помогает в таких случаях, так как проблема кроется в самих данных или логике их обработки.
Когда отладчик не дает ясной картины (например, отладка фоновых заданий срывается или сложно поймать момент зависания), нашим главным инструментом становится Технологический журнал (ТЖ).
Чтобы понять, что происходит внутри платформы в момент зависания, нам необходимо настроить сбор логов. Нас интересуют события, связанные с выполнением встроенного языка и исключительными ситуациями.
В файле настройки logcfg.xml рекомендуется включить события:
EXCP — для отслеживания аварийных завершений процессов.PROC — для анализа длительности выполнения серверных вызовов (если лог будет слишком большим, можно включить фильтр по длительности).Анализируя логи ТЖ, мы можем обнаружить момент обрыва соединения. В рассматриваемом случае в логах можно увидеть сообщения вида «Сеанс отсутствует или удален» или «Сеанс завершен администратором», если процесс был убит системой по таймауту или вручную.
Но самое ценное — это стек вызовов (Context), который записывается в лог перед падением или при длительном выполнении. Именно там мы можем увидеть имя процедуры, на которой «застряла» 1С.
В нашем случае анализ показал, что выполнение застревает в общих модулях, отвечающих за обработку коллекций значений. Конкретная проблемная функция: УдалитьПовторяющиесяЭлементыМассива (или аналогичная по смыслу в зависимости от версии БСП).
Давайте посмотрим на логику работы подобных алгоритмов. Обычно они используются при подготовке данных к выгрузке или при загрузке, когда системе нужно собрать, например, всех родителей элемента номенклатуры для построения иерархии.
Проблема была обнаружена в следующем поведении: переменная, отвечающая за количество элементов в массиве для обработки, содержала огромные значения, и цикл удаления дублей работал бесконечно долго.
// Примерная логика проблемного места
Пока КоличествоЭлементов > 0 Цикл
// Логика перебора и удаления
КоличествоЭлементов = КоличествоЭлементов - 1;
КонецЦикла;
Но откуда взялось огромное количество элементов? Причиной оказалась циклическая ссылка в данных.
Циклическая ссылка — это нарушение логической целостности иерархического справочника. Представим ситуацию:
Или еще проще: Группа А является родителем самой себя.
Когда механизм обмена данными (EnterpriseData) пытается сериализовать объект (превратить его в XML), он часто пытается выгрузить всю цепочку родителей, чтобы на стороне приемника корректно разложить папки. Алгоритм работает рекурсивно или в цикле:
Родитель не станет пустым.Если у нас есть цикл (А -> А), условие выхода из цикла никогда не наступит. Массив родителей растет бесконечно (А, А, А, А...), пока не закончится оперативная память, или пока следующий шаг алгоритма (удаление дублей) не зависнет, пытаясь обработать миллионы записей.
Теперь, когда мы понимаем механизм проблемы, давайте разберем методы её устранения. Нам нужно найти «битую» номенклатуру или группу.
Самый надежный штатный метод. Запустите конфигуратор и выполните «Тестирование и исправление» (меню «Администрирование»).
Обязательно выберите пункт «Проверка логической целостности». Платформа 1С умеет определять зацикливание в иерархии справочников. При обнаружении такой ситуации она обычно разрывает цикл (например, очищает поле Родитель у проблемного элемента или переносит его в корень).
Если база большая и ТиИ выполнять долго, мы можем попытаться найти простые циклы запросом. Откройте консоль запросов и выполните проверку для справочника Номенклатуры (или Партнеров, Статей затрат — любого иерархического справочника).
ВЫБРАТЬ
Номенклатура.Ссылка КАК Ссылка,
Номенклатура.Родитель КАК Родитель
ИЗ
Справочник.Номенклатура КАК Номенклатура
ГДЕ
Номенклатура.Ссылка = Номенклатура.Родитель
Этот запрос покажет элементы, которые являются родителями сами себе. Для поиска более сложных циклов (А -> Б -> А) потребуются более сложные запросы с соединениями таблицы самой с собой или использование CTE (в прямых SQL запросах, что не рекомендуется), но чаще всего ошибка именно в ссылке на самого себя.
Если вы можете воспроизвести проблему в файловом варианте или подключиться отладчиком к серверному сеансу:
Чтобы избежать подобных ситуаций в будущем, обратите внимание на следующие моменты:
В заключение отметим: если синхронизация зависает без ошибок и загружает процессор, с вероятностью 99% — это алгоритмическая петля, вызванная некорректными данными. Ищите циклические ссылки.