Как диагностировать и исправить аварийные завершения 1С:Предприятие 8.3 при работе с веб-сервисами и COM-объектами?

Аварийное завершение работы серверных процессов 1С — одна из самых сложных проблем для системного администратора и разработчика. Особенно критично это проявляется в клиент-серверном режиме, когда из-за падения одного процесса rphost прерываются сеансы сразу у десятков или сотен пользователей. В этой статье мы подробно разберем ситуацию, когда после обновления платформы (в частности, на ветку 8.3.17) начинаются массовые «вылеты», связанные с работой регламентных заданий, веб-сервисов и COM-соединений.

Анализ причин нестабильности платформы 8.3.17

Прежде всего, проанализируем ситуацию: падения начались после перехода на версию 8.3.17.1549. Ветка 8.3.17 известна существенными изменениями в механизмах управления памятью и взаимодействия с внешними компонентами. Зачастую в этой версии возникают ошибки типа Access Violation при интенсивной обработке XML через веб-сервисы или при использовании wsProxy.

Когда регламентное задание в УТ 11 обращается к внешней базе через ADODB.Connection, это задействует механизмы COM. Если в коде или в самой платформе происходит утечка памяти или некорректная очистка объектов, рабочий процесс сервера 1С может завершиться аварийно. Поскольку в стандартных настройках кластера на одном процессе rphost могут висеть сеансы многих пользователей, падение «фонового» задания тянет за собой всех остальных.

Настройка Технологического журнала для поиска ошибки

Выясним точную причину падения. Гадать на «кофейной гуще» в таких случаях неэффективно, поэтому первым делом мы должны настроить Технологический журнал (ТЖ). Это единственный надежный способ увидеть, какой именно программный модуль или системное событие предшествовало краху.

Для этого нам понадобится создать файл logcfg.xml в каталоге conf сервера 1С. Разберем пример минимальной конфигурации, которая позволит отловить исключительные ситуации и завершение процессов:

<config xmlns="http://v8.1c.ru/7.4/8.1/config/logcfg">
  <log location="C:\LOGS\1C_EXCP" history="24">
    <event>
      <eq property="Name" value="EXCP"/>
    </event>
    <event>
      <eq property="Name" value="PROC"/>
    </event>
    <property name="all"/>
  </log>
</config>

В данном примере мы собираем события EXCP (исключения) и PROC (запуск и остановка процессов). Рассмотрим подробнее, на что обратить внимание в логах:

• Событие PROC: Ищите записи с аномальным завершением процесса непосредственно перед временем вылета пользователей.
• Событие EXCP: Изучите контекст ошибки. Если в логах фигурируют записи о Memory allocation error или проблемы с драйверами OLE DB, это подтверждает проблему с COM-соединениями.

Изоляция проблемных сеансов в кластере 1С

Чтобы падение одного регламентного задания не приводило к вылету всех пользователей УТ 11 и УПП, проанализируем настройки кластера 1С. Мы можем ограничить влияние сбоев с помощью параметров рабочего сервера.

Рассмотрим шаги по настройке в консоли администрирования:

1. Откройте свойства рабочего сервера в консоли кластера.
2. Установите параметр "Количество соединений на один процесс" в небольшое значение (например, от 10 до 25). По умолчанию там может стоять 128 или более.
3. Установите "Предел объема памяти" для процессов rphost. Это заставит платформу перезапускать «протекшие» процессы до того, как они вызовут критическую ошибку ОС.

Такая настройка гарантирует, что если ADODB.Connection вызовет фатальную ошибку, пострадают только те 10-25 пользователей, которые работали в том же процессе, что и регламентное задание, а не вся компания.

Проблемы при работе с COM-объектами и XML

При обмене информацией между УТ и УПП через wsProxy передается текст XML. В платформе 8.3.17 при десериализации больших объемов данных могут возникать ошибки переполнения стека или повреждения кучи. Посмотрим на типичный сценарий работы через веб-сервис:

// Пример вызова веб-сервиса
Определение = Новый WSОпределения(URL, Логин, Пароль);
Прокси = Новый WSПрокси(Определение, URI, НазваниеСервиса, НазваниеПорта);
Результат = Прокси.ОбработатьДанные(ТекстXML);

Если ошибка происходит внутри функции ОбработатьДанные на стороне сервера, крайне важно убедиться, что все созданные объекты ЧтениеXML и ЗаписьXML закрываются явным образом.

Что касается ADODB.Connection, разберем важный нюанс: если ваш сервер 1С имеет 64-битную архитектуру, а используемые драйверы ODBC/OLE DB — 32-битные, работа через COM будет крайне нестабильной. Проанализируем код регламентного задания. Обязательно используйте конструкцию Попытка...Исключение и всегда закрывайте соединение:

Соединение = Новый COMОбъект("ADODB.Connection");
Попытка
    Соединение.Open(СтрокаПодключения);
    // Выполнение операций с БД
Исключение
    ЗаписьЖурналаРегистрации("Ошибка ADO", УровеньЖурналаРегистрации.Ошибка,,, ОписаниеОшибки());
КонецПопытки;

Если Соединение.State <> 0 Тогда
    Соединение.Close();
КонецЕсли;

Рекомендации по выбору стабильной платформы

Если диагностика через Технологический журнал подтверждает, что ошибка происходит внутри исполняемого файла платформы (например, в core83.dll), а не в программном коде, следует рассмотреть вопрос смены релиза.

Как отмечают эксперты, ветка 8.3.17 может быть нестабильной для определенных конфигураций. Рассмотрим альтернативы:

• Откат на 8.3.16: Если режим совместимости конфигурации УТ 11 позволяет (например, требуется версия не ниже 8.3.14), переход на стабильный релиз ветки 8.3.16 (например, 8.3.16.1659) часто решает проблему «вылетов».
• Обновление до 8.3.18 или выше: В более новых ветках многие ошибки взаимодействия с COM и обработки XML, характерные для 8.3.17, уже исправлены.

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

Дополнительные сервисные операции

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

1. Очистка индекса полнотекстового поиска: В некоторых случаях повреждение индекса FTS приводит к падению rphost при попытке обращения к нему.
2. Тестирование и исправление (ТИИ): Запустите проверку логической и ссылочной целостности, а также реиндексацию таблиц базы данных.
3. Очистка кэша сервера 1С: Удалите содержимое папки snccntx и кэш рабочих процессов в каталоге данных сервера (srvinfo), предварительно остановив службу 1C:Enterprise Server.

Выяснив причину через ТЖ и изолировав процессы в кластере, вы сможете добиться стабильной работы системы даже при наличии специфических ошибок в коде обмена или платформе.