Какие сеансы в 1С считаются спящими и как правильно ими управлять?

Программист 1С v8.3 (Управляемые формы) IT и автоматизация бизнеса
← На главную

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

Три состояния сеанса: активный, пассивный и спящий

Для начала проанализируем внутреннюю логику платформы. Чтобы эффективно управлять подключениями, нам нужно четко разделять три состояния, в которых может находиться сеанс пользователя:

  1. Активный сеанс: Это стандартное рабочее состояние. Сеанс считается активным, если в данный момент выполняется вызов сервера (например, проводится документ или формируется отчет) или если с момента последнего обращения к серверу прошло менее времени, установленного в параметрах кластера (по умолчанию — 20 минут).
  2. Пассивный сеанс: Это состояние, при котором клиентское приложение запущено и связь с сервером поддерживается, но реальных вызовов сервера (запросов данных) не происходило более 20 минут. Важно понимать: пассивный сеанс — это не ошибка, а режим экономии ресурсов. В современных версиях платформы (начиная с 8.3.5) пассивные сеансы могут освобождать лицензии в пул сервера, если это предусмотрено настройками.
  3. Спящий сеанс: Это состояние возникает исключительно при нештатном разрыве связи между клиентом и сервером. Примерами могут служить: аварийное завершение процесса 1cv8.exe через диспетчер задач, «падение» операционной системы, сбой сетевого оборудования или закрытие крышки ноутбука с последующим переходом в спящий режим.

Рассмотрим подробнее механизм «засыпания». Когда связь обрывается, сервер не убивает сеанс мгновенно. Он «замораживает» его, сохраняя состояние объектных данных (например, содержимое еще не записанного документа в памяти сервера). Это делается для того, чтобы при восстановлении связи пользователь мог продолжить работу ровно с того места, где остановился, без потери введенных данных. Это поведение регулируется механизмом Reconnect.

Настройка параметров кластера для управления сеансами

Для управления жизненным циклом сеансов мы должны обратиться к консоли администрирования кластера серверов 1С. Разберем основные параметры, которые влияют на поведение системы:

Если в вашей организации наблюдается дефицит лицензий или спящие сеансы блокируют регламентные операции (например, мешают обновлению конфигурации в монопольном режиме), мы рекомендуем сократить «Время завершения спящего сеанса» до приемлемых значений, например, до 1200–1800 секунд (20–30 минут). Если установить значение 0, сеанс будет удаляться сервером немедленно при обнаружении обрыва связи.

Как вычислить и завершить реально неактивного пользователя?

В обсуждениях часто звучит вопрос: «Как выкинуть бухгалтера, который открыл отчет и просто смотрит в него 3 часа?». С точки зрения сервера такой сеанс может быть пассивным, но он все равно удерживает лицензию, если не настроено иное. Рассмотрим три метода решения этой задачи.

Метод 1: Использование Библиотеки стандартных подсистем (БСП)

Это самый цивилизованный и рекомендуемый метод для современных конфигураций (УТ 11, БП 3.0, ERP 2). В составе БСП есть подсистема «Завершение работы пользователей». Проанализируем ее преимущества:

  1. Она работает на стороне клиента и отслеживает активность: движения мыши, нажатия клавиш.
  2. Система позволяет настроить время бездействия, после которого пользователю будет выведено предупреждение, а затем сеанс будет корректно завершен.
  3. Метод учитывает физическую активность человека, а не только вызовы сервера.

Метод 2: Программный контроль через обработчик ожидания

Если ваша конфигурация не использует БСП или вам нужно специфическое решение, мы можем реализовать собственный механизм. Рассмотрим пример использования метода ПодключитьОбработчикОжидания.

В модуле управляемого приложения пропишем инициализацию:


Процедура ПриНачалеРаботыСистемы()
    // Проверяем активность каждые 5 минут (300 секунд)
    ПодключитьОбработчикОжидания("ПроверитьАктивностьПользователя", 300);
КонецПроцедуры

В этом же модуле опишем саму процедуру проверки. Нам потребуется переменная, в которой будет храниться время последнего взаимодействия. Однако проще всего использовать глобальный контекст для отслеживания времени бездействия системы:


Процедура ПроверитьАктивностьПользователя() Экспорт
    МаксимальноеВремяПростоя = 3600; // 1 час в секундах
    ТекущийПростой = ПолучитьВремяБездействияСистемы(); 
    
    Если ТекущийПростой > МаксимальноеВремяПростоя Тогда
        ЗавершитьРаботуСистемы(Ложь, Ложь); // Завершаем без подтверждения
    КонецЕсли;
КонецПроцедуры

Важно помнить, что функция ПолучитьВремяБездействияСистемы() доступна в некоторых расширениях или может быть реализована через вызов Windows API, так как штатные средства 1С фиксируют только обращения к серверу.

Метод 3: Анализ журнала регистрации через регламентное задание

Рассмотрим ситуацию, когда нам нужно принудительно завершать сеансы со стороны сервера. Мы можем написать регламентное задание, которое анализирует ЖурналРегистрации. Выясним причину, по которой этот метод считается спорным: чтение журнала регистрации — ресурсоемкая операция.

Тем не менее, алгоритм может быть следующим:

  1. Получаем список активных соединений через МенеджерКластера или СеансыИнформационнойБазы.
  2. Для каждого пользователя проверяем последние записи в журнале регистрации по событию "Сеанс. Изменение" или любым другим обращениям.
  3. Если последняя запись старше 3 часов — используем средства администрирования для разрыва сеанса.

Пример получения списка сеансов:


СписокСеансов = МенеджерИнформационнойБазы.ПолучитьСеансы();
Для Каждого ТекущийСеанс Из СписокСеансов Цикл
    // Анализ времени последнего обращения
    Если ТекущийСеанс.ПоследняяАктивность < (ТекущаяДата() - 10800) Тогда
        // Код для завершения сеанса через COM-соединение или внешнее управление
    КонецЕсли;
КонецЦикла;

Влияние спящих сеансов на производительность СУБД

Проанализируем еще один важный аспект. Спящие сеансы — это не просто строчки в консоли. Пока сеанс «спит», он может удерживать:

Поэтому в высоконагруженных системах мы рекомендуем устанавливать жесткие лимиты на время жизни спящих сеансов. Оптимально — от 15 до 40 минут. Этого времени достаточно, чтобы пользователь мог перезагрузить компьютер или переподключиться к Wi-Fi, не потеряв контекст работы, но при этом система не будет «мусорить» старыми соединениями.

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

← На главную