При работе с крупными базами данных на платформе «1С:Предприятие 8.3» администраторы и разработчики часто сталкиваются с ситуацией, когда запущенная тяжелая операция (например, групповое перепроведение документов, закрытие месяца или расчет себестоимости в «1С:Комплексная автоматизация») выполняется часами. Если запуск производился внутри терминальной сессии RDP, сеанс пользователя может автоматически завершиться по таймауту неактивности со стороны операционной системы Windows Server. При этом в консоли администрирования серверов 1С запущенный сеанс переходит в статус «Спящий». В этой статье мы подробно разберем, можно ли перехватить этот сеанс, что происходит с транзакциями при обрыве связи и как удаленно проконтролировать ход выполнения задачи.
Начнем с главного вопроса: нет, вручную подключиться к спящему сеансу с другого компьютера или из нового окна программы невозможно. В платформе 1С не предусмотрены механизмы «перехвата» или ручного внедрения в существующий сеанс сторонним процессом.
Технология спящих сеансов, внедренная в платформу начиная с версии 8.3.5, создана исключительно для автоматического восстановления связи. Она работает по следующему алгоритму:
1cv8c.exe или 1cv8.exe) на компьютере пользователя теряет связь с сервером приложений (например, из-за кратковременного сбоя Wi-Fi или ухода ноутбука в спящий режим).Однако в рассматриваемом случае терминальный сервер Windows принудительно завершил («убил») процесс тонкого или толстого клиента 1С внутри RDP-сессии по таймауту. Поскольку инициатор сеанса физически прекратил свое существование в оперативной памяти сервера терминалов, отправить запрос на пробуждение больше некому. Этот сеанс стал «сиротой» и будет отображаться в консоли 1С до тех пор, пока сервер не удалит его по истечении лимита времени (по умолчанию — 24 часа), либо пока администратор не удалит его вручную.
Проанализируем техническое состояние сеанса. Если в консоли администрирования серверов 1С в колонке «Спящий» у сеанса стоит значение «Да», это однозначно указывает на то, что активная работа на стороне сервера уже прекращена.
Сеанс в 1С физически не может перейти в спящий режим до тех пор, пока выполняется хотя бы один серверный вызов (код встроенного языка или SQL-запрос). Пока СУБД проводит документы, сеанс удерживает рабочее соединение с рабочим процессом rphost. Переход в «спящее» состояние происходит только тогда, когда активных вызовов нет, а пинги от клиента отсутствуют более 2 минут. Таким образом, если вы видите статус «Да», проведение документов уже завершилось (успешно или с ошибкой) либо прервалось из-за отката транзакции.
Судьба запущенного процесса зависит от архитектуры запуска процедуры проведения:
1. Синхронный запуск (напрямую из клиентского интерфейса):
Если перепроведение выполнялось в контексте клиентской сессии (пользователь видел полосу загрузки и ждал окончания процесса), то при уничтожении процесса тонкого клиента операционной системой сервер 1С фиксирует потерю связи. Платформа пытается корректно прервать выполнение текущей операции. Поскольку проведение документов всегда выполняется в транзакции, вся незавершенная транзакция полностью откатывается. База данных возвращается в исходное состояние, которое было до запуска операции.
2. Асинхронный запуск (через фоновые или регламентные задания):
Если в конфигурациях на управляемых формах (таких как КА 2, ERP 2.5 или БП 3.0) проведение запускалось через типовые механизмы закрытия месяца или группового изменения объектов, платформа задействует механизмы БСП (Библиотеки стандартных подсистем). Процесс перепроведения в этом случае делегируется фоновому заданию.
Такое задание выполняется в отдельном системном сеансе на сервере приложений 1С. В этом случае закрытие RDP-сессии пользователя и «засыпание» его клиентского сеанса никак не влияют на проведение — фоновый процесс на сервере продолжит работать автономно до полного завершения.
Поскольку подключиться к сеансу напрямую мы не можем, воспользуемся косвенными методами диагностики.
Это самый достоверный способ узнать, что происходило в системе. Откроем Журнал регистрации из любого другого активного сеанса с правами администратора и настроим фильтр:
Проанализируем записи:
Сеанс отсутствует или удален или сообщения об откате транзакции — проведение прервалось.Если у вас есть подозрение, что проведение было запущено через фоновое задание и все еще продолжается, обратим внимание на показатели сеансов в консоли кластера 1С. Откроем список сеансов и проанализируем колонки:
Понаблюдаем за этими параметрами в динамике в течение 5–10 минут. Если показатели непрерывно меняются (растет объем прочитанных/записанных данных, меняется загрузка памяти), значит, серверный процесс активно работает с базой данных. Если показатели статичны — процесс завершен.
Для определения запущенных на сервере фоновых процессов мы можем написать небольшую внешнюю обработку или выполнить код во внешней консоли запросов/кода под администратором:
ПараметрыОтбора = Новый Структура;
ПараметрыОтбора.Вставить("Состояние", СостояниеФоновогоЗадания.Активно);
АктивныеЗадания = ФоновыеЗадания.ПолучитьФоновыеЗадания(ПараметрыОтбора);
Для Каждого Задание Из АктивныеЗадания Цикл
Сообщить("Активно задание: " + Задание.ИмяМетода + " | Запущено: " + Задание.Начало);
КонецЦикла;
Этот простой алгоритм покажет все выполняющиеся в данный момент фоновые процессы на сервере 1С, что позволит исключить вероятность того, что проведение еще идет в фоне.
При использовании клиент-серверного варианта работы (MS SQL Server, PostgreSQL) мы можем обратиться к средствам СУБД. Например, в MS SQL Server мы можем открыть Activity Monitor или выполнить системный запрос для поиска активных блокировок и транзакций, инициированных процессами rphost. Если СУБД нагружает процессор на 90-100% и в списке активных запросов фигурируют таблицы проведения документов (например, таблицы регистров накопления или бухгалтерии), значит, СУБД все еще записывает результаты проведения.
Чтобы исключить аварийное прерывание длительных процессов, выполним превентивные настройки инфраструктуры.
Основная причина проблемы — жесткие лимиты сессий в Windows Server. Системному администратору необходимо настроить групповые политики (GPO) или параметры служб удаленных рабочих столов следующим образом:
В конфигураторе через меню Администрирование — Параметры информационной базы мы можем гибко управлять поведением спящих сеансов: