Почему самопроизвольно перезапускается рабочий процесс в 1С 8.3 и как это исправить

← На главную

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

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

Причины самопроизвольного перезапуска рабочих процессов

Проанализируем ключевые факторы, приводящие к перезапуску процессов rphost менеджером кластера или операционной системой:

Некорректно заданные параметры обслуживания в консоли кластера. В свойствах кластера предусмотрены параметры планового перезапуска, а также лимиты по объему оперативной памяти. Если процесс достигает установленного порога или срабатывает внутренний таймер, менеджер кластера rmngr принудительно останавливает рабочий процесс.
Ограничения разрядности платформы (32-разрядный сервер). Если служба сервера 1С работает в 32-битном режиме, адресное пространство одного процесса ограничено объемом до 2–3 ГБ. При выполнении тяжелых операций (например, компиляция и сохранение метаданных в конфигураторе) процесс мгновенно упирается в ограничение по памяти и аварийно «падает».
Сбои в нативных библиотеках и ошибки доступа к памяти. Исключение Access Violation (код 0xC0000005) возникает из-за некорректной работы драйверов оборудования, внешних компонент защиты, криптографии либо багов конкретного релиза платформы 1С.
Повреждение таблиц конфигурации в базе данных. При частом применении динамического обновления без монопольного захвата базы в таблицах Config и ConfigSave на стороне MS SQL Server могут возникнуть логические несоответствия, провоцирующие падение процесса при попытке фиксации изменений.
Активность ресурсоемких регламентных заданий. Фоновые задачи, выполняющие неоптимальные выборки или обработку сотен тысяч записей, вызывают утечку памяти или лавинообразную нагрузку на рабочий процесс.

Шаг 1. Корректировка параметров кластера серверов

Рассмотрим первоочередные настройки в консоли администрирования серверов 1С:Предприятия, которые исключат плановые перезапуски по таймерам и объемам:

Откроем консоль администрирования кластера и перейдем в свойства локального кластера.
Проверим значение параметра «Интервал перезапуска». Если требуется полностью исключить принудительный перезапуск процессов по расписанию, установим значение 0.
Параметр «Останавливать выключенные процессы через» также установим в значение 0.
Проверим лимиты оперативной памяти. Установим параметры «Допустимый объем памяти» и «Интервал превышения допустимого объема памяти» в значение 0 (лимит снят).
Перейдем в свойства рабочего сервера. В платформе 8.3 распределение нагрузки выполняется автоматически. Чтобы распределить тяжелые вызовы между несколькими процессами, можно скорректировать параметры «Количество ИБ на процесс» и «Количество соединений на процесс», что вынудит кластер создать дополнительные рабочие процессы rphost.

Шаг 2. Настройка технологического журнала для выявления краха

Выясним причину падения процесса с помощью технологического журнала платформы 1С. Для этого создадим конфигурационный файл logcfg.xml в каталоге настроек платформы (для 64-битной версии: C:\Program Files\1cv8\conf\logcfg.xml):


<config xmlns="http://v8.1c.ru/v8/tech-log">
  <log location="C:\1C_Logs" history="24">
    <event>
      <eq property="name" value="EXCP"/>
    </event>
    <event>
      <eq property="name" value="PROC"/>
    </event>
    <event>
      <eq property="name" value="ATTN"/>
    </event>
    <property name="all"/>
  </log>
</config>

Проанализируем собранные события после очередного сбоя:

Событие PROC регистрирует запуск, остановку и удаление процессов операционной системой или кластером.
Событие EXCP покажет исключительные ситуации, ошибки работы с памятью и стек вызовов, на котором произошло аварийное прерывание.
Событие ATTN зафиксирует критические предупреждения менеджера кластера.

Шаг 3. Анализ журналов операционной системы Windows

Если в технологическом журнале зафиксировано получение команды на завершение работы от операционной системы, обратимся к журналу событий Windows (Event Viewer):

Перейдем в раздел «Журналы Windows» -> «Приложение» (Application).
Найдем записи с уровнем «Ошибка» и источником «Application Error» (Event ID 1000).
Посмотрим на имя сбойного приложения: если указан rphost.exe, обратим внимание на поле «Имя сбойного модуля» (Faulting module name). Например, падение в библиотеке backend.dll или dbmsql.dll сигнализирует об ошибке платформы при работе с запросами к СУБД.
Проверим код исключения: значение 0xc0000005 подтверждает нарушение прав доступа при чтении или записи оперативной памяти.

Шаг 4. Устранение логических повреждений и очистка кэша

Разберем по шагам регламентные операции для очистки временных данных и восстановления структуры метаданных:

Очистка серверного кэша. Остановим службу 1C:Enterprise 8.3 Server Agent. Перейдем в каталог данных кластера (каталог srvinfo). Очистим папки контекстных данных и временных файлов сеансов (директории вида snccntx*), после чего запустим службу заново.
Очистка локального кэша конфигуратора. На рабочей машине разработчика удалим каталоги пользовательского кэша в папках AppData\Local\1C\1cv8 и AppData\Roaming\1C\1cv8.
Проверка целостности базы средствами MS SQL. Выполним монопольную проверку логической и физической структуры таблиц, выполнив запрос в Management Studio: DBCC CHECKDB ('ИмяБазы') WITH NO_INFOMSGS, ALL_ERRORMSGS;
Тестирование через выгрузку в информационную базу. Выполним резервное копирование средствами СУБД. Затем выгрузим конфигурацию и данные через конфигуратор в файл .dt и загрузим в чистую тестовую базу. Этот шаг позволяет пересобрать таблицы метаданных и исключить накопившиеся ошибки динамических обновлений.
Исключение динамических обновлений. Запретим обновление конфигурации базы данных при активных пользовательских сеансах. Все изменения структуры метаданных следует вносить исключительно в монопольном режиме.

Шаг 5. Обновление платформы и контроль разрядности

Проанализируем технические требования: ранние сборки ветки 8.3.10 содержат известные платформенные ошибки взаимодействия с MS SQL Server 2014, выражающиеся в утечках памяти процессов. Рекомендуется:

Убедиться, что на сервере развернута 64-разрядная версия сервера «1С:Предприятия» (x86-64), снимающая лимит в 2 ГБ памяти на один рабочий процесс.
Обновить платформу на стабильный релиз более поздней сборки.
Временно отключить фоновое сканирование каталогов кластера антивирусным ПО и исключить каталоги srvinfo и каталоги СУБД из проверок в реальном времени.