1С: как бороться с зависшими сеансами

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

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

Бороться с зависшими сеансами нужно на трёх уровнях: оперативно находить и завершать их вручную, настраивать автоматическое завершение по тайм-ауту и устранять первопричины — сетевые обрывы, ошибки в коде фоновых заданий, некорректную работу интеграций. Дальше разберём каждый уровень с конкретными действиями.

Как распознать зависший сеанс и чем он опасен

Не каждый «старый» сеанс — зависший. Пользователь мог просто оставить программу открытой на ночь, и это нормальная ситуация. Признаки именно зависшего сеанса: время последней активности не меняется часами, объём прочитанных и записанных данных заморожен, клиентский компьютер выключен или недоступен, а сам пользователь утверждает, что давно вышел из программы.

Опасность зависших сеансов троякая. Во-первых, они удерживают клиентские лицензии — при дефиците лицензий реальные пользователи получают отказ во входе. Во-вторых, сеанс может держать управляемые блокировки данных, из-за чего коллеги не могут провести документы или закрыть период. В-третьих, каждый сеанс занимает память внутри рабочего процесса rphost, и накопление «мёртвых» сеансов ведёт к росту потребления памяти и деградации производительности всего кластера.

Где смотреть список сеансов

Основной инструмент администратора — консоль управления кластером серверов 1С. Откройте оснастку «Администрирование серверов 1С:Предприятия», раскройте нужный кластер, затем ветку «Сеансы». Здесь видны все подключения: имя пользователя, база, компьютер, время начала, время последнего обращения, объём вызовов и потребляемая память.

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

Файловые базы не имеют кластера, поэтому там список подключений смотрят прямо из предприятия: меню «Администрирование» → «Активные пользователи». Возможности ограничены: можно послать сообщение и завершить сеанс, но детальной статистики по памяти и вызовам нет.

Как завершить зависший сеанс вручную

В консоли кластера выделите зависший сеанс и через контекстное меню выберите «Удалить». Сервер 1С разорвёт соединение и освободит лицензию и блокировки. Это основной способ разовой чистки, он безопасен для базы целиком, но не для данных того конкретного сеанса: всё, что пользователь не сохранил, будет потеряно.

Если сеансов много, удобнее действовать через утилиту администрирования rac из командной строки. Она позволяет получить список сеансов и завершить конкретный по его идентификатору, что легко автоматизировать скриптом.

rac session --cluster=<ID_кластера> list
rac session --cluster=<ID_кластера> terminate --session=<ID_сеанса>

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

1. 1
   Откройте консоль кластера и перейдите в раздел «Сеансы»
2. 2
   Отсортируйте по времени последней активности и найдите подозрительные сеансы
3. 3
   Убедитесь, что пользователь действительно не работает (позвоните или проверьте его компьютер)
4. 4
   Завершите сеанс через контекстное меню «Удалить»
5. 5
   Проверьте, что лицензия освободилась и блокировки сняты
6. 6
   Если сеанс появился снова — ищите источник: фоновое задание, COM-подключение, авторестарт клиента

Автоматическое завершение: тайм-ауты кластера

Ручная чистка не масштабируется: если сеансы зависают регулярно, настройте автоматическое завершение. В свойствах кластера (консоль серверов, правый клик по кластеру → «Свойства») есть параметры, отвечающие за контроль соединений: интервал проверки и время, после которого не отвечающее соединение считается разорванным. Ключевые параметры — «Тайм-аут разрыва соединения» и «Интервал проверки разрыва»: сервер периодически опрашивает клиентов и завершает те соединения, которые не отвечают.

Подбирайте значения осмотрительно. Слишком агрессивный тайм-аут будет обрывать сеансы пользователей, которые просто долго не кликали мышью, но сидят в программе — например, читают длинный отчёт. Слишком мягкий — и зависшие сеансы будут копиться часами. Практичный подход: начать с умеренных значений, наблюдать неделю и корректировать по жалобам и статистике.

Дополнительно настраивается «засыпание» сеансов тонкого клиента: неактивный сеанс переводится в спящий режим, освобождая часть ресурсов, а затем завершается по отдельному тайм-ауту. Это компромисс между удобством пользователей (возврат в программу без повторного входа) и экономией ресурсов сервера.

Зависшие фоновые задания и внешние подключения

Отдельная категория проблем — фоновые задания, которые «застряли»: обмен с сайтом, синхронизация между базами, тяжёлая обработка данных. Такой сеанс выглядит активным, но по факту крутится в бесконечном цикле или ждёт ответа от недоступного внешнего ресурса. Завершение сеанса в консоли кластера не всегда останавливает само задание корректно — надёжнее отменить задание через консоль заданий или программно, а затем разобраться с причиной зависания.

Частый источник «фантомных» сеансов — внешние интеграции: скрипты, подключающиеся через COM-connector, веб-сервисы и HTTP-сервисы, которые по ошибке не закрывают соединение. Каждый такой запуск плодит новый сеанс. Диагностика проста: в списке сеансов видно много однотипных подключений от одного пользователя-робота с одного сервера. Лечится исправлением кода интеграции, а не чисткой сеансов.

Профилактика: как не допустить повторения

Устойчивое решение строится на устранении причин. Проверьте стабильность сети между клиентами и сервером: обрывы VPN и Wi-Fi — главный генератор зависших сеансов. На терминальных серверах настройте завершение отключённых RDP-сессий по тайм-ауту, чтобы «забытые» сеансы Windows не удерживали клиентов 1С.

Полезны регламентные меры: скрипт, который по расписанию через rac анализирует сеансы и завершает те, что неактивны дольше заданного порога; мониторинг количества сеансов и памяти rphost с оповещением администратора; периодический анализ журнала регистрации на предмет ошибок фоновых заданий. Для разработчиков правило простое: любой код, открывающий соединение, обязан его закрывать, а длительные операции должны иметь контрольные точки и обработку прерывания.

Частые вопросы