Переход с толстого клиента на тонкий в 1С:Предприятии 8.3 часто сопровождается изменением привычных механизмов администрирования. Одной из распространенных проблем становится поиск так называемых «мертвых» или зависших сессий. Если раньше в консоли кластера сеансы без привязки к серверу или порту однозначно указывали на неактуальность, то в тонком клиенте отображение параметров изменилось. В этой статье мы подробно разберем, как эффективно управлять сеансами, настраивать автоматическую очистку «зомби-процессов» и рационально использовать лицензии.
Разберем ситуацию: количество активных пользователей меньше количества купленных лицензий, но при попытке входа система сообщает о нехватке ключей. Проанализируем список сеансов в консоли управления кластером серверов 1С. В тонком клиенте многие колонки, которые были информативны для толстого клиента, могут оставаться пустыми — это нормальное поведение системы, связанное с особенностями протокола HTTP/HTTPS или работы через веб-сервер.
Для выявления неактивных сессий нам необходимо обратить внимание на колонку Спящий (в некоторых версиях она находится в самом конце списка, поэтому прокрутим таблицу вправо). Рассмотрим основные состояния сеанса:
Проанализируем колонку Последняя активность. Если разница между текущим временем и временем последней активности составляет несколько часов, а статус сеанса при этом не меняется, с большой долей вероятности этот сеанс является «мертвым» и его можно безопасно завершить вручную.
Вместо того чтобы постоянно мониторить список вручную, настроим автоматическое завершение неактуальных соединений. Выясним причину, по которой сеансы долго висят в системе. В параметрах информационной базы в консоли кластера есть два ключевых параметра, которые помогут нам автоматизировать процесс.
Разберем шаги по настройке:
Кластеры — ИмяКластера — Информационные базы.Свойства.Рассмотрим значения, которые следует установить:
1200 (20 минут) до 3600 (1 час).0, сеанс будет висеть бесконечно. Рекомендуем установить значение 300 (5 минут) или 600 (10 минут).Таким образом, если пользователь просто оставил открытую программу и ушел, через 20 минут его сеанс «уснет», а еще через 5 минут сервер принудительно закроет его, освободив лицензию для коллег.
Часто дефицит лицензий связан не с «мертвыми» сессиями, а с механизмом их подсчета. Посмотрим на ситуацию, когда один пользователь открывает несколько баз или несколько окон одной базы. Проанализируем, как 1С выдает лицензии:
Вариант 1: Лицензии выдает сервер 1С. В свойствах информационной базы параметр Разрешить выдачу лицензий сервером 1С установлен в значение Да. В этом случае каждое новое окно тонкого клиента, запущенное пользователем, будет потреблять отдельную лицензию. Если у вас 30 человек и каждый откроет по 2 окна, вам потребуется 60 лицензий.
Вариант 2: Лицензии выдаются клиентом. Если на компьютере пользователя установлен локальный USB-ключ или программная лицензия активирована локально, то в рамках одной сессии операционной системы пользователь может открывать неограниченное количество окон 1С, расходуя всего одну лицензию.
Если вы столкнулись с резкой нехваткой лицензий после перехода на 11.4 и тонкий клиент, проверьте именно этот параметр. Возможно, стоит перенастроить раздачу лицензий, чтобы экономить ресурсы.
В ситуациях, когда стандартная консоль MMC работает медленно или не дает полной картины, воспользуемся консольной утилитой rac. Она позволяет получить детальную информацию о каждом сеансе в текстовом виде. Проанализируем пример команды для получения списка сеансов:
rac session --cluster=<ID_кластера> list --infobase=<ID_базы>
В выводе данной команды обратим внимание на атрибуты hibernate (статус спящего режима) и last-active. На основе этих данных можно написать простой скрипт на PowerShell или Python, который будет раз в час проверять время последней активности и принудительно завершать сеансы, которые «молчат» более заданного времени.
Для удаления конкретного зависшего сеанса через rac используем следующую структуру:
rac session --cluster=<ID_кластера> terminate --session=<ID_сеанса>
Иногда сеанс в консоли 1С выглядит активным, но на самом деле он «зомбирован» на уровне базы данных. Разберем, как проверить это через SQL Server Management Studio (SSMS). Воспользуемся системной процедурой sp_who2 или динамическим представлением:
SELECT * FROM sys.dm_exec_sessions
WHERE program_name LIKE '%1C:Enterprise%'
Проанализируем результат. Если мы видим соединение, которое удерживает транзакцию (open_transaction_count > 0) очень долгое время без изменения объема считанных данных, это явный признак зависшего процесса. В таких случаях иногда требуется «убить» процесс на уровне SQL-сервера, что приведет к автоматическому разрыву сеанса и в кластере 1С.
Не забудем про фоновые и регламентные задания. В современных конфигурациях (например, ERP 2 или КА 2) их количество значительно возросло. Каждое фоновое задание создает кратковременный сеанс. Если в вашей системе настроено много часто выполняющихся заданий (например, раз в 10 секунд), в консоли всегда будет «шум» из множества сеансов. Проанализируем колонку Приложение в консоли кластера — сеансы с типом BackgroundJob не должны вводить вас в заблуждение, они обычно не занимают клиентскую лицензию (если только не инициированы специфическим образом), но создают нагрузку на сервер.
Подводя итог, для борьбы с «мертвыми» сессиями в тонком клиенте необходимо комбинировать правильную настройку таймаутов в свойствах базы, мониторинг колонки «Спящий» и понимание модели лицензирования (серверная vs клиентская выдача). Это позволит поддерживать стабильную работу системы и избегать неоправданных затрат на покупку дополнительных лицензий.