Почему долго запускается 1С через COM-соединение и как это исправить

← На главную

Проблема резкого замедления работы COM-соединения (COM-объекта V83.COMConnector) — это классическая ситуация, с которой сталкиваются разработчики при поддержке распределенных систем. Особенно часто это проявляется в связке, когда основная информационная база работает на SQL-сервере, а база-приемник является файловой. Ситуация, когда процесс, занимавший 15 секунд, внезапно начинает длиться 10 минут, требует комплексного анализа как программного кода, так и серверного окружения.

В этой статье мы подробно разберем причины такого поведения, проанализируем методы диагностики и определим шаги по оптимизации системы. Если медленная работа COM-соединения затрудняет сверку данных после переноса, вы можете автоматически сравнить бухгалтерские и налоговые проводки между базами 1С для быстрого поиска возможных расхождений.

Анализ кода инициализации соединения

Прежде всего, рассмотрим типовой код, который используется для создания подключения. Проанализируем пример, представленный в обсуждении:


Попытка
    ОбработкаЗагрузкиДвДанные.Записать(ИмяОбработки);
    Коннектор = Новый COMObject("V83.COMConnector"); 
    Если ЗначениеЗаполнено(ПараметрыПодключения.ИмяСервера) и ЗначениеЗаполнено(ПараметрыПодключения.ИмяБазы) Тогда
        Соединение = Коннектор.Connect("Srvr='"+ПараметрыПодключения.ИмяСервера+"';Ref='"+ПараметрыПодключения.ИмяБазы+"';Usr='"+ПараметрыПодключения.ИмяПользователя+"';Pwd='"+ПараметрыПодключения.Пароль+"'");            
    Иначе    
        Соединение = Коннектор.Connect("File='"+ПараметрыПодключения.ПутьКБазе+"';Usr='"+ПараметрыПодключения.ИмяПользователя+"';Pwd='"+ПараметрыПодключения.Пароль+"'");            
    КонецЕсли;    
    ОбработкаЗагрузки = Соединение.ВнешниеОбработки.Создать(ИмяОбработки,Ложь);
Исключение
    // Обработка ошибки
КонецПопытки;

В данном фрагменте кода критическим местом является метод Connect(). Именно на этом этапе происходит инициализация полнотекстового поиска, проверка лицензий, загрузка конфигурации и запуск фоновых процессов в подключаемой базе. Если обработка данных занимает секунды, а общее время выполнения измеряется минутами, значит, «тормоза» происходят именно внутри процесса инициализации сеанса.

Диагностика: где именно теряется время?

Чтобы понять, в каком направлении двигаться, нам необходимо внедрить замеры времени. Разберем, как это сделать правильно, чтобы предоставить аргументы системным администраторам:

Замер этапа создания объекта: Проверим, как быстро создается сам COMObject.
Замер этапа авторизации: Сколько времени уходит на метод Connect().
Замер этапа загрузки обработки: Сколько времени занимает ВнешниеОбработки.Создать.

Проанализируем ситуацию с помощью простого логирования:


НачалоЭтапа = ТекущаяДата();
Коннектор = Новый COMObject("V83.COMConnector");
ЗаписьЖурналаРегистрации("COM.Тайминг", УровеньЖурналаРегистрации.Информационный, , , "Создание коннектора: " + (ТекущаяДата() - НачалоЭтапа) + " сек.");

НачалоЭтапа = ТекущаяДата();
Соединение = Коннектор.Connect(СтрокаПодключения);
ЗаписьЖурналаРегистрации("COM.Тайминг", УровеньЖурналаРегистрации.Информационный, , , "Установка соединения: " + (ТекущаяДата() - НачалоЭтапа) + " сек.");

Если Журнал регистрации показывает, что «Установка соединения» длится сотни секунд, проблему нужно искать в настройках Windows и платформы 1С.

Причина 1: Проверка лицензий и поиск HASP

При создании V83.COMConnector система пытается найти свободную лицензию. Если на сервере не настроен файл nnhasp.ini, клиент 1С (в данном случае COM-соединение) начинает опрашивать всю сеть широковещательными запросами UDP по порту 475. В сложной сетевой инфраструктуре это может приводить к длительным ожиданиям (тайм-аутам) перед тем, как лицензия будет найдена или выдана сервером лицензирования.

Что сделать: Убедитесь, что в папке conf (на сервере, где исполняется код) лежит настроенный nnhasp.ini с явно указанным IP-адресом менеджера лицензий. Также проверьте, не включена ли опция поиска программных лицензий в интернете, если сервер не имеет к нему доступа.

Причина 2: Разрастание кэша пользователя службы

COM-соединение запускается от имени пользователя, под которым работает служба 1C:Enterprise Server (обычно это USR1CV8). У этого пользователя в профиле Windows (%AppData%\Local\1C\1Cv8) со временем скапливаются тысячи временных файлов и папок кэша конфигураций. При каждом новом COM-подключении система сканирует эти папки.

Решение: Попросите системных администраторов очистить кэш для учетной записи, под которой запущена служба rphost. Это стандартная процедура «оздоровления» сервера 1С.

Причина 3: Защита от опасных действий

В современных версиях платформы (8.3.9 и выше) реализован механизм защиты. При запуске внешних обработок через COM-соединение система может попытаться вывести невидимое диалоговое окно с вопросом: «Разрешить выполнение опасного действия?». Поскольку в COM-соединении нет интерфейса, процесс будет висеть до тех пор, пока не сработает внутренний тайм-аут платформы. Если COM-соединение используется для постоянной синхронизации, процесс можно перевести на работу по расписанию. Это позволит автоматизировать регулярный обмен данными между базами 1С без необходимости изменять конфигурации.

Как исправить: В параметрах пользователя (в базе-приемнике), под которым происходит подключение, необходимо снять галочку «Защита от опасных действий». Либо добавить в строку подключения параметр DisableSafeMode=True.


// Пример модифицированной строки подключения для файловой базы
СтрокаПодключения = "File='" + Путь + "';Usr='" + Логин + "';Pwd='" + Пароль + "';DisableSafeMode=True;";

Причина 4: Проблемы с SMB и сетевыми блокировками

Если файловая база расположена на другом сервере, доступ к ней осуществляется по протоколу SMB. Настройки Opportunistic Locking (Oplocks) в Windows могут приводить к тому, что один процесс блокирует файл 1Cv8.1CD на длительное время, а COM-соединение ожидает снятия этой блокировки. Также антивирусы на сервере часто начинают сканировать файл базы данных именно в моменты активного обращения к нему через COM.

Рекомендация: Добавьте расширение .1CD, .1CL и папки с временными файлами 1С в исключения антивируса на обоих серверах.

Переход на HTTP-сервисы как радикальное решение

Рассмотрим совет из сообщения №8 форума: «Переходи на http сервисы». Почему это важно? COM-соединение считается устаревшим (legacy) механизмом. Оно привязано к ОС Windows, требует регистрации DLL, чувствительно к разрядности процесса (32/64 bit) и крайне тяжело отлаживается на сервере.

Преимущества HTTP-сервисов:

Скорость: Сеанс HTTP-сервиса взлетает практически мгновенно, так как не требует инициализации полноценного «тяжелого» соединения.
Кроссплатформенность: Работает на Linux без Wine.
Стабильность: Не зависят от регистрации библиотек в реестре Windows.

Разберем пример того, как мог бы выглядеть вызов вместо COM-соединения:


// На стороне базы-приемника создаем HTTP-сервис с методом POST
// На стороне базы-отправителя вызываем его:
НТТРЗапрос = Новый HTTPЗапрос("/hs/Exchange/LoadData");
НТТРЗапрос.УстановитьТелоИзСтроки(ДанныеДляЗагрузки);
Соединение = Новый HTTPСоединение(СерверПриемник, , Логин, Пароль);
Ответ = Соединение.ОтправитьДляОбъекта(НТТРЗапрос);

Итоги и план действий

Проанализировав ситуацию, мы видим, что «тормоза» в 10 минут — это не норма. Чтобы исправить ситуацию, выполните следующие шаги:

Проведите замеры времени в коде, чтобы точно знать, какой метод «зависает».
Проверьте Журнал регистрации в файловой базе: если там есть запись о начале сеанса, а код начал выполняться через 9 минут — проблема в инициализации (лицензии, кэш).
Очистите серверный кэш пользователя USR1CV8.
Отключите защиту от опасных действий для пользователя обмена.
Обсудите с администраторами возможность публикации файловой базы на веб-сервере (Apache или IIS) для перехода на HTTP-сервисы.

Помните, что использование V83.COMConnector в современных реалиях платформы 8.3.20 и выше требует идеальной настройки окружения. В большинстве случаев переход на веб-технологии решает проблемы производительности раз и навсегда.