Сталкиваясь с проблемами администрирования серверов 1С, мы можем обнаружить достаточно раздражающую ситуацию: когда, казалось бы, "мертвый" сеанс на сервере 1С упорно появляется вновь сразу после того, как мы его принудительно удалили (поможет контроль сбоев и прерывание сеансов 1С). Это явление, часто называемое "зомби-сеансом", может мешать проведению обновлений, монопольному доступу к базе или просто создавать лишнюю нагрузку и беспорядок в списке активных сеансов. В данном руководстве мы подробно разберем, почему возникают такие сеансы, и какие шаги мы можем предпринять для их окончательного устранения, а также для предотвращения их появления в будущем.
Для начала, давайте проанализируем, как проявляется эта проблема, исходя из обсуждения на форуме и нашего опыта:
Ключевой момент, раскрытый в ходе обсуждения на форуме (сообщение 18), заключается в том, что очень часто причиной постоянно возрождающегося сеанса является регламентное (фоновое) задание, которое было настроено на автоматический перезапуск при аварийном завершении.
Давайте разберем этот механизм подробнее: если фоновое задание, например, по обработке данных или обмену, запускается в рамках определенного сеанса (часто от имени технического пользователя, такого как DefUser, или специализированной служебной учетной записи), и мы принудительно завершаем этот сеанс, система 1С расценивает это как аварийное завершение задания. Поскольку задание настроено на перезапуск в таком случае, оно немедленно запускается снова, создавая новый сеанс, который мы снова видим в консоли. Это создает бесконечный цикл "удаления" и "возрождения".
Чтобы разорвать этот порочный круг, мы должны остановить не сам сеанс, а регламентное задание, которое его порождает.
Администрирование вашей конфигурации 1С.Обслуживание (или аналогичный, в зависимости от конфигурации).Регламентные и фоновые задания.DefUser или специальным служебным пользователем, созданным для интеграции), мы ищем регламентные задания, которые выполняются от его имени.Включено для этого задания, чтобы предотвратить его автоматический перезапуск.Иногда, как указано в сообщении 18, может потребоваться просто дождаться, когда фоновое задание завершит свое выполнение самостоятельно. Если оно завершится корректно, сеанс DefUser отключится автоматически, и не будет необходимости вмешиваться в его работу, если цель не получение монопольного доступа.
Помимо регламентных заданий, существуют и другие факторы, которые могут приводить к появлению "зомби-сеансов" или их видимому "возрождению". Давайте рассмотрим эти причины и соответствующие методы их устранения.
rphost.exe)Каждый сеанс в 1С обслуживается отдельным рабочим процессом rphost.exe на сервере. Иногда, из-за внутренних ошибок платформы, сбоев в сети или некорректно написанного кода, этот процесс может "зависнуть". При попытке удалить сеанс через консоль кластера, сама консоль отправляет команду на завершение, но зависший процесс rphost.exe не может ее корректно обработать. Спустя некоторое время система может снова отобразить этот сеанс, так как основной процесс для него все еще активен.
Диспетчер задач.Подробности или Процессы (в зависимости от версии операционной системы).rphost.exe с соответствующим PID и принудительно завершаем его, используя функцию Завершить задачу или Снять задачу. Это является более жестким, но часто эффективным методом.Сеанс может инициировать длительную транзакцию, которая создает блокировку на уровне таблиц в базе данных (например, MS SQL Server или PostgreSQL). Если сеанс завершается некорректно, блокировка в СУБД может остаться. Это иногда приводит к тому, что система 1С не может корректно убрать запись о сеансе, или же при попытках других операций, связанных с заблокированными данными, "фантомный" сеанс появляется снова.
Сеанс мог быть создан не пользователем, а внешним приложением, которое интегрировано с 1С через COM-соединение или веб-сервисы. Если такое приложение настроено на постоянное поддержание связи и автоматическое переподключение при обрыве, то после принудительного удаления сеанса оно просто создаст новый, что выглядит как его "возрождение".
При нестабильном сетевом подключении или аварийном завершении работы клиентского приложения сервер 1С не всегда мгновенно распознает, что сеанс стал неактивным. Такой "подвисший" сеанс может оставаться в системе до истечения таймаута, и попытки его удаления могут быть безуспешными до тех пор, пока сервер сам не определит его как неактивный.
racДля клиент-серверного варианта 1С Предприятия существует мощная утилита командной строки rac (RAC – RAbbitMQ Administration Console, но в контексте 1С это 1C:Enterprise Server Administration Console), которая позволяет управлять кластером серверов, включая завершение сеансов — для этого есть завершение сеансов 1С по расписанию. Этот метод является более низкоуровневым и часто более эффективным для завершения "упорных" сеансов.
rac session terminate --cluster <UUID_кластера> --session <UUID_сеанса>.rac cluster list и rac session list --cluster <UUID_кластера> соответственно.Для предотвращения подобных ситуаций в будущем и автоматической очистки системы от неактивных и "подвисших" соединений, мы можем оптимизировать настройки информационной базы.
Свойства или Настройки:
Время засыпания пассивного сеанса: Этот параметр определяет, через сколько минут неактивный сеанс (в котором нет пользовательских действий) перейдет в "спящее" состояние.Время завершения спящего сеанса: Этот параметр определяет, через сколько минут "спящий" сеанс будет принудительно завершен сервером 1С.Время засыпания пассивного сеанса можно установить в 10-15 минут, а Время завершения спящего сеанса в 30-60 минут. Это позволит серверу 1С автоматически быстрее очищать систему от неактивных соединений, уменьшая вероятность появления "зомби-сеансов".Борьба с постоянно возрождающимися сеансами 1С требует системного подхода и понимания потенциальных причин. Начиная с проверки регламентных заданий, как наиболее частой причины, и заканчивая низкоуровневой диагностикой процессов и блокировок, мы можем эффективно устранить эту проблему и обеспечить стабильную работу нашей системы 1С.