Где сервер 1С хранит данные сеансов и что делать, когда они разрастаются

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

Управлять сеансовыми данными можно тремя способами: точечно (завершить конкретный зависший сеанс в консоли или через rac), настройками (ограничить память рабочих процессов и вынести сервис в отдельный менеджер) и радикально (остановить сервер и удалить кэш snccntx). Первый способ безопасен в любое время, второй требует перезапуска процессов, третий — только в технологическое окно.

Как устроены сеансовые данные в кластере 1С

Каждый пользователь, фоновое задание или веб-клиент — это сеанс. Сеанс живёт дольше одного вызова сервера, поэтому кластеру нужно где-то хранить его состояние, пока клиент думает или пользователь пьёт кофе.

📦 Что попадает в сеансовые данные:

• 🔹 значения параметров сеанса, которые заполняются при входе;
• 🔹 данные, помещённые методом ПоместитьВоВременноеХранилище() — файлы, табличные документы, выгрузки;
• 🔹 серверная часть управляемых форм: реквизиты формы между вызовами клиента;
• 🔹 служебное состояние сеанса — текущая база, пользователь, лицензия.

Где они живут физически

В платформе 8.3 сеансовые данные обслуживает сервис сеансовых данных — один из сервисов менеджера кластера rmngr. Рабочие процессы rphost обращаются к нему, а горячую часть держат у себя в кэше. Поэтому при перезапуске рабочего процесса сеанс не обрывается: его состояние хранится не в самом rphost.

На диске сервис сбрасывает данные в каталог реестра кластера:

Номер 1541 в имени — порт менеджера кластера. Если кластер поднят на другом порту, папка будет называться иначе, например reg_2541.

Рядом в reg_1541 лежат файлы реестра кластера 1CV8Clst.lst, 1CV8Reg.lst и папки информационных баз с GUID без префикса — в них, среди прочего, журнал регистрации. Удалять их нельзя: это настройки кластера и история событий баз.

Активные и зависшие сеансы: как найти и разобрать

Первое, с чего начинается разбор, — список сеансов. В консоли кластера: Кластеры → <кластер> → Информационные базы → <база> → Сеансы. Общий список по всем базам — в узле Кластеры → <кластер> → Сеансы.

👀 Колонки, на которые смотреть:

• 🔹 Последняя активность — сеанс, который час не обращался к серверу, а «Время вызова (текущее)» у него растёт, скорее всего завис;
• 🔹 Приложение — «Тонкий клиент», «Веб-клиент», «Фоновое задание», «COM-соединение», «Конфигуратор»;
• 🔹 Спящий — сеанс, у которого пропало клиентское соединение;
• 🔹 Память (текущая) и Память (5 мин) — кто съедает память рабочего процесса;
• 🔹 Блокировано СУБД и Блокировано 1С — номер сеанса, который держит этот сеанс в ожидании.

Спящие сеансы

Если у пользователя пропала сеть или он закрыл ноутбук, сеанс не исчезает сразу, а «засыпает». Его данные остаются в сервисе сеансовых данных, лицензия освобождается. Через заданное время спящий сеанс завершается. Эти интервалы видны в свойствах сеанса; в выводе rac это поля passive-session-hibernate-time и hibernate-session-terminate-time.

Пачка спящих сеансов — нормальная картина после сбоя сети. Но если они копятся сутками, растёт и объём snccntx.

Список сеансов из командной строки

Утилита rac работает через сервер администрирования ras, его нужно запустить заранее (по умолчанию порт 1545).

rem список кластеров и их идентификаторы
rac cluster list

rem все сеансы кластера
rac session list --cluster=<uuid-кластера>

rem сеансы с информацией о лицензиях
rac session list --cluster=<uuid-кластера> --licenses

rem завершить конкретный сеанс
rac session terminate --cluster=<uuid-кластера> --session=<uuid-сеанса>

Если на кластере задан администратор, добавьте --cluster-user=<имя> --cluster-pwd=<пароль>. Остальные параметры смотрите в rac help session.

Очистка сеансовых данных и памяти кластера

Чистить есть смысл в двух случаях: папки snccntx выросли до размеров, которые мешают диску, или сервер стабильно выдаёт ошибки сеансов, которые не проходят после перезапуска рабочих процессов.

Мягкий вариант: перезапуск рабочего процесса

В консоли откройте Кластеры → <кластер> → Рабочие процессы и найдите rphost с аномальной памятью. Его можно завершить в диспетчере задач по PID из консоли — кластер сам запустит новый процесс. Сеансовые данные при этом сохраняются в сервисе, пользователи остаются в базе, но вызовы, которые выполнялись в этом процессе прямо сейчас, оборвутся с ошибкой. Поэтому выбирайте момент, когда в процессе нет длинных операций.

Радикальный вариант: удаление кэша snccntx

Этот способ сбрасывает состояние всех сеансов сразу. Все пользователи будут отключены, несохранённые данные пропадут. Делайте это вне рабочего времени, предупредив людей.

1. Попросите пользователей выйти и проверьте в консоли, что сеансов не осталось. Фоновые задания, которые идут в этот момент, лучше дождаться.
2. Сделайте копию каталога reg_1541 целиком — на случай, если удалите не то.
3. Остановите службу агента сервера: в services.msc найдите «Агент сервера 1С:Предприятия 8.3» или выполните net stop с именем службы. На Linux — systemctl stop для службы сервера 1С вашей версии.
4. Убедитесь в диспетчере задач, что процессов ragent, rmngr, rphost больше нет.
5. В каталоге reg_1541 удалите только папки, имя которых начинается на snccntx.
6. Запустите службу и проверьте вход в базу.

Пример для Windows (имя службы на вашем сервере может отличаться — посмотрите его в свойствах службы):

net stop "1C:Enterprise 8.3 Server Agent (x86-64)"
for /d %%D in ("C:\Program Files\1cv8\srvinfo\reg_1541\snccntx*") do rd /s /q "%%D"
net start "1C:Enterprise 8.3 Server Agent (x86-64)"

Если после очистки проблема вернулась

Значит, раздувает не мусор, а живой код. Частая причина — обработки, которые кладут большие файлы во временное хранилище и не удаляют их. Разработчику стоит проверить:

• 🔸 передаётся ли во ПоместитьВоВременноеХранилище() уникальный идентификатор формы — тогда данные удалятся вместе с закрытием формы;
• 🔸 вызывается ли УдалитьИзВременногоХранилища() после того, как файл забрали;
• 🔸 не хранятся ли выгрузки на сотни мегабайт в реквизитах формы.

Взаимоблокировки: как они связаны с сеансами

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

Два разных сценария выглядят для пользователя похоже:

Как найти виновника

1. В списке сеансов базы отсортируйте по колонке «Блокировано 1С» или «Блокировано СУБД». В ней стоит номер сеанса, который мешает.
2. Найдите этот номер в колонке «Сеанс» и посмотрите, кто это и сколько длится его вызов.
3. Если это забытый отчёт или висящая обработка, свяжитесь с пользователем, а потом завершите сеанс.

Транзакция откатится, блокировки снимутся, очередь пойдёт. Данные завершённого сеанса — его временное хранилище и состояние форм — будут удалены, в базе ничего не испортится: незавершённая транзакция просто не запишется.

Настройки рабочего сервера и кластера, которые влияют на сеансовые данные

Большая часть проблем с памятью решается настройками, а не очисткой. Параметры разнесены по двум окнам.

Свойства рабочего сервера

Открываются в консоли через Кластеры → <кластер> → Рабочие серверы → <сервер> → Свойства.

Флажок «Менеджер под каждый сервис» особенно полезен для сеансовых данных. Сервис сеансовых данных уходит в отдельный процесс rmngr, и по его памяти в диспетчере задач сразу видно, сколько он потребляет. Параметр применяется после перезапуска службы.

Свойства кластера

Кластеры → <кластер> → Свойства. Здесь живут правила перезапуска процессов:

• 🔹 Интервал перезапуска — плановый перезапуск рабочих процессов раз в N секунд; помогает при медленных утечках памяти;
• 🔹 Допустимый объём памяти и Интервал превышения допустимого объёма памяти — процесс, который дольше заданного времени держит память выше порога, будет перезапущен;
• 🔹 Принудительно завершать проблемные процессы — без этого флажка зависший rphost будет только помечен, но не убит.

Требования назначения функциональности

На кластере из нескольких серверов сервис сеансовых данных можно закрепить за конкретной машиной. В свойствах рабочего сервера откройте «Требования назначения функциональности» и добавьте правило для типа объекта «Сервис сеансовых данных». Так он будет работать на сервере с быстрым SSD и достаточной памятью.

Диагностика через технологический журнал

Консоль показывает, кто тормозит сейчас. Технологический журнал показывает, что происходило ночью, когда никто не смотрел. Он настраивается файлом logcfg.xml в каталоге conf установленной платформы (например, C:\Program Files\1cv8\conf\). Сервер подхватывает изменения сам, без перезапуска, примерно в течение минуты.

Пример: ловим ожидания блокировок, таймауты и взаимоблокировки.

<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="http://v8.1c.ru/v8/tech-log">
  <log location="D:\techlog\locks" history="24">
    <event>
      <eq property="name" value="TLOCK"/>
    </event>
    <event>
      <eq property="name" value="TTIMEOUT"/>
    </event>
    <event>
      <eq property="name" value="TDEADLOCK"/>
    </event>
    <property name="all"/>
  </log>
</config>

history="24" — хранить файлы 24 часа. Каталог журнала должен быть на диске с запасом места и с правами на запись для пользователя службы, например usr1cv8.

📋 Какие события смотреть под задачу:

В событии TDEADLOCK смотрите свойство DeadlockConnectionIntersections: там перечислены пары соединений и ресурсы, на которых они сцепились. По номерам соединений находите пользователей и операции — это прямой путь к месту в коде, которое нужно переписать.

Ошибки, связанные с сеансовыми данными

Частые вопросы