Как исправить ошибку 10054 и аварийное завершение рабочих процессов rphost в 1С?

← На главную

Сетевая ошибка Windows Sockets - 10054 (0x00002746): Удаленный хост принудительно разорвал существующее подключение является одним из наиболее распространенных симптомов нестабильной работы кластера серверов 1С:Предприятия. При возникновении этой проблемы пользователи внезапно теряют связь с информационной базой, а в системных журналах фиксируются перезапуски рабочих процессов rphost. Разберем по шагам, почему возникает данный сбой, как правильно локализовать его причину с помощью технологического журнала и какие настройки сервера позволяют полностью устранить падения.

Анализ механизма возникновения ошибки 10054

Сама по себе ошибка 10054 со стороны клиентского приложения или фонового задания означает лишь следствие: клиент пытался отправить или получить данные, но сокет был принудительно закрыт сервером. В подавляющем большинстве случаев это происходит из-за того, что рабочий процесс rphost, обслуживавший данное клиентское соединение, аварийно завершил свою работу (упал по критическому исключению в операционной системе).

Проанализируем основные источники сбоев, вызывающих крах процесса rphost:

Конфликт ресурсов при совместном размещении 1С и СУБД: завышенный приоритет потоков MS SQL Server монополизирует ресурсы процессора, вызывая тайм-ауты и сбои в обработке сетевых пакетов кластером 1С.
Сбои при выполнении тяжелых COM-соединений: ошибки при выгрузке и загрузке данных через comcntr.dll в адресном пространстве процесса 1С вызывают необрабатываемые исключения в модулях C++.
Переполнение адресного пространства процесса: при масштабных обменах данными через XML оперативная память может фрагментироваться, приводя к критической ошибке нехватки памяти (Out of Memory).
Сетевые тайм-ауты и сбросы сокетов: длительные синхронные вызовы между распределенными серверами могут разрываться сетевым оборудованием из-за неактивности канала.

Диагностика падений с помощью минимального технологического журнала

Для точного определения причин перезапуска процессов rphost настроим сбор технологического журнала с фиксацией аварийных дампов и системных исключений. Создадим в каталоге конфигурации технологического журнала файл logcfg.xml со следующей минимальной конфигурацией:


<config xmlns="http://v8.1c.ru/v8/tech-log">
    <dump create="true" location="C:\LOGS\dumps" prntscrn="false" type="0"/>
    <log location="C:\LOGS\techlog" history="24">
        <event>
            <eq property="name" value="EXCP"/>
        </event>
        <event>
            <eq property="name" value="PROC"/>
        </event>
        <property name="all"/>
    </log>
</config>

Параметр type="0" указывает платформе создавать мини-дампы аварийного завершения без включения полных сегментов оперативной памяти. Это предотвращает лавинообразное заполнение дискового пространства дамповыми файлами. По имени файла дампа и последним хронологическим записям события EXCP для соответствующего PID процесса можно выяснить конкретную строку программного кода или системный контекст, вызвавший падение.

Решение 1: Корректировка приоритета потоков в MS SQL Server

Если сервер 1С:Предприятия и СУБД MS SQL Server установлены на одной физической или виртуальной машине, критически важно проверить настройки распределения процессоров СУБД. По умолчанию или при ручной оптимизации администраторы нередко включают опцию повышения приоритета процесса SQL Server, что приводит к деградации и краху процессов 1С.

Выполним правильную настройку сервера баз данных:

Откроем SQL Server Management Studio (SSMS) и подключимся к экземпляру СУБД.
Нажмем правой кнопкой мыши на имя сервера и выберем Свойства (Properties).
Перейдем на вкладку Процессоры (Processors).
Найдем параметр Поддерживать приоритет SQL Server (Boost SQL Server priority) и снимем с него флаг.
На серверах с архитектурой NUMA снимем флаг автоматического назначения маски соответствия процессоров и вручную распределим ядра: оставим несколько ядер свободными под задачи операционной системы и службу сервера 1С.
Нажмем ОК и перезапустим службу MSSQLSERVER.

Важно: включенная опция повышения приоритета переводит процесс sqlservr.exe в режим приоритета реального времени (Priority 13), что лишает рабочий процесс rphost процессорного времени при пиковых нагрузках и приводит к разрыву сокетов клиентами.

Решение 2: Изоляция COM-соединений в отдельный процесс COM+

Когда в конфигурации выполняются регулярные обмены через COM-соединитель (например, универсальная выгрузка/загрузка XML данных), прямой вызов библиотеки comcntr.dll происходит непосредственно внутри адресного пространства rphost. Любое нарушение адресации памяти (Access Violation) или сбой сетевого сокета в сторонней базе мгновенно закрывает весь рабочий процесс 1С вместе со всеми подключенными пользователями.

Для защиты рабочих процессов вынесем COM-соединитель в изолированное серверное приложение COM+:

Откроем консоль Службы компонентов (выполним команду dcomcnfg).
Развернем ветку: Службы компонентов -> Компьютеры -> Мой компьютер -> Приложения COM+.
Создадим новое приложение, зададим имя (например, 1C_V8_COM) и укажем тип активации Серверное приложение (Server application).
Укажем учетную запись, от имени которой запускается служба сервера 1С.
В созданном приложении перейдем в ветку Компоненты (Components), выберем Создать компонент и укажем путь к библиотеке comcntr.dll из каталога bin установленной платформы 1С.

После этой настройки все COM-вызовы будут обрабатываться отдельным процессом dllhost.exe. В случае ошибки при обмене завершится только процесс COM-адаптера, а основной процесс rphost и пользовательские сессии продолжат стабильную работу.

Решение 3: Оптимизация сетевых параметров и алгоритмов обмена

При передаче больших объемов данных через распределенные узлы или COM-соединения необходимо пересмотреть логику выгрузки данных и системные параметры сетевого стека:

Порционная обработка данных: в обработках выгрузки ограничим размер пакета транзакции (например, порциями по 500–1000 объектов). После записи каждого пакета необходимо освобождать память, явно очищая ссылки и переменные соединений присваиванием значения Неопределено.
Отключение аппаратных разгрузок сети: функции сетевой карты, такие как Large Send Offload (LSO) и TCP Chimney Offload, при непрерывных потоках данных могут приводить к сбросу сетевых сокетов. Отключим их в свойствах сетевого адаптера или через командную строку:
```
netsh int tcp set global chimney=disabled
netsh int tcp set global rss=disabled
```
Корректировка тайм-аута Keep-Alive: чтобы промежуточное оборудование не разрывало длительно молчащие сокеты при формировании больших выборок, в ветке реестра HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters установим параметр KeepAliveTime (тип DWORD) равным 300000 (5 минут в миллисекундах).
Настройка автозапуска служб: если сервер регулярно перезагружается по расписанию, для службы 1C:Enterprise Server Agent установим тип запуска Автоматически (отложенный запуск) или настроим зависимость от службы MSSQLSERVER, чтобы исключить утренние сбои при старте кластера до инициализации СУБД.