Одной из наиболее неприятных и труднодиагностируемых проблем в работе клиент-серверных версий 1С:Предприятие 8.3 является внезапное аварийное завершение работы пользователей с ошибкой «Сеанс отсутствует или удален». Особенно часто это проявляется при выполнении POST-запросов к ресурсу /e1cib/modules/call. В этой статье мы подробно разберем причины возникновения этой ситуации, проанализируем записи технологического журнала и рассмотрим проверенные методы решения проблемы, начиная от простых настроек базы и заканчивая системными параметрами сервера.
Прежде всего, проанализируем, что происходит в момент вылета. Ошибка часто ссылается на файлы исходного кода платформы, такие как ClusterDistribImpl.cpp или SeanceContextImpl.cpp. Это говорит о том, что механизм управления сеансами в кластере 1С теряет связь с конкретным клиентским соединением. Когда тонкий клиент или веб-клиент обращается к серверу, сервер проверяет наличие активного сеанса по его ID. Если сеанс был по какой-то причине завершен со стороны сервера (например, по таймауту или из-за сбоя процесса rphost), клиент получает отказ.
Рассмотрим основные способы решения, которые помогли администраторам на практике.
Выясним одну из самых частых причин: слишком агрессивные настройки завершения спящих сеансов. Если параметры «времени засыпания» установлены на слишком низкие значения, система может принудительно разрывать связь даже при кратковременных задержках в сети или во время выполнения длительных серверных вызовов.
Для исправления ситуации выполним следующие шаги:
Время засыпания пассивного сеанса и Время завершения спящего сеанса.Часто в базах по умолчанию или из-за случайных правок стоят значения «20» и «30». Увеличение этих интервалов позволяет избежать ситуации, когда сервер 1С считает сеанс «брошенным» и удаляет его контекст из памяти.
Начиная с версии платформы 8.3.9, в 1С появился механизм Защита от опасных действий. Иногда этот механизм работает избыточно строго, блокируя вызовы модулей через веб-сервер или тонкий клиент, что приводит к обрыву сессии.
Проанализируем ситуацию: если вылеты начались после обновления платформы или конфигурации, попробуем отключить данную защиту для пользователей:
Интересный факт: на практике замечено, что даже частичное отключение этой опции для наиболее активных пользователей может стабилизировать работу всей системы, использующей публикацию на IIS или Apache.
Проанализируем сетевую составляющую. Платформа 1С:Предприятие иногда некорректно обрабатывает приоритеты протоколов IPv4 и IPv6. При попытке сервера обратиться к самому себе или при взаимодействии менеджера кластера с рабочими процессами может возникнуть задержка из-за попыток использовать IPv6, что сервер воспринимает как разрыв TCP-соединения (ошибка 10054 в техжурнале).
Для решения проблемы рекомендуется полностью отключить IPv6 на уровне реестра Windows:
regedit.HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters.DisabledComponents (тип DWORD 32 бит).0xFFFFFFFF (в шестнадцатеричной системе).Разберем ситуацию, когда ошибки возникают под высокой нагрузкой. Современные сетевые карты пытаются «помочь» процессору, забирая на себя часть обработки пакетов (функция Offloading). Однако драйверы часто делают это с ошибками, что приводит к повреждению пакетов 1С.
Рассмотрим, какие параметры стоит отключить в свойствах сетевого адаптера на сервере:
IPv4 Checksum OffloadTCP Checksum OffloadLarge Send Offload (LSO)Отключение этих функций заставит центральный процессор обрабатывать сетевой трафик напрямую, что значительно повышает стабильность передачи данных между клиентом и сервером приложений.
Если проблема сохраняется даже после настройки параметров, возможно, повреждены временные файлы контекста сеансов. Проанализируем содержимое рабочего каталога кластера 1С (обычно это srvinfo).
Внутри каталога каждой информационной базы на сервере (папки с именами типа reg_1541) существует директория snccntxt. В ней хранятся данные SeanceContext. При аварийных завершениях там могут накапливаться «битые» файлы. Выполним очистку:
snccntxt и удалим её содержимое.Это заставит платформу создавать контексты сеансов с чистого листа, исключая конфликты со старыми записями.
Если вы используете доступ через браузер или тонкий клиент через HTTP, выясним, не является ли виновником веб-сервер. В настройках IIS обратите внимание на Application Pool Recycling (Переработка пула приложений). Если пул перезагружается слишком часто или по достижении небольшого лимита памяти, все сеансы будут мгновенно аннулированы. Рекомендуется отключить регулярную переработку пула в рабочее время.
Для Apache проверьте параметр KeepAliveTimeout. Если он установлен менее 60 секунд, веб-сервер может закрывать соединение раньше, чем rphost успеет вернуть результат длительного запроса, что спровоцирует ошибку «Сеанс отсутствует» на стороне клиента.
Мы рассмотрели комплекс мер по устранению аварийного завершения сеансов. Как показывает практика, наиболее эффективным методом является комбинация Способа 1 (увеличение таймаутов в базе) и Способа 3 (отключение IPv6). Если ваша конфигурация использует сторонние системы защиты (например, СЛК), обязательно убедитесь в актуальности версий компонентов защиты, так как они часто становятся причиной падения рабочих процессов rphost при выполнении серверных вызовов.