Как устранить ошибку «Сеанс отсутствует или удален» в технологическом журнале 1С

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

При администрировании высоконагруженных систем на платформе 1С:Предприятие 8.3 специалисты часто сталкиваются с лавинообразным ростом объема технологического журнала (ТЖ). Разбор технологического журнала без боли и страданий становится важной задачей. Одной из наиболее раздражающих проблем является постоянное появление исключений EXCP с описанием «Сеанс отсутствует или удален». В этой статье мы подробно разберем, почему возникают эти записи, как они связаны с внутренними механизмами платформы и как привести логи в порядок, не теряя при этом важную диагностическую информацию.

Анализируем структуру ошибки в логах

Прежде всего, проанализируем типовую запись из технологического журнала, которая вызывает беспокойство (в анализе поможет конвертер технологического журнала в новый формат). Обычно она выглядит следующим образом:

22:13.171002-0,EXCP,2,process=rphost,p:processName=base_ac,t:applicationName=BackgroundJob,Exception=60c686dc-798f-4d17-aadb-a90156a16eb8,Descr='src\rserver\src\SrvrInfoBaseImpl.cpp(935): 60c686dc-798f-4d17-aadb-a90156a16eb8: Сеанс отсутствует или удален'

Разберем, что здесь происходит. Процесс rphost пытается выполнить операцию в контексте фонового задания (BackgroundJob). Однако в момент обращения к менеджеру кластера выясняется, что идентификатор сеанса, под которым работает поток, уже не является валидным. Ссылки на файлы SrvrInfoBaseImpl.cpp и RMngrCalls.cpp прямо указывают на разрыв коммуникации между рабочим процессом и менеджером кластера (rmngr).

Выясняем причины: почему сеанс исчезает?

Рассмотрим основные сценарии, при которых возникает данная коллизия. Важно понимать, что в большинстве случаев это не «падение» системы, а штатное (хотя и неаккуратное с точки зрения логирования) завершение процессов.

  1. Механизм полнотекстового поиска (ППП). Это наиболее частая причина для версий платформы 8.3.18 и 8.3.19. Система инициирует фоновое задание для обновления индекса. В этой ситуации история фоновых заданий может показать аномально короткие интервалы их работы. Если задание завершается очень быстро или, наоборот, прерывается менеджером из-за таймаута, возникает ситуация, когда rphost еще «помнит» сеанс, а rmngr его уже удалил из таблицы активных соединений.
  2. Действия пользователей в динамических списках. Разберем ситуацию: пользователь открывает большой список (например, список заказов) и начинает быстро вводить символы в строке поиска. Каждое изменение строки порождает новый фоновый запрос к серверу. Если пользователь стирает символ или закрывает форму до получения ответа, предыдущее фоновое задание отменяется. При попытке rphost вернуть результат в уже «убитый» сеанс, мы получаем искомое исключение.
  3. Агрессивные настройки кластера по памяти. Посмотрим на параметры «Допустимый объем памяти» и «Интервал превышения допустимого объема памяти» в консоли администрирования. Если процесс rphost достигает предела, он помечается к завершению. Новые соединения на него не принимаются, а старые начинают принудительно закрываться. В этот переходный период массово генерируются ошибки о потере сеансов.

Шаг 1: Проверка и корректировка настроек процессов

Для начала попробуем минимизировать количество естественных перезапусков процессов. Выполним следующие действия в консоли администрирования кластера 1С (в качестве альтернативы может использоваться OneS Cluster Admin - консоль администрирования кластера серверов 1С):

Шаг 2: Очистка серверного кеша и папки sncfg

Иногда причиной «фантомных» сеансов становится некорректное состояние файлов внутри самого кластера. Рассмотрим процедуру глубокой очистки:

  1. Остановим службу 1C:Enterprise 8.3 Server Agent.
  2. Перейдем в каталог данных сервера (обычно это C:\Program Files\1cv8\srvinfo).
  3. Найдем папку конкретного кластера (например, reg_1541) и внутри нее — папку sncfg. В этой директории хранятся конфигурационные данные о сеансах и процессах.
  4. Удалим содержимое папки sncfg, а также временные файлы из папок temp.
  5. Запустим службу заново. Система пересоздаст структуру данных, что часто помогает избавиться от зацикленных ошибок отсутствующих сеансов.

Шаг 3: Настройка фильтрации в logcfg.xml

Если мы выяснили, что ошибки носят информационный характер и не мешают работе пользователей (т.е. нет реальных жалоб на вылеты из программы), логично будет исключить их из технологического журнала, чтобы они не занимали место на диске. Разберем, как модифицировать файл logcfg.xml.

Добавим условие фильтрации по тексту исключения Descr. Пример настройки:


<log location="C:\Logs\1C\Exceptions" history="72">
    <event>
        <eq property="Name" value="EXCP"/>
        <not>
            <like property="Descr" value="*60c686dc-798f-4d17-aadb-a90156a16eb8*"/>
        </not>
        <not>
            <like property="Descr" value="*Сеанс отсутствует или удален*"/>
        </not>
    </event>
</log>

Используя конструкцию <not> с оператором <like>, мы приказываем системе игнорировать записи, содержащие специфический GUID ошибки. Это позволит сфокусироваться на действительно критических проблемах, таких как Access Violation или ошибки СУБД — для их отслеживания предназначен мониторинг системных ошибок и логов 1С с уведомлением в Telegram.

Шаг 4: Сетевые аспекты и антивирусы

Проанализируем взаимодействие между процессами на сетевом уровне. Кластер 1С использует динамический диапазон портов (по умолчанию 1560–1591). Если антивирусное ПО или встроенный брандмауэр Windows блокируют или «инспектируют» пакеты на этих портах, подтверждение активности сеанса (heartbeat) может не дойти от rphost до rmngr вовремя.

Рекомендация: Добавьте все исполняемые файлы 1С (ragent.exe, rmngr.exe, rphost.exe) в исключения антивируса и проверьте, чтобы диапазон портов 1540-1591 был полностью открыт для внутреннего трафика сервера.

Резюме

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

← На главную