Как решить проблему с зависшими и «самовосстанавливающимися» сеансами на сервере 1С?

Системный администратор 1С v8.3 (Управляемые формы) 1С:Розница Торговля и дистрибуция
← На главную

В практике администрирования серверов 1С часто встречается неприятная ситуация: сеансы пользователей зависают, а после стандартного перезапуска службы или удаления процессов rphost они «воскресают» снова. Это создает серьезные проблемы, особенно в крупных инфобазах с количеством пользователей от 100 до 400, где блокировки и некорректные соединения могут парализовать работу целых отделов. Рассмотрим подробно, почему это происходит и как правильно провести «генеральную уборку» сервера для устранения этой проблемы.

Разберем причину «живучести» сеансов: механизм snccntx

Проанализируем ситуацию: почему даже после перезапуска службы 1С сеансы появляются снова? Главный виновник этого процесса — механизм сохранения данных сеансов. В каталоге описания кластера (по умолчанию это путь C:\Program Files\1cv8\srvinfo\reg_1541) существует специальная папка с именем вида snccntx... (Session Context).

Рассмотрим подробнее механизм её работы:

  1. Менеджер кластера 1С (процесс rmngr) постоянно записывает состояние текущих сеансов в файлы внутри этой папки.
  2. При штатном или аварийном перезапуске службы менеджер кластера считывает эти файлы и пытается восстановить состояние соединений.
  3. Если в данных сеанса произошла ошибка или база данных удерживает транзакцию, сеанс восстанавливается в «зависшем» состоянии.

Следовательно, простое «убийство» процесса rphost через диспетчер задач не поможет — rmngr просто создаст новый рабочий процесс и «подцепит» туда старые данные из кэша сеансов.

Выясним роль профиля пользователя службы 1С

Часто системные администраторы совершают ошибку, очищая кэш только на клиентских машинах. Однако сервер 1С сам является «клиентом» по отношению к СУБД и хранит свои временные файлы. Разберем, где именно искать эти данные.

Если служба 1С запущена от имени специального пользователя (например, USR1CV8), то его временные файлы находятся по пути: C:\Users\USR1CV8\AppData\Local\1C\1Cv8.

В этой директории хранятся:

Важный момент: если служба работает под системной учетной записью (Local System), пути будут иными: C:\Windows\System32\config\systemprofile\AppData\Local\1C (или в папке SysWOW64 для 32-битных систем). Перед очисткой обязательно проверьте, под кем стартует dbgs и ragent.

Проанализируем влияние журнала регистрации

Посмотрим на ситуацию со стороны стабильности системы. В версиях платформы 8.3.10 и выше стал активно применяться новый формат журнала регистрации — .lgd (на базе SQLite). При высокой нагрузке (300+ пользователей) этот формат часто становится узким местом.

Любая попытка пользователя войти в систему инициирует запись в журнал регистрации. Если файл 1Cv8.lgd заблокирован из-за большой очереди транзакций или поврежден, сеанс «зависает» на этапе авторизации, так и не открыв интерфейс.

Как изменить формат на более стабильный (текстовый):

  1. Остановите сервер «1С:Предприятия».
  2. Перейдите в каталог 1Cv8Log внутри папки вашей базы в srvinfo.
  3. Удалите или переименуйте файл 1Cv8.lgd.
  4. Создайте в этой же папке пустой текстовый файл 1Cv8.lgf.
  5. Запустите сервер. Платформа поймет, что нужно использовать старый текстовый формат.

Алгоритм полного решения проблемы (пошагово)

Если «легкие» методы очистки не помогают, выполним последовательность действий, которую применили участники обсуждения для гарантированного результата. Проводить эти работы лучше в технологическое окно, когда все пользователи покинули систему.

  1. Завершение работы пользователей: Отключите доступ к серверу (через RDP или блокировку соединений в консоли администрирования 1С).
  2. Остановка служб: Полностью остановите службу Агент сервера 1С:Предприятия. Убедитесь через диспетчер задач, что процессы ragent, rmngr и все rphost исчезли.
  3. Остановка СУБД: Остановите службу SQL Server. Это необходимо, чтобы разорвать все «спящие» транзакции (SPID), которые могут удерживать блокировки на уровне таблиц базы данных.
  4. Очистка серверных данных:
    • Удалите содержимое папок snccntx в каталогах всех информационных баз внутри reg_1541.
    • Очистите папку temp в профиле пользователя, от которого запускается 1С.
    • Удалите содержимое папки C:\Users\<Имя_Пользователя_Службы>\AppData\Local\1C\1Cv8.
  5. Перезагрузка сервера: Выполните физическую перезагрузку сервера (ОС Windows) для сброса всех сетевых сокетов и очистки оперативной памяти.
  6. Запуск систем: Сначала запустите SQL Server, затем службу 1С.

Дополнительные настройки для предотвращения зависаний

Чтобы проблема возникала реже, проанализируем настройки сетевого стека TCP/IP. Часто сеансы висят из-за того, что сервер считает соединение активным, хотя клиент давно отключился. Для решения этой задачи рекомендуется настроить параметры KeepAlive в реестре Windows на стороне сервера 1С и SQL.

Параметры находятся в ветке: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

Также полезно будет отключить протокол IPv6, если ваша сеть его не использует, так как это может вызывать задержки при общении между процессами rmngr и rphost.

Подведем итог: Проблема «воскресающих» сеансов — это следствие работы механизмов отказоустойчивости платформы 1С, которые пытаются восстановить даже ошибочные соединения. Единственным надежным способом очистки системы является полная остановка всех связанных служб и физическое удаление файлов состояния сеансов в папке snccntx.

← На главную