В процессе интеграции 1С с веб-сайтом (например, на платформе 1С-Битрикс) специалисты часто сталкиваются с ситуацией, когда регламентное или фоновое задание обмена неожиданно прерывается. Особенность этой проблемы заключается в том, что в Журнале регистрации 1С и Журнале событий Windows какие-либо ошибки отсутствуют, а сама задача может циклически перезапускаться через определенный интервал времени (например, каждые 20 минут).
Рассмотрим подробнее причины возникновения подобного сбоя, проанализируем механизмы работы платформы 1С и разберем по шагам, как диагностировать и полностью устранить данную проблему.
Проанализируем механику работы фоновых заданий в платформе 1С:Предприятие. Когда задание запускается по расписанию, оно выполняется в контексте рабочего процесса серверов 1С — rphost. Если в ходе исполнения кода происходит стандартная ошибка (например, деление на ноль или неверный тип данных), платформа перехватывает её и записывает подробную информацию в Журнал регистрации (ЖР).
Однако если рабочий процесс rphost завершается аварийно (происходит так называемый Process terminated или аварийное закрытие процесса операционной системой), исполняемый код 1С прекращает работу мгновенно. Платформа просто не успевает обработать исключение и записать событие в Журнал регистрации.
Планировщик фоновых заданий 1С фиксирует неожиданное исчезновение процесса и расценивает задание как незавершенное. По умолчанию платформа предпринимает повторную попытку запуска задачи через интервал повтора (обычно около 20 минут). Это и объясняет циклическое поведение системы.
Посмотрим, как гарантированно определить причину падения процесса. Единственным надежным инструментом диагностики на уровне платформы является Технологический журнал (ТЖ).
Для сбора информации о сбоях рабочих процессов настроим файл конфигурации logcfg.xml в каталоге шаблонов настроек технологического журнала. В конфигурацию необходимо включить отслеживание следующих событий:
Process terminated).Рассмотрим пример файла настройки logcfg.xml для фиксации аварийных завершений процессов:
<config xmlns="http://v8.1c.ru/v8/tech-log">
<log location="C:\LOGS\rphost_crash" history="48">
<event>
<eq property="name" value="EXCP"/>
</event>
<event>
<eq property="name" value="PROC"/>
</event>
<property name="all"/>
</log>
</config>
При анализе собранного технологического журнала обратите внимание на следующие ключевые записи:
Удаленный хост принудительно разорвал существующее подключение (ошибка сокета 10054). Это говорит о том, что соединение между 1С и веб-сервером было разорвано внешней стороной или сетевым оборудованием.Process terminated. Stopped on error указывает на то, что рабочий процесс rphost упал из-за необработанного системного сбоя или превышения лимитов памяти.Проанализируем наиболее частые технические факторы, приводящие к обрыву фонового задания обмена с сайтом:
Критический объем памяти процессов и Временно допустимый объем памяти процессов. Если процедура обмена выгружает в оперативную память массивный объем данных, процесс rphost пересекает установленный порог. Платформа 1С в целях защиты сервера принудительно завершает данный процесс.Интервал перезапуска (группа Перезапускать рабочие процессы). Если администраторы установили ненулевое значение данного параметра (например, 1000–2000 секунд), рабочий процесс будет завершаться строго по таймеру, обрывая все длительные фоновые задания без записи ошибок в ЖР.php.ini. Таймауты proxy_read_timeout, fastcgi_read_timeout и параметр max_execution_time при превышении лимита времени принудительно обрывают соединение со стороны сайта.Разберем по шагам действия, необходимые для устранения аварийных сбросов фонового задания.
Откройте консоль администрирования кластера серверов 1С. Перейдите в свойства кластера и проверьте следующие параметры:
0 (чтобы отключить принудительный плановый перезапуск процессов).Перейдите в настройки узла обмена с сайтом в 1С. Уменьшите количество товаров или документов в одном пакете (например, с 5000 до 500 элементов). Это позволит 1С отправлять данные на сайт небольшими порциями, не перегружая оперативную память процесса rphost и избегая длительного «жидания» сокета.
В конфигурационных файлах Nginx на сервере сайта увеличьте значение таймаутов ожидания ответа от скриптов:
proxy_read_timeout 600;
proxy_connect_timeout 600;
fastcgi_read_timeout 600;
В файле php.ini увеличим максимальное время выполнения скрипта: max_execution_time = 600.
Чтобы промежуточное сетевое оборудование (активные маршрутизаторы, файрволы) не закрывало неактивные TCP-сессии во время длительного формирования файла выгрузки, настроим отправку пакетов проверки связи на уровне ОС Windows Server.
В реестре Windows по адресу HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters установим/создадим параметры DWORD:
KeepAliveTime — интервал в миллисекундах перед первой отправкой Keep-Alive пакета (например, 300000 = 5 минут).KeepAliveInterval — интервал между повторными пакетами при отсутствии ответа.Для предотвращения влияния падения процесса обмена на работу пользователей выделим для фоновых заданий отдельный рабочий процесс rphost. Для этого в консоли кластера 1С создадим требование назначения функционала для объекта Фоновые задания, зафиксировав его за отдельным процессом или сервером.
Последовательное выполнение указанных шагов и предварительная диагностика через Технологический журнал позволяют выявить узкое место интеграции и обеспечить стабильную работу ночного обмена данными с сайтом.