Работа с фоновыми заданиями на платформе 1С:Предприятие 8.2 часто сопряжена с трудностями администрирования. В отличие от более современной версии 8.3, где управление ресурсами кластера реализовано гибко, версия 8.2 имеет ряд архитектурных ограничений. Одной из наиболее острых проблем является невозможность штатными средствами закрепить выполнение фоновых заданий за конкретным рабочим процессом rphost. Это приводит к тому, что при зависании одного задания администратору зачастую приходится перезапускать весь процесс, что обрывает сеансы обычных пользователей. В этой статье мы подробно разберем, как устроена работа процессов в 8.2, почему происходят зависания и какими обходными путями можно минимизировать ущерб для системы.
Для начала проанализируем ситуацию с точки зрения архитектуры кластера. В версии 8.3 существует механизм под названием «Требования назначения функциональности». Он позволяет администратору четко указать: «этот рабочий процесс обслуживает только клиентские соединения, а этот — только фоновые задания». В версии 8.2 такого механизма не существует. Распределение соединений между процессами rphost происходит автоматически на основе внутренней логики балансировки нагрузки кластера. Кластер старается распределять сеансы равномерно, ориентируясь на количество соединений и текущий объем потребляемой оперативной памяти.
Таким образом, когда фоновое задание запускается, оно может «приземлиться» на любой из доступных рабочих процессов. Если это задание зависает и перестает отвечать на команды консоли сервера, единственный радикальный способ его остановить — это завершение процесса rphost.exe через диспетчер задач ОС или консоль. Но вместе с ним «погибнут» и все полезные сеансы пользователей, оказавшиеся в этом же процессе.
Рассмотрим подробнее основные причины, по которым фоновое задание может войти в состояние «зомби», когда кнопка «Завершить» в консоли 1С не дает никакого эффекта:
deadlock или длительной блокировки, а механизм 1С не может корректно интерпретировать состояние отката (rollback) на уровне СУБД, сеанс в консоли будет отображаться как активный, но фактически он неуправляем.rphost некорректно освобождал память после завершения тяжелых операций. Процесс раздувался до критических размеров, переставал принимать новые команды управления, но при этом продолжал удерживать старые соединения.Интересный нюанс, который мы должны разобрать, связан с тем, как именно 1С завершает сеанс. Когда вы нажимаете «Удалить» в консоли сеансов, сервер приложений 1С пытается отправить команду серверу СУБД (например, MS SQL), чтобы тот разорвал соединение (KILL SPID). Если у учетной записи, под которой сервер 1С подключается к SQL, недостаточно прав, эта команда игнорируется.
Проанализируем права пользователя SQL. Часто базу создают под учетной записью с ограниченными правами. Чтобы сервер 1С мог эффективно принудительно завершать «зависшие» в SQL процессы, убедитесь, что у учетной записи 1С в SQL Server установлена роль processadmin. В некоторых случаях даже прав db_owner бывает недостаточно для корректного выполнения низкоуровневых команд разрыва соединений. Если же база создана под sa, а задания все равно не удаляются, значит проблема локализована внутри самого потока rphost, а не на стороне SQL.
Хотя штатной изоляции нет, мы можем применить хитрость. В настройках рабочего сервера кластера 1С 8.2 есть параметр «Количество соединений на один рабочий процесс». По умолчанию там стоит значение 128. Если мы установим это значение равным 1, то система будет вынуждена для каждого нового соединения (в том числе для каждого фонового задания) запускать отдельный процесс rphost.
Рассмотрим плюсы и минусы этого подхода:
rphost. Если оно зависло, вы просто убиваете конкретный PID (идентификатор процесса) в операционной системе, не затрагивая вообще никого больше.rphost потребляет значительный объем памяти на собственные нужды платформы. Если у вас одновременно работают 50 пользователей, серверу придется держать 50 активных процессов, что может привести к нехватке ресурсов.Оптимальным решением будет установка лимита, например, в 5-10 соединений, что позволит распределить риски, не перегружая память сервера.
Разберем ситуацию, когда мы не хотим вручную мониторить консоль. Мы можем автоматизировать процесс поиска и уничтожения «зависших» заданий. Для этого удобно использовать PowerShell или VBScript, которые подключаются к кластеру через COM-соединение V82.COMConnector.
Логика работы такого скрипта может выглядеть так:
rphost, в котором запущено это задание, и принудительно завершает процесс в ОС.Посмотрим на пример логики получения информации о процессах (на примере PowerShell):
$Connector = New-Object -ComObject "V82.COMConnector"
$AgentConnection = $Connector.ConnectAgent("ServerName")
$Clusters = $AgentConnection.GetClusters()
# Выбираем нужный кластер
$WorkingProcess = $AgentConnection.GetWorkingProcesses($Clusters[0])
foreach ($Process in $WorkingProcess) {
Write-Host "Процесс: " $Process.HostName " PID: " $Process.MainPort
# Здесь можно добавить логику анализа загрузки памяти
}
Если фоновые задания критически важны и постоянно вешают систему, рассмотрим вариант с созданием второго экземпляра службы сервера 1С на этом же сервере, но на других портах (например, не 1540/1541, а 1640/1641). Это позволит полностью изолировать среду выполнения.
Посмотрим, как это реализовать:
COM-соединение или Web-сервисы передаем команды на запуск тяжелых фоновых заданий во вторую базу.В этом случае, что бы ни случилось во второй службе, основной рабочий процесс с пользователями останется в полной безопасности. Этот метод требует изменения кода конфигурации, но гарантирует 100% изоляцию.
Проанализируем важность обновления платформы. В ветке 8.2 самым стабильным считается релиз 8.2.19.130. Именно в нем были исправлены критические ошибки, связанные с «зомби-процессами» фоновых заданий, которые возникали при кратковременных разрывах связи между сервером приложений и SQL-сервером. Если ваша платформа ниже этого релиза, никакие настройки не помогут полностью избавиться от случайных зависаний.
Также не забудьте настроить параметры самого кластера:
Эти настройки позволяют серверу 1С заниматься самоочисткой без участия администратора, что является лучшим решением для платформы 8.2.