Ситуация, когда сеансы пользователей в 1С зависают в состоянии покоя, задваиваются или блокируют объекты информационной базы, является распространенной проблемой в клиент-серверной архитектуре. При этом пользователи сталкиваются с ошибками вида «Объект заблокирован», отменой транзакций или невозможностью провести документ. Разберем по шагам, почему возникают «фантомные» сессии и как правильно локализовать и устранить эту проблему.
Одной из наиболее частых причин зависания сессий является кратковременная потеря пакетов в локальной сети. Режим работы «Толстый клиент» крайне чувствителен к сетевым задержкам и нестабильности соединений. В отличие от стандартного обмена трафиком, платформа 1С передает данные крупными порциями. Обычная проверка связи командой ping с параметрами по умолчанию отсылает пакеты размером всего 32 байта, что не позволяет выявить проблемы с фрагментацией и буферизацией на сетевом оборудовании.
Протестируем сетевое соединение от клиента до сервера 1С с увеличенным размером пакета:
ping IP_АДРЕС_СЕРВЕРА -l 60000 -t
Проанализируем результаты выполнения команды:
Если сетевой сбой происходит без явного закрытия TCP-соединения, серверная операционная система продолжает считать сокет активным в течение системного таймаута Keep-Alive. По умолчанию в Windows этот параметр составляет 2 часа (7 200 000 мс).
Для ускорения обнаружения «мертвых» клиентских подключений скорректируем системные таймауты в ветке реестра сервера:
HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
300000 (тип DWORD, 5 минут).1000 (тип DWORD, 1 секунда).Дополнительно проверим параметры сетевых карт на клиентах и сервере:
IPv4 Checksum Offload, Large Send Offload (LSO) и TCP Chimney Offload, так как некорректная работа драйверов сетевой карты при аппаратной обработке пакетов часто приводит к зависанию сессий под нагрузкой.В процессе работы кластера серверов 1С в каталоге реестра накапливаются временные данные сеансов. При некорректных разрывах связи данные сеансовых блокировок могут оставаться в служебных каталогах, вызывая конфликты при повторном входе пользователей.
Выполним процедуру очистки кэша сеансов:
ragent.exe).C:\Program Files\1cv8\srvinfo\reg_1541\).snccntx12345...). В этой папке хранятся сеансовые данные.Также настроим в свойствах кластера автоматический перезапуск рабочих процессов (rphost.exe) с интервалом 86400 секунд (раз в сутки) и включим параметр завершения проблемных процессов.
Чтобы сервер 1С самостоятельно удалял брошенные и неактивные сессии, удерживающие лицензии и блокировки данных, настроим параметры информационной базы в консоли администрирования кластера серверов:
1200 секунд), после которого сессия переходит в спящий режим.600 секунд), по истечении которого кластер принудительно удаляет уснувший сеанс и снимает все установленные им блокировки.Если сетевые настройки и очистка кэша не решили проблему, необходимо выяснить точную причину разрыва сессий с помощью Технологического журнала (ТЖ). Для этого создадим файл logcfg.xml в каталоге настроек платформы (C:\Program Files\1cv8\conf\logcfg.xml).
Посмотрим на пример конфигурации журнала для отслеживания разрывов соединений и блокировок:
<config xmlns="http://v8.1c.ru/v8/tech-log">
<dump location="C:\LOGS\DUMPS" create="true" type="0" prntscrn="false"/>
<log location="C:\LOGS\TJ" history="24">
<event>
<eq property="name" value="CONN"/>
</event>
<event>
<eq property="name" value="SESS"/>
</event>
<event>
<eq property="name" value="TLOCK"/>
</event>
<event>
<eq property="name" value="EXCP"/>
</event>
<property name="all"/>
</log>
</config>
Проанализируем события, попадающие в лог:
Если локальная сеть между рабочими станциями и сервером 1С работает через неуправляемые коммутаторы или имеет большую протяженность, использование толстого клиента всегда будет нести риски зависания транзакций. В таких условиях рекомендуется применить одно из следующих решений: