Переход между масштабными редакциями типовых решений, в частности с 1С:ERP 2.1 на 1С:ERP 2.2, сопровождается кардинальной реструктуризацией данных: полностью перерабатываются механизмы партионного учета, производственный контур, взаиморасчеты и структуры регистров. В процессе запуска информационной базы в режиме «1С:Предприятие» после обновления конфигурации многие сталкиваются с критической ошибкой: «Аварийно завершился рабочий процесс фонового задания», после чего процесс на стороне сервера прерывается или сопровождается сообщением о нехватке памяти.
Разберем по шагам природу данной проблемы, выясним причины падения серверных процессов и рассмотрим проверенные технические пути ее устранения.
Проанализируем ситуацию, которая возникает на серверной стороне при попытке запуска процедуры обновления:
Блокировка регламентных заданий включена. Однако это блокирует запуск заданий исключительно по заданному расписанию. Прикладные процедуры обновления данных запускаются платформенно через вызов длительных операций (ФоновыеЗадания.Выполнить), игнорируя эту блокировку. Более того, БСП выполняет фоновое обновление параллельно в несколько потоков, создавая взрывной рост потребления ОЗУ.8.3.9 (в частности 8.3.9.1850) на 64-разрядных серверах имели нестабильную работу менеджера управления памятью при обработке многопоточных фоновых заданий, что приводило к сбою с кодом 0xC0000005 и аварийному падению процесса rphost.exe.rphost. При достижении параметров Критический объем памяти процессов или Безопасный расход памяти за один вызов процесс уничтожается операционной системой или самим кластером, прерывая активные потоки обновления.Рассмотрим первоочередное действие, позволившее решить проблему на практике. Если обновление ERP зависает на этапе сравнения/объединения или вылетает в фоновом режиме на ранних сборках 8.3.9, необходимо скорректировать версию платформы:
8.3.9.х выполним перенос информационной базы на проверенный стабильный релиз платформы (например, ветку 8.3.8 либо более поздние стабильные сервисные выпуски 8.3.10+, рекомендованные для конкретной сборки конфигурации).Когда в конфигурации запускается обновление данных, Библиотека стандартных подсистем пытается распараллелить обработчики на максимально возможное количество ядер процессора. Для высоконагруженных таблиц ERP это гарантированно приводит к пиковому расходу памяти рабочим процессом.
Переведем выполнение процедур обновления в строго последовательный однопоточный режим. Для этого выполним запуск клиентского приложения из командной строки с передачей специального параметра:
1cv8.exe ENTERPRISE /S "Server1C\erp_base" /C "ЗапуститьОбновлениеИнформационнойБазы;ЧислоПотоковОбновления=1"
Рассмотрим подробнее, что дает этот параметр: платформа отключает параллельное ветвление фоновых заданий БСП. Все обработчики выполняются поочередно в одном контексте, что многократно снижает риск переполнения памяти сервера и предотвращает аварийное завершение процесса.
Разберем параметры администрирования кластера 1С, которые могут принудительно убивать рабочий процесс при длительных операциях:
Временно допустимый объем памяти процессов в значение -1.Критический объем памяти процессов или снимите жесткие ограничения на период сервисных работ.Интервал превышения допустимого объема памяти процессов.Количество ИБ на один процесс на значение 1. Это позволит изолировать обновляемую базу в отдельном процессе rphost, исключив влияние соседних баз данных и выделив заданию максимальный пул ресурсов.Посмотрим на последовательность накатывания обновлений. Прямой переход с устаревших сборок редакции 2.1 на ранние сборки 2.2 может вызывать конфликт метаданных.
2.1.3.188 до 2.1.3.202 (или более позднего завершающего релиза 2.1).Расширения), так как несовместимость их структуры часто провоцирует падение процедур БСП на 50–60% выполнения.2.2.1.142 или 2.2.1.155).Выясним причину падения фоновых заданий со стороны СУБД: при массивных транзакциях реструктуризации часто переполняются файлы журналов транзакций и временная база tempdb.
Simple (Простая), чтобы журнал транзакций не разрастался до исчерпания свободного места на диске.tempdb: убедимся, что авторасширение (autogrowth) задано в фиксированных мегабайтах (а не в процентах), а на системном диске СУБД имеется достаточный запас дискового пространства.Если процесс фонового задания продолжает падать без детальных записей в стандартном Журнале регистрации, воспользуемся системными инструментами мониторинга:
Журналы Windows -> Приложение (Application). Найдем записи с источником Application Error, ассоциированные с процессом rphost.exe. Наличие кода исключения 0xc0000005 подтвердит ошибку обращения к памяти в текущей версии платформы.logcfg.xml в каталоге настроек платформы для сбора событий аварийных завершений:
<config xmlns="v8.1c.ru/v8/tech-log">
<log location="C:\Logs\1C" history="24">
<event>
<eq property="name" value="PROC"/>
</event>
<event>
<eq property="name" value="EXCP"/>
</event>
<property name="all"/>
</log>
</config>
События PROC и EXCP позволят зафиксировать момент гибели процесса и стек вызовов процедур, на которых завершилась работа фонового задания.