Проблема «зависших» сеансов в кластере серверов 1С:Предприятие — одна из самых частых головных болей системных администраторов и разработчиков. Ситуация, когда один и тот же пользователь плодит десятки соединений, которые не закрываются часами, приводит к избыточному потреблению лицензий, утечкам памяти и нестабильной работе рабочих процессов rphost. Разберем подробно, почему стандартные настройки в Конфигураторе часто «не срабатывают» и как правильно настроить жизненный цикл сеанса.
Прежде всего, нам необходимо понять, как платформа 1С определяет, «жив» сеанс или нет. Многие ошибочно полагают, что если пользователь не нажимает на кнопки, сеанс должен немедленно заснуть. Однако в современных версиях платформы реализован механизм фонового поддержания связи (так называемый «пинг»).
Проанализируем документацию: клиентское приложение (будь то тонкий или толстый клиент) каждые 5–10 минут отправляет короткий запрос на сервер. Это необходимо для проверки стабильности соединения. Если мы установим в параметрах информационной базы время засыпания сеанса менее 10 минут (например, 30 секунд или 5 минут), сеанс никогда не перейдет в спящий режим. Каждый такой автоматический «пинг» будет сбрасывать счетчик неактивности пользователя, и сервер будет считать, что работа продолжается.
Рассмотрим пошагово, где и какие настройки нужно выставить для эффективного управления сеансами. Для этого зайдем в информационную базу через Конфигуратор и перейдем в меню Администрирование — Параметры информационной базы. Нас интересуют два ключевых поля:
Важный нюанс: установим время засыпания не менее 1200 секунд (20 минут). Это гарантированно перекроет интервалы внутренних опросов платформы. Время завершения можно поставить небольшим — например, 60–120 секунд. Таким образом, через 20 минут бездействия сеанс уснет, и еще через минуту-две исчезнет совсем.
Если после настройки таймингов сеансы все равно висят активными, проанализируем код конфигурации. Основным «врагом» механизма засыпания являются программные обработчики ожидания. Рассмотрим пример кода, который может блокировать сон:
ПодключитьОбработчикОжидания("ПроверитьНовыеСообщения", 60);
Если в вашей базе (особенно в самописных решениях) работает подобный код, который раз в минуту обращается к серверу для проверки почты, курса валют или уведомлений, сеанс всегда будет активным. Для сервера 1С нет разницы между тем, нажал ли пользователь кнопку «Провести» или это отработал фоновый скрипт — для него это активность сеанса.
Чтобы найти виновника, рекомендуется проверить Журнал регистрации. Если мы видим там регулярные записи от имени пользователя с одинаковым интервалом, значит, работает какой-то внутренний механизм конфигурации или регламентное задание.
Разберем ситуацию, когда пользователь закрыл ноутбук или у него пропал интернет. В этом случае соединение между клиентом и сервером обрывается некорректно. Операционная система Windows на сервере может удерживать TCP-соединение в состоянии ESTABLISHED очень долго (по умолчанию до 2 часов).
Проанализируем возможность оптимизации на уровне реестра сервера. Для ускорения очистки «мертвых» сокетов системные администраторы часто изменяют параметры KeepAliveTime. Посмотрим, какие ключи в реестре отвечают за это:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\KeepAliveTime — установим значение около 300 000 (5 минут).HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\KeepAliveInterval — установим 1000 (1 секунда).Эти настройки заставят ОС быстрее опрашивать зависшие соединения и сообщать серверу 1С, что клиент недоступен, что позволит платформе корректно пометить сеанс как разорванный.
Иногда проблема кроется не в настройках базы, а в «усталости» самого рабочего процесса rphost. В процессе долгой работы в нем могут накапливаться ошибки управления памятью, из-за чего сеансы «прилипают» к процессу и не удаляются даже принудительно через консоль.
Рассмотрим настройки кластера серверов 1С. В консоли администрирования (MMC-снапшот) откроем свойства нашего локального кластера и обратим внимание на следующие параметры:
Если ни один из способов не помог, перейдем к «тяжелой артиллерии» — настройке Технологического журнала (ТЖ). Это единственный способ увидеть, что именно происходит в момент попытки завершения сеанса.
Создадим файл logcfg.xml и добавим в него сбор событий CONN и CLSTR. Проанализируем полученные логи: мы сможем увидеть сообщения об ошибках, например, невозможность завершить транзакцию или блокировку сеанса каким-то внешним COM-объектом (например, драйвером торгового оборудования). Часто именно подключенное оборудование (сканеры, ККТ) держит канал связи открытым, не давая сеансу уйти в спящий режим.
Подводя итог, для решения проблемы зависших сеансов нам нужно действовать комплексно:
rphost в настройках кластера.Соблюдение этих шагов позволит поддерживать список сеансов в актуальном состоянии и избежать искусственного дефицита лицензий.