Каждый администратор систем 1С:Предприятие рано или поздно сталкивается с ситуацией, когда стабильно работавший годами обмен данными внезапно начинает давать сбой. Особенно часто это происходит после обновления технологической платформы. В этой статье мы подробно разберем одну из самых неприятных и трудноуловимых ошибок — «Аварийно завершился рабочий процесс фонового задания» при синхронизации конфигураций «Управление торговлей» (УТ) и «Бухгалтерия предприятия» (БП), а также при других обменах (например, ЗУП и БП).
Выясним причины, почему падает рабочий процесс rphost, проанализируем поведение системы при превышении лимитов памяти, рассмотрим влияние известных багов платформы 8.3.16 и выработаем пошаговый алгоритм устранения этой неисправности.
Для начала давайте разберемся в механике работы кластера 1С:Предприятия. Когда запускается фоновое задание синхронизации данных, за его выполнение отвечает рабочий процесс сервера — rphost. Если в ходе выполнения задачи процесс внезапно закрывается, менеджер кластера (rmngr) фиксирует аварийное завершение и выдает пользователю соответствующее сообщение.
Проанализируем основные причины резкого сброса рабочего процесса:
rphost ограничен лимитом адресного пространства в 2-3 гигабайта. Любая сложная операция выгрузки/загрузки легко упирается в этот потолок, вызывая крах процесса.Давайте рассмотрим комплекс мер, которые помогут гарантированно локализовать и устранить падение фоновых заданий при синхронизации.
Если база данных имеет долгую историю развития и создавалась на старых релизах платформы, при переходе на новые версии (например, с 8.3.13 на 8.3.16) физическая структура таблиц может начать конфликтовать с новыми алгоритмами платформы. Обычное обновление конфигурации здесь не поможет. Требуется провести полную реструктуризацию таблиц.
Разберем алгоритм выполнения этой процедуры:
.dt. Никакие регламентные работы не должны начинаться без актуального бэкапа!Существует еще один крайне эффективный метод «оздоровления» базы данных — выполнение полного цикла выгрузки-загрузки. Для этого выгрузите базу в файл .dt, создайте абсолютно новую пустую базу данных на сервере и загрузите полученный файл туда. Этот метод полностью перестраивает внутренние индексы СУБД и удаляет возможный логический мусор из структуры таблиц.
Как показывает практика эксплуатации платформ линейки 8.3.16 (особенно релизов 8.3.16.1063 и 8.3.16.1148), в них содержатся системные ошибки работы с сериализацией XML и утечкой памяти COM-соединений при обмене данными. Если вы используете эти версии, любые настройки кластера могут оказаться малоэффективными.
Рекомендуется выполнить обновление платформы 1С:Предприятие на сервере и на рабочих станциях клиентов до более стабильных и современных релизов, где эти баги были устранены (например, ветки 8.3.17.2231, 8.3.18.1483 или актуальные версии 8.3.21+).
Если обновление платформы временно невозможно по организационным причинам, мы можем минимизировать падения процессов путем тонкой настройки параметров кластера в консоли администрирования серверов 1С.
Проанализируем следующие параметры рабочего сервера:
rphost до аварийного падения.Иногда падение фонового процесса провоцируется не самой платформой 1С, а зависанием запросов на уровне СУБД. При обработке обмена СУБД может выбрать неоптимальный план запроса из-за устаревшей статистики индексации, что приведет к бесконечному ожиданию, росту потребления ресурсов и последующему принудительному завершению со стороны кластера 1С.
Необходимо настроить регулярные регламентные операции на стороне СУБД:
UPDATE STATISTICS).VACUUM ANALYZE).Если вышеописанные шаги не помогли, необходимо точно выяснить причину аварии с помощью встроенного инструмента диагностики — Технологического журнала (ТЖ) 1С. Мы можем настроить его таким образом, чтобы фиксировать только моменты падения процессов и исключения.
Для этого в каталоге с установленной платформой (обычно это C:\Program Files\1cv8\conf\ на сервере) необходимо создать файл конфигурации logcfg.xml следующего содержания:
<config xmlns="http://v8.1c.ru/v8/tech-log">
<log location="C:\1c_logs\rphost_crashes" history="48">
<event>
<eq property="Name" value="EXCP"/>
</event>
<event>
<eq property="Name" value="PROC"/>
</event>
<property name="all"/>
</log>
</config>
После создания этого файла платформа начнет автоматически записывать логи в указанную директорию. Перед самым падением процесса rphost в логах события EXCP будет зафиксирована конкретная ошибка СУБД, обращение к памяти или дефектный кусок кода конфигурации, приведший к сбою.
Аварийное завершение процессов при синхронизации — это комплексная проблема, которая чаще всего решается либо обновлением платформы 1С, либо лечением структуры самой базы данных путем реструктуризации и выгрузки в .dt. Систематическое обслуживание СУБД и контроль параметров кластера серверов позволят вам навсегда забыть об этой проблеме и обеспечить бесперебойную работу пользователей.