Почему виснет 1С после обновления конфигурации и как решить проблему с падением rphost?

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

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

Шаг 1. Локализация проблемы: проверка в файловом режиме

Для того чтобы понять, кроется ли причина в коде обновленной конфигурации или в клиент-серверном взаимодействии с СУБД (PostgreSQL или MS SQL Server), необходимо локализовать источник сбоя. Проанализируем базовый алгоритм проверки:

1. Выполним выгрузку информационной базы в файл с расширением .dt через Конфигуратор (меню Администрирование — Выгрузить информационную базу).
2. Развернем полученную выгрузку в файловом режиме на локальном компьютере или тестовом сервере.
3. Протестируем выполнение типовых операций несколькими пользователями.

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

Шаг 2. Временное отключение регламентных и фоновых заданий

Одной из наиболее частых причин блокировок и критической нагрузки на процессор после обновления является запуск фоновых процедур. В частности, после обновления типовых решений могут запускаться процедуры отложенного обновления данных или регулярный полнотекстовый поиск.

Разберем, как заблокировать выполнение регламентных заданий:

1. Откроем консоль Администрирование серверов 1С Предприятия.
2. Найдем нужную информационную базу в дереве кластера и откроем ее свойства.
3. Установим флаг Блокировка регламентных заданий включена и сохраним изменения.

Если после этого зависания прекратились, включим блокировку обратно и выполним выборочный запуск заданий через обработку Регламентные и фоновые задания в пользовательском режиме, чтобы определить конкретную процедуру, вызывающую сбой.

Шаг 3. Завершение отложенных процедур обновления данных

В современных конфигурациях 1С после обновления основной конфигурации запускаются фоновые обработчики отложенного обновления данных. Если в системе накопился большой объем информации, эти процедуры могут непрерывно выполнять тяжелые запросы в фоне.

Выясним состояние обновления и завершим его:

1. Зайдем в программу с правами администратора.
2. Перейдем в раздел Администрирование — Обслуживание — Результаты обновления программы.
3. Если присутствуют невыполненные процедуры, запустим их выполнение вручную в монопольном режиме без присутствия остальных пользователей.

Шаг 4. Настройка автоматического перезапуска рабочих процессов кластера

Если процесс rphost.exe зависает из-за постепенной утечки памяти или фрагментации адресного пространства, настроим параметры кластера для плавного пересоздания рабочих процессов без участия администратора:

1. В консоли управления кластером 1С откроем свойства центрального сервера или рабочего сервера.
2. Зададим параметр Допустимый объем памяти, при достижении которого процесс перестанет принимать новые сеансы.
3. Установим Интервал перезапуска (например, 86400 секунд для ежедневного обновления процессов).
4. Настроим параметр Интервал превышения допустимого объема памяти, чтобы сервер автоматически завершал застрявшие процессы после переноса сеансов на новый рабочий процесс.

Шаг 5. Обновление статистики и обслуживание СУБД

При обновлении конфигурации меняется структура таблиц и индексов. Устаревшая статистика СУБД приводит к тому, что оптимизатор запросов выбирает неэффективные планы выполнения, из-за чего возникают длительные взаимные блокировки.

Для базы под управлением PostgreSQL выполним сервисные команды в консоли СУБД:

1. Запустим обновление статистики и очистку неиспользуемых страниц командой: VACUUM FULL ANALYZE;
2. Выполним переиндексацию таблиц: REINDEX DATABASE name_db;

Для баз на MS SQL Server выполним регламентные процедуры через SQL Server Management Studio:

1. Обновим статистику по всем таблицам базы данных командой: EXEC sp_updatestats;
2. Выполним реорганизацию и реиндексацию всех индексов базы данных.

Шаг 6. Диагностика с помощью Технологического журнала

Если предложенные шаги не дали полного результата, проанализируем поведение системы с помощью Технологического журнала 1С. Для этого создадим файл tjconfig.xml в каталоге bin/conf установленной платформы со следующим содержимым:

<config xmlns="http://v8.1c.ru/v8/tech-log">
	<log location="C:\LOGS_1C" history="24">
		<event>
			<eq property="Name" value="EXCP"/>
		</event>
		<event>
			<eq property="Name" value="LOCK"/>
		</event>
		<event>
			<eq property="Name" value="DEADLOCK"/>
		</event>
	</log>
</config>

Сбор логов за период зависания и анализ событий LOCK, DEADLOCK и EXCP поможет точечно определить модуль или запрос к СУБД, приводящий к остановке работы кластера.