Сеансовые данные сервера 1С: что это и как ими управлять

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

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

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

Что именно входит в состав сеансовых данных

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

• имя пользователя информационной базы и его полное имя;
• имя компьютера, с которого выполнено подключение;
• тип клиента: тонкий, толстый, веб-клиент, фоновое задание, COM-соединение, веб-сервис;
• дата и время начала сеанса и время последней активности;
• номер сеанса и номер соединения с кластером;
• признак использования лицензии и её тип;
• текущий вызов СУБД, длительность текущего запроса, объём прочитанных и записанных данных;
• потребление памяти и процессорного времени рабочим процессом в контексте сеанса.

Кроме атрибутов подключения, к сеансовым данным относятся и параметры сеанса — программные переменные, которые разработчик инициализирует в модуле сеанса при старте (текущий пользователь, его настройки, ограничения доступа на уровне записей). Они хранятся на сервере в течение всего сеанса и недоступны другим сеансам.

Где хранятся сеансовые данные и сколько они живут

Основная часть сеансовых данных размещается в оперативной памяти рабочих процессов кластера (rphost). Именно поэтому перезапуск службы агента сервера 1С или рабочих процессов безвозвратно уничтожает все активные сеансы — пользователи получают ошибку разрыва соединения и вынуждены входить заново.

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

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

Как посмотреть сеансовые данные в консоли кластера

Штатный инструмент — консоль администрирования серверов 1С:Предприятия (оснастка «1С:Предприятие — серверы» на Windows или скрипты rac/ras на Linux и Windows). Порядок действий в графической консоли:

1. Откройте консоль администрирования серверов и разверните нужный кластер.
2. Перейдите в ветку «Сеансы» — отобразится список всех активных сеансов всех баз кластера.
3. Для фильтрации по конкретной базе раскройте «Кластеры → Информационные базы → имя базы → Сеансы».
4. Выделите сеанс и откройте свойства: там видны пользователь, компьютер, время начала, последняя активность, текущий вызов СУБД, показатели производительности.
5. Для завершения сеанса нажмите «Удалить» в контекстном меню — клиент получит сообщение о разрыве соединения.

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

1. 1
   Откройте консоль кластера и перейдите в список сеансов нужной базы
2. 2
   Отсортируйте по времени последней активности — зависшие сеансы обычно долго неактивны
3. 3
   Проверьте колонку текущего вызова СУБД: длительный запрос указывает на активную блокировку
4. 4
   Убедитесь по имени пользователя и компьютера, что сеанс действительно не нужен
5. 5
   Завершите сеанс через контекстное меню и попросите пользователя войти заново

Программный доступ к сеансовым данным

Из встроенного языка 1С сеансовые данные доступны через несколько механизмов. Метод ПолучитьСеансыИнформационнойБазы() возвращает массив объектов СеансИнформационнойБазы с описанием всех активных сеансов текущей базы — так строят собственные мониторинги и отчёты «кто в базе».

Для текущего сеанса доступны параметры сеанса (ПараметрыСеанса.ИмяПараметра), которые инициализируются в обработчике УстановкаПараметровСеанса модуля сеанса. Типичное содержимое — ссылка на текущего пользователя, настройки отборов, признаки лицензирования подсистем. Важно помнить: параметры сеанса устанавливаются один раз при старте и при каждом обращении, если они ещё не заданы, поэтому код инициализации должен быть быстрым и отказоустойчивым.

Для внешней автоматизации администрирования используется утилита rac в связке с сервером администрирования ras: она позволяет получать списки сеансов, завершать их и менять свойства кластера из скриптов, что удобно для регламентной очистки «висяков» вне рабочее время.

Сеансы = ПолучитьСеансыИнформационнойБазы();
Для Каждого Сеанс Из Сеансы Цикл
    Сообщить(Строка(Сеанс.НомерСеанса) + " | " + Сеанс.ИмяПользователя + " | " + Сеанс.ИмяКомпьютера);
КонецЦикла;

Типовые проблемы и их диагностика по сеансовым данным

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

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

Третий сценарий — рост потребления памяти рабочими процессами. По показателям сеансов (прочитано/записано, длительность вызовов) находят «тяжёлые» сеансы, после чего анализируют выполняемый ими код или отчёты. Частая причина — неоптимальные запросы в пользовательских отчётах или фоновых заданиях.

Безопасность и ограничения при работе с сеансами

Завершение чужого сеанса — деструктивная операция: все несохранённые данные пользователя будут потеряны, а открытая транзакция откатится. Перед принудительным завершением свяжитесь с пользователем, если сеанс активен, и убедитесь, что это не критичное фоновое задание (обмен данными, закрытие месяца, резервное копирование).

Доступ к консоли кластера и утилите rac должен быть ограничен: любой, кто может управлять сеансами, фактически контролирует работу пользователей. Используйте отдельную учётную запись администратора кластера с паролем, не работайте под пустым паролем администратора, а сервер администрирования ras ограничьте сетевыми правилами.

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

Как выбрать способ управления сеансами

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

Частые вопросы о сеансовых данных сервера 1С