При выполнении тяжелых регламентных операций, таких как "Распределение затрат и расчет себестоимости" в 1С:ERP 2.5, администраторы часто сталкиваются с критической ошибкой: "Аварийно завершился рабочий процесс фонового задания". Эта ситуация опасна тем, что расчет прерывается на полуслове, оставляя базу в неопределенном состоянии, а в журнале регистрации фиксируются исключительные ситуации. Чтобы понять, на каком этапе система дает сбой, рекомендуется предварительно выполнить замер производительности контура 1С и поиск узких мест — для этого подойдет инструмент для анализа производительности и ТЖ 1С. Разберем детально, почему это происходит и как настроить серверную часть для стабильной работы.
Когда процесс rphost завершается аварийно, первичная причина обычно кроется не в самой платформе 1С, а во взаимодействии с СУБД (MS SQL Server). Проанализируем типичную запись из технологического журнала, которая сопутствует этой проблеме:
Соединение с сервером баз данных разорвано администратором. Выполнение оператора KILL не привело к ошибке СУБД.
Эта запись говорит о том, что менеджер кластера 1С (процесс rmngr) или сам SQL Server принудительно разорвал соединение. Чаще всего это происходит из-за взаимоблокировок (deadlocks). В логах это выглядит как ошибка с кодом 1205: Транзакция (идентификатор процесса) вызвала взаимоблокировку ресурсов и стала жертвой взаимоблокировки.
Выясним причину: при расчете себестоимости система активно пишет данные в регистры, в частности в РегистрСведений.ЗаданияКФормированиюДвиженийПоНДС. Если несколько фоновых заданий пытаются одновременно модифицировать одни и те же таблицы, SQL Server выбирает одну транзакцию как "жертву" и завершает её, чтобы снять блокировку. Если это происходит некорректно, рабочий процесс 1С может упасть.
Одной из скрытых причин частых дедлоков является отключение возможности блокировки на уровне строк в индексах MS SQL Server. Если этот параметр (ALLOW_ROW_LOCKS) выключен, SQL Server вынужден блокировать целые страницы данных или всю таблицу целиком, что резко увеличивает вероятность конфликтов. Рассмотрим, как проверить состояние индексов.
Для начала выполним запрос в SQL Server Management Studio (SSMS), чтобы найти индексы, где строковые блокировки запрещены:
SELECT
A.Name AS IndexName,
ob.Name AS TableName
FROM sys.indexes A
LEFT OUTER JOIN sys.objects ob ON ob.object_id = A.object_id
WHERE ALLOW_ROW_LOCKS = 0
AND ob.type = 'U'
Если запрос вернул список индексов, значит, проблема найдена. Это могло произойти из-за некорректно настроенных планов обслуживания или сторонних скриптов оптимизации. Чтобы исправить ситуацию, нам необходимо включить строковые блокировки для всех индексов базы данных. Для этого воспользуемся следующим скриптом:
EXEC sp_MSforeachtable 'ALTER INDEX ALL ON ? SET (ALLOW_ROW_LOCKS = ON)'
После выполнения этой команды SQL Server получит возможность более гранулярно управлять блокировками, что значительно снизит количество взаимоблокировок при расчете партий и НДС.
Даже если у вас на сервере установлено 200 Гб ОЗУ, rphost может завершаться аварийно, если менеджер кластера посчитает, что процесс потребляет слишком много ресурсов. Разберем настройки рабочего сервера в консоли "Администрирование серверов 1С Предприятия" (здесь поможет инструмент для администрирования серверов 1С и управления сеансами):
rphost разрастается при расчете тяжелого месяца, он может быть принудительно завершен кластером.rphost и в нем работают все пользователи, то его падение прерывает работу всех. Установите значение 20-25 соединений на один процесс. Для мониторинга состояния серверных ресурсов в этот момент будет полезен детализированный менеджер задач 1С при участии PowerShell. Это позволит кластеру распределять нагрузку и создавать новые процессы динамически.Взаимоблокировки при записи в ЗаданияКФормированиюДвиженийПоНДС часто провоцируются избыточным параллелизмом SQL Server. Когда один запрос пытается выполниться на всех ядрах процессора сразу, он может заблокировать сам себя или соседние потоки того же задания.
Посмотрим на параметр Max Degree of Parallelism (MAXDOP) в свойствах SQL Server. Для баз данных 1С эксперты рекомендуют следующие значения:
Расчет себестоимости активно использует временные таблицы. Для детального анализа того, что происходит внутри этих таблиц, можно использовать специальное расширение для просмотра временных таблиц при закрытии месяца. Если база tempdb расположена на медленном диске или состоит из одного файла при большом количестве ядер, это создает "узкое горлышко". Проанализируем состояние tempdb: рекомендуется разделить её на несколько файлов (обычно 8) одинакового начального размера.
Также стоит обратить внимание на объект РегистрСведений.ЗаданияКФормированиюДвиженийПоНДС. Если расчет себестоимости падает именно на нем, выполним следующие действия:
Обратим внимание на используемый драйвер. В тексте ошибки часто фигурирует Microsoft SQL Server Native Client 11.0. Этот драйвер является устаревшим. Для современных версий платформы 8.3.22/8.3.23 и выше на операционных системах Windows Server 2016+ рекомендуется перейти на Microsoft OLE DB Driver for SQL Server (MSOLEDBSQL). Это повышает стабильность сетевых соединений и лучше обрабатывает разрывы сессий.
Резюмируем: Для устранения ошибки "Аварийно завершился рабочий процесс" необходимо действовать комплексно. Сначала включаем ALLOW_ROW_LOCKS в SQL, затем проверяем лимиты памяти в консоли 1С, и в завершение оптимизируем MAXDOP и драйверы подключения. Это обеспечит стабильное закрытие месяца даже на очень больших объемах данных.