Почему сервер 1С принудительно завершает сеансы пользователей и как предотвратить «убийство» процессов

← На главную

В процессе эксплуатации высоконагруженных систем на базе 1С:Предприятие 8.3 администраторы часто сталкиваются с ситуацией, когда сервер начинает самопроизвольно «убивать» сеансы пользователей или фоновые задания. Это сопровождается ошибками в Технологическом журнале (ТЖ) с пометкой func=killClient и признаком ADMIN. Со стороны пользователя это выглядит как внезапный разрыв соединения или ошибка "Cannot continue the execution because the session is in the kill state". Рассмотрим подробно, почему кластер принимает такие решения и как стабилизировать работу сервера.

Разбор причин: Механизмы мониторинга и лимиты памяти

Одной из неочевидных причин принудительного завершения сеансов является настройка безопасности расхода ресурсов. Разберем ситуацию на примере параметра «Безопасный расход памяти за один вызов». Проанализируем логику работы сервера:

Если данный параметр установлен в значение по умолчанию (0), система рассчитывает его как 5% от «Максимального объема памяти рабочих процессов».
Если и максимальный объем не задан, то за основу берется 80% от общего объема оперативной памяти сервера.

Рассмотрим пример расчета: если на сервере установлено 500 Гб ОЗУ, то лимит составит: 500 * 0,8 * 0,05 = 20 Гб. Если фоновое задание при формировании тяжелого отчета попытается выделить память, превышающую этот порог хотя бы на 1 байт, сервер 1С не просто прервет операцию, а переведет сеанс в состояние KillState. При этом в SQL-профайлере будет четко видна команда KILL [SPID], инициированная процессом rphost.

Влияние настроек отказоустойчивости на стабильность процессов

Выясним причину, по которой сервер может уничтожать целый рабочий процесс вместе со всеми пользователями. В настройках кластера существуют параметры: «Допустимое отклонение количества ошибок сервера» и «Принудительно завершать проблемные процессы». Разберем, как они работают в связке:

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


42:12.301043-0,ATTN,14,process=ragent,OSThread=7532,Descr=Process has generated too big amount of exceptions
42:12.301044-0,ATTN,14,process=ragent,OSThread=7532,Descr=Process will be killed,logOnly=0

Рекомендация: Для предотвращения «эффекта домино», когда одна ошибка пользователя валит весь rphost, установите параметр «Допустимое отклонение количества ошибок сервера» в значение 0. Это отключит механизм автоматического убийства процесса на основе статистики исключений.

Проблема I/O Freeze: Влияние бэкапов и снимков системы

Часто «убийство» процессов происходит ночью или в моменты создания резервных копий. Рассмотрим механизм взаимодействия 1С, SQL Server и службы VSS (Volume Shadow Copy). При создании Snapshot-бэкапа (например, средствами Veeam или встроенными средствами гипервизора) происходит кратковременная заморозка ввода-вывода (событие I/O is frozen в логах SQL Server).

В этот момент рабочий процесс 1С перестает отвечать на пинги менеджера кластера. По умолчанию rphost пингуется раз в секунду и ждет ответа 5 секунд. После трех неудачных попыток (суммарно 15 секунд) менеджер кластера (rmngr) считает процесс мертвым и отдает команду на его уничтожение. Однако заморозка дисков при бэкапе может длиться до 20–60 секунд.

Для решения этой проблемы необходимо увеличить таймаут опроса процессов. Рассмотрим настройку параметров запуска агента сервера 1С (ragent). Добавим ключ в строку запуска службы или файл конфигурации:

-pingTimeout 25000

Это увеличит время ожидания до 25 секунд на одну попытку (суммарно 75 секунд), что позволит процессам «пережить» период заморозки дисковой подсистемы.

Конфликты на уровне гипервизора и антивирусного ПО

Иногда процессы падают без видимых причин в ТЖ, оставляя записи только в системном журнале Windows (Event Viewer) с ошибками в модулях ntdll.dll или inet.dll. Разберем основные причины такого поведения:

Устаревшие драйверы: Ошибки в работе rmngr и rphost на виртуальных машинах могут быть связаны с драйверами чипсета или сетевых адаптеров гипервизора. Обновление компонентов интеграции (VMware Tools или Hyper-V Integration Services) часто решает проблему внезапных падений.
Антивирусная активность: Если на сервере установлен антивирус (например, Kaspersky), он может блокировать низкоуровневые запросы между ragent и rphost. Посмотрим на это с точки зрения безопасности: антивирус сканирует память процессов, что вызывает задержки, на которые сервер 1С реагирует как на зависание процесса. Необходимо добавить все бинарные файлы 1С (ragent.exe, rmngr.exe, rphost.exe) и каталоги данных (srvinfo) в исключения.

Режим совместимости и ошибки транзакций SQL

Разберем ситуацию, когда после принудительного разрыва соединения пользователи начинают получать ошибки "The COMMIT TRANSACTION request has no corresponding BEGIN TRANSACTION" или "cannot find the object #tt1". Это происходит потому, что 1С не всегда корректно обрабатывает разрыв сессии на уровне SQL-сервера и пытается продолжить работу в транзакции, которая уже откатилась, или обращается к временным таблицам, которые были удалены вместе с сессией.

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

Как провести диагностику самостоятельно

Чтобы точно определить причину «убийства» сеансов в вашей системе, настроим Технологический журнал для отслеживания событий жизненного цикла процессов. Проанализируем следующий файл logcfg.xml:


<config xmlns="http://v8.1c.ru/7.4/config/logcfg">
  <dump location="C:\Dumps" create="true" type="2"/>
  <log location="C:\LOGS\PROCESS_KILL" history="72">
    <event>
      <eq property="name" value="PROC"/>
    </event>
    <event>
      <eq property="name" value="ATTN"/>
    </event>
    <event>
      <eq property="name" value="EXCP"/>
    </event>
    <property name="all"/>
  </log>
</config>

Событие ATTN покажет нам причину, по которой агент или менеджер решили убить процесс (превышение памяти, отсутствие ответа), а событие PROC зафиксирует моменты запуска и остановки процессов с указанием конкретных ошибок (например, Bad cluster lock или Stopped by console).

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