При работе в программе 1С:Зарплата и управление персоналом (редакция 3.1) пользователи часто сталкиваются со стабильными падениями рабочих процессов при выполнении групповых рассылок расчетных листков. Ситуация обычно усугубляется после обновления конфигурации или платформы. Внезапно фоновые задания аварийно завершаются, система выдает невнятные сообщения, связанные со свойствами XDTO, а замер производительности после вылета базы оказывается абсолютно пустым.
В этой статье мы подробно разберем, почему происходят подобные сбои, проанализируем внутренние механизмы платформы 1С, приводящие к падению, и рассмотрим пошаговые инструкции по устранению данной проблемы.
Для начала проанализируем техническую сторону процесса. Когда запускается рассылка расчетных листков, программа выполняет целый комплекс ресурсоемких операций:
Вся эта цепочка действий ложится на плечи фонового задания, которое выполняется в рамках рабочего процесса rphost на сервере приложений 1С. Существует три главные причины, по которым этот процесс может аварийно завершиться:
1. Ошибки сериализации и Фабрики XDTO (Баги платформы)
В версиях платформы 8.3.13 и 8.3.14 (а также в некоторых релизах ветки 8.3.15) присутствовал критический баг. При использовании расширений конфигурации пакеты XDTO периодически «терялись» из глобального контекста. В момент, когда фоновое задание пыталось передать данные между сервером и клиентом, возникала ошибка десериализации («Несоответствие свойства и элемента данных XDTO»). Из-за этого платформа не могла корректно завершить поток и аварийно закрывала весь рабочий процесс.
2. Превышение лимитов оперативной памяти в кластере серверов
Поскольку перед отправкой 1С формирует документы в памяти, при рассылке на сотни и тысячи сотрудников потребление ОЗУ процессом rphost лавинообразно растет. Если в настройках кластера серверов 1С заданы жесткие ограничения на допустимый объем памяти (что стандартно для многих серверных конфигураций), то менеджер кластера (процесс rmngr) принудительно убивает «прожорливый» поток. Пользователь при этом видит сообщение «Аварийно завершился рабочий процесс фонового задания».
3. Передача «тяжелого» клиентского контекста
В типовых механизмах Библиотеки Стандартных Подсистем (БСП) вызовы длительных операций часто осуществляются через функцию ДлительныеОперации.ВыполнитьСКонтекстомКлиента. На старых версиях платформы передача тяжелого контекста формы в фоновое задание вызывала переполнение стека или утечку памяти на стороне сервера, что также приводило к моментальному падению клиента.
---
Если в вашей информационной базе установлены расширения, они могут искажать контекст фабрики XDTO на сервере. Давайте проверим наши расширения на соответствие правилам препроцессора.
Откроем конфигуратор и перейдем в меню Конфигурация — Расширения конфигурации. Особое внимание следует обратить на те расширения, которые заменяют или дополняют логику общих модулей. Убедимся, что все серверные вызовы корректно обрамлены инструкциями препроцессора. Например, модуль должен начинаться с проверки доступности контекста:
#Если Сервер Или ТолстыйКлиентОбычноеПриложение Или ВнешнееСоединение Тогда
Процедура ПередЗаписьюРасчетногоЛистка(Источник, Отказ) Экспорт
// Здесь располагается логика обработки данных на стороне сервера
КонецПроцедуры
#КонецЕсли
Если в расширениях используются методы, предназначенные только для работы на стороне клиента, без соответствующих директив компиляции, сервер 1С при попытке скомпилировать фоновое задание упадет с ошибкой XDTO. В качестве диагностического теста рекомендуется временно отключить все расширения в базе и запустить рассылку заново.
---
Обычная очистка локального кэша пользователя (удаление папок в AppData/Local/1C) в данном случае не поможет, так как фоновые задания выполняются от имени системного пользователя сервера 1С:Предприятия. Нам потребуется очистить кэш на стороне сервера.
Выполним процедуру очистки по шагам:
services.msc). Служба обычно называется "Agent 1C:Enterprise 8.3".C:\Program Files\1cv8\srvinfo\ (или аналогичный путь на вашем сервере).reg_1541).snccntx. В ней хранятся сеансовые данные и кэш конфигурации метаданных.snccntx, а также все временные папки с именами-идентификаторами (UID) в каталоге сервера.Очистка серверного кэша заставит платформу заново пересобрать фабрику XDTO при первом обращении, что исключит фантомные ошибки сериализации.
---
Если падения продолжаются, нам необходимо оптимизировать параметры расхода памяти процессами 1С. Откроем Консоль администрирования серверов 1С:Предприятия и проанализируем настройки нашего кластера:
0 (без ограничений), чтобы проверить, прекратятся ли вылеты.86400 секунд (раз в сутки), чтобы память своевременно освобождалась операционной системой.180 секунд. Это позволит плавно завершать старые процессы rphost, освобождая ресурсы под новые фоновые задачи рассылки.---
Если обновить платформу прямо сейчас нет возможности, а отправку расчетных листков нужно выполнить срочно, применим метод порционной отправки. Платформа захлебывается, когда пытается обработать весь массив сотрудников единовременно.
Рассмотрим, как разделить задачу на шаги:
rphost гарантированно уложится в лимиты памяти и успеет корректно закрыть соединение до того, как сработает механизм очистки кластера.---
Поскольку ошибки сериализации фабрики XDTO и падения при использовании метода ДлительныеОперации.ВыполнитьСКонтекстомКлиента признаны зарегистрированными ошибками технологической платформы (в частности, баг 000021194), единственным долгосрочным решением является обновление платформы 1С.
Практика администрирования показывает, что стабильная работа механизмов рассылки и XDTO-пакетов без внезапных падений гарантируется на релизах платформы начиная с веток 8.3.15.2107, 8.3.16.1814 и выше. При обновлении платформы не забывайте также обновить конфигурацию 1С:ЗУП до актуального релиза, так как новые версии конфигураций оптимизированы под обновленные требования к сериализации объектов платформой.