Перевод информационных баз 1С:Предприятие на новые версии платформы (например, при переходе с 8.1 или 8.2 на 8.3) часто сопровождается неожиданным поведением системы. Одной из самых распространенных и неприятных проблем является появление так называемых «сеансов без соединений». В консоли администрирования серверов 1С мы можем наблюдать картину, когда за одним пользователем числится несколько сеансов, при этом у части из них отсутствует активное соединение, но они продолжают удерживать лицензии. Это приводит к преждевременному исчерпанию пула клиентских лицензий и блокирует работу других пользователей.
В этой статье мы подробно разберем, почему возникают подобные «сеансы-призраки», проанализируем внутренние механизмы платформы 1С 8.3 и рассмотрим пошаговые инструкции по устранению этой проблемы.
Начиная с версии платформы 8.3.5, разработчики внедрили специальный механизм повышения отказоустойчивости. Если клиентское приложение аварийно закрывается, зависает или теряет связь с сервером из-за нестабильного сетевого соединения, сервер 1С:Предприятия не уничтожает сеанс мгновенно. Он переводит его в статус «Спящий» (в консоли кластера в колонке «Спящий» устанавливается значение «Да»).
Этот механизм задуман для блага: если у пользователя на несколько секунд пропал Wi-Fi или перезагрузился роутер, при восстановлении связи он сможет продолжить работу в той же сессии без потери несохраненных данных. Однако на практике, если клиентское приложение закрылось «намертво» (например, процесс завершился аварийно), сеанс зависает на сервере без привязанного соединения. При этом он продолжает занимать рабочую лицензию. Когда пользователь заходит в систему заново, создается еще один, уже активный сеанс, расходующий очередную лицензию.
Если в параметрах информационной базы значения времени засыпания и завершения установлены в 0 (по умолчанию), платформа использует внутренние алгоритмы, из-за которых такие зависшие сеансы могут оставаться в памяти до 24 часов (86400 секунд).
Первым шагом для борьбы с сеансами без соединений является жесткое ограничение времени жизни неактивных сессий в настройках самой базы. Давайте разберем, как это сделать:
1200 (20 минут) или 1800 (30 минут). Не стоит ставить значение менее 10 минут (600 секунд), чтобы избежать ложных срабатываний из-за кратковременных пауз в работе.600 (10 минут) до 3600 (1 час) в зависимости от интенсивности работы пользователей.Важное предупреждение для крупных систем: Обратите внимание, что в современных версиях платформы (начиная с 8.3.15) изменение этих параметров на базах с числом пользователей более 10 может потребовать наличия КОРП-лицензий. Если после изменения параметров пользователи столкнулись с ошибкой лицензирования, эти значения придется вернуть в положение 0, а проблему решать другими административными методами, описанными ниже.
Если ваши пользователи работают в терминальном режиме на сервере под управлением 64-битной ОС Windows (x64), а сама платформа 1С установлена в 32-битном варианте (что часто встречается на обычных формах и толстом клиенте), возникает классический конфликт подсистемы печати.
При отправке любого документа на печать из 1С операционная система запускает специальный транслятор splwow64.exe (Spooler Windows on Windows 64-bit), который связывает 32-битное приложение 1С с 64-битными драйверами принтеров. Проблема заключается в том, что после закрытия 1С процесс splwow64.exe остается активным в операционной системе еще некоторое время. Из-за этого терминальная сессия пользователя RDP не может корректно завершиться (она переходит в статус «Дисконнект» или «Зависла»), а сеанс 1С остается висеть на сервере приложений, удерживая лицензию.
Для принудительного завершения процесса печати при закрытии основного приложения необходимо внести изменения в системный реестр терминального сервера:
regedit и нажмите Enter.HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\SysProcs
splwow64.exe и установите для него значение 0.Для автоматизации этой операции на нескольких серверах можно запустить командную строку от имени Администратора и выполнить следующую команду:
reg add "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\SysProcs" /v splwow64.exe /t REG_DWORD /d 0 /f
Данная настройка указывает операционной системе Windows принудительно гасить процесс печати splwow64.exe сразу же после того, как пользователь закрывает клиентское приложение 1С. Это позволит терминальной сессии корректно закрываться, предотвращая появление зависших сеансов.
Еще одной неочевидной причиной массового появления «сеансов без соединений» является аварийное падение (краш) платформы 1С при работе с табличными документами. Очень часто пользователи по привычке сохраняют сформированные отчеты в старый формат Excel 97-2003 (*.xls) вместо современного Excel 2007-... (*.xlsx).
Рассмотрим причины, по которым это приводит к критическому сбою:
Moxel.dll) не справляется с обработкой превышения лимитов. В лучшем случае система выдает ошибку, в худшем — уходит в бесконечный цикл с потреблением 100% ресурсов процессора и аварийно завершает работу процесса 1cv8.exe.Out of Memory и моментальное падение платформы без сохранения логов. Сеанс на сервере при этом теряет соединение с клиентом и зависает.Решение проблемы:
Что делать, если сеанс уже завис «намертво», обычное удаление через консоль администрирования серверов 1С не помогает (сеанс снова возвращается в список через несколько секунд), а перезагружать всю службу ragent нельзя, так как в базе работают десятки активных пользователей?
Существует эффективный метод точечного уничтожения зависшего рабочего процесса без вреда для остальных пользователей. Разберем эту процедуру по шагам:
PID: 4512.rphost.exe. Если автоматический запуск выключен, создайте новый рабочий процесс вручную на том же сервере приложений.
taskkill /F /PID 4512
Используя данный комплексный подход — от настройки таймаутов в конфигураторе и оптимизации реестра терминального сервера до контроля форматов сохранения отчетов — мы гарантированно избавимся от проблемы зависания сеансов без соединений, сэкономим лицензии 1С и повысим общую стабильность работы системы.