Почему постоянно перезапускается и создается новый процесс rphost.exe

Ситуация, когда рабочие процессы 1С (rphost.exe) начинают массово перезапускаться, «плодиться» в большом количестве или аварийно завершаться, является критической для стабильной работы предприятия. Особенно часто это проявляется после обновления платформы (например, на ветку 8.3.15) или изменения топологии кластера. Пользователей начинает «выкидывать» из системы, длительные операции прерываются, а мониторинг фиксирует недоступность портов. В этой статье мы подробно разберем, как проанализировать ситуацию, выявить виновника и стабилизировать работу сервера 1С:Предприятия.

Анализ симптомов и первичная диагностика

Рассмотрим типичную картину проблемы: после перехода на новый релиз платформы количество процессов rphost.exe резко возрастает (например, с 2–3 больших до 15–30 маленьких), при этом их объем оперативной памяти не превышает 1–2 Гб. Параллельно с этим могут наблюдаться ошибки связи с сервером и жалобы пользователей на нехватку прав или обрывы соединений. Прежде всего, проанализируем влияние внешних факторов.

Влияние систем мониторинга (Zabbix и аналоги): Часто администраторы настраивают мониторинг доступности порта (например, 1560), просто «слушая» его TCP-запросы. В платформе 8.3.15 механизмы работы с сетевыми сокетами были оптимизированы, и некорректные или «пустые» запросы от систем мониторинга могут приводить к подвисанию потоков внутри rphost.exe. Это вызывает срабатывание внутренних тайм-аутов кластера и принудительный перезапуск процесса.

Настройка Технологического журнала для поиска причин падения

Чтобы понять, почему процесс завершается с ошибкой Stopped on error (working), нам необходимо собрать подробные данные. Разберем, как правильно настроить файл logcfg.xml. Нам важны события завершения процессов (PROC) и исключительные ситуации (EXCP).

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

<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="http://v8.1c.ru/v8/tech-log">
  <dump create="true" location="C:\Logs\Dumps" type="3" prntscrn="false"/>
  <log location="C:\Logs\v8_logs" history="24">
    <event>
      <eq property="name" value="PROC"/>
    </event>
    <event>
      <eq property="name" value="EXCP"/>
    </event>
    <property name="all"/>
  </log>
</config>

Важные замечания по настройке:

1. Дампы (dump): Убедимся, что параметр create="true" активен. Это позволит 1С создать файл дампа в момент падения процесса, который затем можно отправить в техподдержку.
2. Событие EXCP: Позволяет увидеть текст ошибки непосредственно перед падением. Например, критическую ошибку 'src\SrvrInfoBaseImpl.cpp(9344): На сервере 1С:Предприятия произошла неисправимая ошибка'.
3. Событие PROC: Зафиксирует сам факт остановки процесса и его параметры.

Проблема внешней компоненты печати штрихкодов

Выясним одну из наиболее частых причин нестабильности — использование устаревших внешних компонент. В типовых конфигурациях (ERP, УТ, ЗУП) часто используется компонента для формирования штрихкодов. Если она имеет старую версию (ниже 9.0.6.x), она может вызывать критические сбои в адресном пространстве rphost.exe.

Проанализируем шаги по исправлению:

1. Скачаем актуальную версию «1С:Библиотека подключаемого оборудования» (БПО).
2. Найдем в составе БПО новую версию компоненты печати штрихкодов (например, 9.0.12.x).
3. Обновим компоненту в информационной базе. В новых версиях используется технология Native API, которая работает гораздо стабильнее старых COM-объектов и реже приводит к краху рабочего процесса.

Очистка параметров кластера в файле 1CV8Clst.lst

При переходе между версиями (например, с 8.3.14 на 8.3.15) параметры в файле конфигурации кластера могут «залипнуть» в некорректном состоянии. Это связано с тем, что в новых релизах некоторые настройки (например, связанные с КОРП-лицензиями) были переработаны или удалены из интерфейса, но остались в файле.

Рассмотрим, как это исправить вручную (внимание: перед редактированием обязательно остановите службу 1C:Enterprise 8.3 Server Agent):

1. Перейдем в каталог srvinfo (по умолчанию C:\Program Files\1cv8\srvinfo).
2. Найдем файл 1CV8Clst.lst в папке вашего кластера (например, reg_1541).
3. Проанализируем структуру параметров рабочего сервера. Иногда требуется сбросить значения в строке описания сервера, заменив лишние единицы на нули, чтобы убрать принудительные ограничения, которые некорректно интерпретируются платформой ПРОФ.

Пример строки из файла, где параметры были сброшены для стабильности:

{15030fd8-168f-4254-a02a-dc32fc85a6a8,"Рабочий сервер",1541,"SRV-NAME",0,0,0,0,0,0,0}

Известные ошибки платформы (Баг 40000903)

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

Симптомы бага 40000903:

• Аварийное завершение происходит спонтанно, часто при выполнении фоновых заданий.
• В технологическом журнале перед падением нет специфических 1С-ошибок, только системные исключения Access Violation.
• Проблема чаще проявляется в кластерах из нескольких серверов.

Рекомендации по выбору стабильной версии

Если ваша конфигурация требует версию не ниже 8.3.14.1976 или 8.3.15, а текущий релиз ведет себя нестабильно, проанализируем варианты решения:

1. Откат на стабильную ветку 8.3.14: Релиз 8.3.14.1854 и выше считается одним из самых стабильных для систем на базе ERP и ЗУП, где исправлены основные утечки памяти и проблемы с лицензированием.
2. Переход на более новые ветки: Если платформа 8.3.15 критична, стоит рассматривать только финальные сборки этой ветки или сразу переходить на 8.3.16.1063 и выше, где было исправлено огромное количество ошибок управления процессами, накопленных в 15-й версии.
3. Настройка перезапуска: В консоли администрирования кластера для рабочих процессов временно установите параметр Допустимый объем памяти и Интервал превышения допустимого объема памяти. Это позволит платформе перезапускать процессы более «цивилизованно», не дожидаясь их аварийного падения, хотя и не решит коренную проблему.

Подведем итог: Борьба с падениями rphost.exe — это всегда комплекс мер. Начните с отключения агрессивного мониторинга портов, обновите внешние компоненты и, если технологический журнал подтверждает неустранимую ошибку платформы, запланируйте переход на проверенный релиз (8.3.14.1854+ или старшие сборки 8.3.16).