В процессе эксплуатации клиент-серверных версий 1С:Предприятие 8.3 администраторы часто сталкиваются с парадоксальной ситуацией: в базе данных наблюдаются значительные блокировки и удерживаемые соединения, однако список активных сеансов в консоли кластера или в самой конфигурации пуст. Это явление часто называют «фантомными» или «зависшими» соединениями. Рассмотрим детально, почему это происходит и как стабилизировать работу системы, основываясь на опыте решения подобных инцидентов в связке платформы 8.3.10 и конфигурации «Управление торговлей 11».
Для начала разберем механизм возникновения проблемы. В нормальных условиях при завершении работы пользователя или завершении фонового задания сеанс и связанное с ним соединение должны закрываться. Однако в релизах платформы, таких как 8.3.10.2639, может происходить сбой в коммуникации между рабочим процессом rphost и менеджером кластера rmngr. В результате запись о сеансе удаляется, но физическое соединение с базой данных (на уровне SQL) остается открытым.
Проанализируем ситуацию: рабочее соединение удерживает блокировки на уровне СУБД, что препятствует работе других пользователей. При попытке вручную удалить такое соединение через консоль администрирования 1С консоль часто «зависает», так как ожидает ответа от потока rphost, который в данный момент может быть заблокирован ожиданием ответа от SQL-сервера или находиться в состоянии бесконечного цикла.
Когда стандартная консоль 1С оказывается бесполезной, нам необходимо обратиться к первоисточнику — SQL-серверу. Проанализируем состояние процессов с помощью системных представлений. Выясним, какие именно процессы удерживают транзакции, используя следующий запрос:
SELECT
des.session_id,
des.status,
des.login_name,
des.host_name,
der.blocking_session_id,
der.wait_type,
der.last_wait_type,
det.transaction_id
FROM sys.dm_exec_sessions des
LEFT JOIN sys.dm_exec_requests der ON des.session_id = der.session_id
LEFT JOIN sys.dm_tran_session_transactions det ON des.session_id = det.session_id
WHERE des.program_name LIKE '%1C:Enterprise%'
Особое внимание стоит уделить процессам со статусом sleeping, у которых при этом поле open_transaction_count больше нуля. Это и есть те самые «зависшие» соединения. Выясним причину: если 1С отправила команду BEGIN TRANSACTION, но из-за сетевой ошибки или ошибки платформы не закрыла её, SQL-сервер будет бесконечно удерживать блокировки таблиц, пока соединение не будет разорвано принудительно.
Как показывает практика, часто триггером зависания выступают конкретные бизнес-процессы. Рассмотрим пример с документом Перемещение товаров. В старых редакциях УТ 11 при записи документа (даже без проведения) инициируется цепочка событий:
ПриЗаписи.Если конфигурация значительно доработана, в коде подписок могут присутствовать неоптимальные запросы или обращения к внешним системам. Выясним причину через замер производительности. Если зависание происходит именно в момент записи, следует проверить наличие эксклюзивных блокировок на регистрах сведений, которые могут обновляться при записи «Перемещения».
Чтобы минимизировать влияние «фантомов» на общую работоспособность базы, проанализируем настройки кластера. Если база данных работает нестабильно, рекомендуется настроить автоматическую очистку ресурсов рабочих процессов. Посмотрим на ключевые параметры в свойствах рабочего сервера:
rphost будет перезапущен до того, как начнет фрагментировать память сервера.Также полезно ограничить количество соединений на один rphost. Рассмотрим установку параметра «Количество соединений на процесс» в значение 20-30. Это позволит изолировать проблему: если один процесс зависнет из-за ошибки в коде 1С, пострадает только небольшая часть пользователей, а не вся база целиком.
Иногда причиной того, что соединения невозможно удалить через консоль, является повреждение файлов сеансовых данных в каталоге кластера. Проанализируем шаги для полной очистки:
1C:Enterprise 8.3 Server Agent.srvinfo (обычно в C:\Program Files\1cv8\srvinfo).reg_1541) и внутри нее — папку snccntxt.Local\Temp).Важно: очистка папки snccntxt приведет к завершению всех активных сеансов, поэтому данную операцию следует проводить только в технологическое окно.
Разберем еще один неочевидный фактор — сетевые настройки ОС. В некоторых релизах 8.3 наблюдались задержки при попытке работы через протокол IPv6. Рекомендуется принудительно отключить IPv6 в свойствах сетевого адаптера сервера 1С и сервера SQL.
Кроме того, настроим параметры KeepAlive в реестре Windows. Это позволит операционной системе быстрее определять «мертвые» сокеты и закрывать их. Посмотрим на параметры ветки реестра HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters:
KeepAliveTime — установите значение 300000 (5 минут).KeepAliveInterval — установите значение 1000 (1 секунда).Эти настройки заставят сервер проверять активность соединения гораздо чаще, чем по умолчанию (2 часа), что позволит SQL-серверу быстрее откатывать транзакции от аварийно завершившихся клиентов.
Решение проблемы зависших соединений требует комплексного подхода. Мы рассмотрели методы диагностики через SQL, настройки автоматизации кластера 1С и системные настройки сети. Помните, что для стабильной работы связки 8.3.10 и старых редакций УТ 11 критически важно следить за актуальностью индексов полнотекстового поиска и регулярно проводить регламентные работы на уровне SQL-сервера (обновление статистики и очистка процедурного кэша), чтобы предотвратить эскалацию блокировок при записи тяжелых документов.