Почему зависают фоновые задания и как восстановить их выполнение в 1С

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

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

Анализ механизма проблемы и причин сбоя

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

ПараметрыПроцедуры = Новый Структура;
ПараметрыВыполнения = ДлительныеОперации.ПараметрыВыполненияВФоне(УникальныйИдентификатор);
ДлительнаяОперация = ДлительныеОперации.ЗапуститьФоновоеЗаданиеСКонтекстомКлиента(
    "МодульФоновыхЗаданий.ВыполнитьДействие",
    ПараметрыПроцедуры,
    ПараметрыВыполнения
);

При выполнении этого кода в сеансе пользователя менеджер кластера (rmngr) определяет рабочий сервер, который должен запустить процесс rphost для обработки фонового задания. Сбой и бесконечное зависание происходят по следующим причинам:

1. Падение или остановка службы ragent на назначенном рабочем сервере: Если в многосерверном кластере настроены Требования назначения функциональности (ТНФ) и сервис фоновых заданий жестко привязан к конкретной ноде, остановка службы на этой ноде приводит к тому, что менеджер пытается передать вызов на неработающий сервер. Фоновое задание не создается, а клиентский сеанс переходит в режим бесконечного ожидания ответа.
2. Исчерпание доступных процессов rphost или соединений: Когда все рабочие процессы перегружены или аварийно завершились из-за нехватки памяти (OOM / Access Violation), новые фоновые потоки блокируются до момента освобождения ресурсов.
3. Нехватка клиентских или серверных лицензий: При запуске фонового задания создается отдельный сеанс. Если серверный пул лицензий исчерпан или сервис лицензирования кластера недоступен, старт фонового потока завершается таймаутом.

Пошаговая диагностика сбоя фоновых заданий

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

1. Проверка состояния служб на всех серверах кластера: Проверим системные службы операционной системы (1C:Enterprise 8.3 Server Agent в Windows или srv1cv83 в Linux) на всех физических и виртуальных машинах, входящих в состав кластера. Убедимся, что на каждой ноде служба находится в статусе «Работает».
2. Проверка консоли администрирования кластера серверов: Откроем консоль кластера или воспользуемся утилитой rac. Перейдем в ветку «Рабочие серверы» и проверим доступность каждого сервера, а также актуальный статус рабочих процессов (rphost).
3. Анализ Требований назначения функциональности (ТНФ): Проверим ветку «Требования назначения функциональности» в свойствах кластера. Выясним, на какие рабочие серверы назначены сервисы фоновых заданий и сервисы баз данных. Если для сервиса задано жесткое правило «Назначить» на конкретный сервер без резервных серверов, сбой этого сервера полностью парализует выполнение всех асинхронных операций.
4. Анализ Технологического журнала (ТЖ): Настроим сбор технологического журнала для отслеживания системных событий кластера. Для поиска сетевых таймаутов и отказов между узлами используем события EXCP, EXCPCNTX, CLSTR, SESN и SCALL.

Устранение проблемы и настройка отказоустойчивости

Разберем по шагам, как устранить зависание и исключить подобные ситуации в будущем:

1. Перезапуск службы кластера на проблемной ноде: Запустим службу ragent на сервере, где произошел сбой. Если служба зависла, принудительно завершим связанные процессы rphost, rmngr и ragent через диспетчер задач или системный монитор процессов, после чего выполним чистый старт службы.
2. Корректировка правил ТНФ при аварии: Если упавший сервер временно недоступен или требует длительного обслуживания, перенастроим правила ТНФ в консоли кластера. Изменим правило для сервиса фоновых заданий на оставшийся рабочий сервер или временно переведем его в режим «Авто», после чего выполним команду «Применить требования назначения функциональности».
3. Настройка резервирования и отказоустойчивости: В многосерверных конфигурациях обязательно добавим резервные рабочие серверы в ТНФ с более низким приоритетом. Это позволит кластеру автоматически перенаправлять фоновые задания на рабочие узлы в случае выхода из строя основного сервера.
4. Настройка автоматического перезапуска рабочих процессов: В свойствах кластера серверов зададим параметры автоперезапуска процессов rphost: настроим интервал перезапуска (например, каждые 86400 секунд), ограничение по объему виртуальной памяти и порог времени неактивности, чтобы предотвратить накопление зависших потоков.

Временные обходные пути для клиентских операций

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

При вызове функций БСП передадим параметр, отключающий выполнение в фоне:

ПараметрыВыполнения = ДлительныеОперации.ПараметрыВыполненияВФоне(УникальныйИдентификатор);
ПараметрыВыполнения.ЗапуститьВФоне = Ложь;
ДлительнаяОперация = ДлительныеОперации.ЗапуститьФоновоеЗаданиеСКонтекстомКлиента(
    "ОтчетыСервер.СформироватьОтчет",
    ПараметрыОтчета,
    ПараметрыВыполнения
);

В этом случае операция выполнится синхронно в рамках текущего клиентского сеанса без обращения к сервису фоновых заданий кластера.