При администрировании крупных и нагруженных баз данных на платформе «1С:Предприятие 8.3» специалисты часто сталкиваются со специфическим поведением кластера рабочих процессов. Одна из наиболее трудноуловимых и неприятных проблем — внезапное падение фоновых заданий с ошибкой «Аварийно завершился рабочий процесс фонового задания», когда в технологическом журнале фиксируются события с пометкой rphost disabled.
В этой статье мы подробно разберем, почему возникает данная проблема, рассмотрим внутренние механизмы распределения нагрузки в кластере 1С, проанализируем состояние гонки (Race Condition), опровергнем некоторые распространенные заблуждения с форумов и предложим надежные системные решения для стабилизации работы сервера.
Для начала проанализируем исходную ситуацию. В настройках кластера установлены жесткие параметры:
При такой конфигурации, как только число активных сессий (включая фоновые задания) превышает 15, менеджер кластера rmngr мгновенно инициирует запуск нового рабочего процесса rphost. Когда нагрузка спадает и количество соединений опускается ниже установленного порога, «лишний» рабочий процесс переводится в статус «Выключен» (disabled).
В этот переходный момент и кроется главная техническая проблема. Процесс в статусе «Выключен» больше не должен принимать новые соединения, но обязан дать уже существующим сеансам корректно завершить свою работу. Однако на практике происходит сбой маршрутизации.
Давайте разберем по шагам, что происходит в кластере при высокой интенсивности запуска фоновых задач:
disabled.В Сообщении №5 на форуме утверждается, что изменение таймаута завершения процессов не решает проблему, так как новые соединения к выключенному процессу все равно не создаются. Это утверждение ошибочно.
В настройках кластера 1С есть критически важный параметр — «Выключенные процессы останавливать через» (в современных релизах платформы он называется «Проблемные процессы останавливать через»). Если этот таймаут установлен в слишком маленькое значение (например, менее 60–120 секунд), происходят следующие негативные последствия:
rphost принудительно «убивается» операционной системой до того, как выполняющиеся на нем долгие фоновые задания успеют штатно завершить работу.Решение: Установите этот параметр в значение, заведомо превышающее время выполнения самого длительного фонового задания в вашей системе (например, 1800 или 3600 секунд). Это гарантирует, что выключаемый процесс будет «жить» достаточно долго для завершения всех активных потоков.
Установка лимита в 15 соединений на процесс провоцирует так называемый «дребезг» (thrashing) операционной системы. Рабочие процессы rphost непрерывно создаются, инициализируют кэш метаданных конфигурации (что требует огромных вычислительных ресурсов и нагружает дисковую подсистему), а затем почти сразу уничтожаются.
Для стабильной работы кластера рекомендуется придерживаться следующих правил:
rphost на современном оборудовании легко и стабильно держит от 50 до 150 соединений. Увеличение этого лимита хотя бы до 50–100 резко снизит частоту создания и уничтожения процессов.Вместо того чтобы пытаться угадать оптимальное количество соединений для всего кластера, рассмотрим наиболее надежный архитектурный подход — изоляцию фоновых заданий с помощью механизмов Требований назначения функциональности.
Этот инструмент позволяет жестко зафиксировать выполнение фоновых и регламентных заданий на выделенных рабочих процессах, которые никогда не будут выключаться из-за колебаний пользовательской активности.
Выполним настройку ТНФ по шагам:
BackgroundJob.CommonModule (для фоновых заданий, запускаемых из кода)BackgroundJob.ScheduledJob.При такой конфигурации фоновые задачи будут выполняться строго в изолированном пуле процессов, полностью исключая влияние пользовательской активности на их жизненный цикл.
Как справедливо заметил автор темы в Сообщении №8, проблема усугубляется при использовании Внешних источников данных. Если модули вашей системы часто обращаются к сторонним базам данных (через ODBC или OLEDB-драйверы), может возникать зависание сетевых сокетов на уровне операционной системы.
Если процесс rphost завис в ожидании ответа от внешней СУБД, он физически не может корректно отработать команду выключения. Менеджер кластера, не получив отклика в течение определенного времени, завершает зависший процесс принудительно (Hard Kill). Это гарантированно приводит к падению всех остальных заданий, которые выполнялись на данном процессе в этот момент.
При работе с внешними источниками рекомендуется всегда оборачивать вызовы в безопасные блоки с перехватом исключений и контролировать таймауты соединений.
Рассмотрим пример безопасного вызова внешнего источника данных на встроенном языке 1С:
Процедура ВыполнитьЧтениеИзВнешнегоИсточника() Экспорт
Попытка
// Устанавливаем соединение с внешним источником данных
ВнешниеИсточникиДанных.ВнешняяБД.УстановитьСоединение();
// Выполняем запрос к внешней таблице
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
| ВнешняяТаблица.Идентификатор,
| ВнешняяТаблица.Значение
|ИЗ
| ВнешнийИсточникДанных.ВнешняяБД.Таблица.ВнешняяТаблица КАК ВнешняяТаблица";
РезультатЗапроса = Запрос.Выполнить();
// Обработка данных...
Исключение
// Записываем детальную информацию об ошибке в Журнал регистрации
ЗаписьЖурналаРегистрации(
"ВнешниеИсточникиДанных",
УровеньЖурналаРегистрации.Ошибка,
,,
ПодробноеПредставлениеОшибки(ИнформацияОбОшибке())
);
// Вызываем исключение для корректной обработки вызывающим кодом
ВызватьИсключение "Не удалось получить данные из внешнего источника. Подробности в журнале регистрации.";
КонецПопытки;
КонецПроцедуры
Не стоит забывать и о системных программных ошибках (багах) самой платформы 1С. Ошибки распределения нагрузки и маршрутизации вызовов при выключении рабочих процессов неоднократно регистрировались вендором в линейках версий 8.3.15–8.3.18.
Если вы регулярно сталкиваетесь с ошибками rphost disabled при корректных настройках кластера, настоятельно рекомендуется обновить платформу до актуальных стабильных релизов (ветки 8.3.22, 8.3.24 и выше). В этих версиях алгоритмы передачи контекста сеансов и миграции активных соединений с выключаемых процессов на стабильные были существенно доработаны и оптимизированы.
Для того чтобы навсегда избавиться от аварийного завершения фоновых заданий из-за выключения рабочих процессов, выполните следующие шаги: