Работа в современных конфигурациях на платформе 1С:Предприятие 8.3, таких как 1С:Комплексная автоматизация 2.5 или ERP 2.5, часто сопровождается активным использованием фоновых и регламентных заданий. Это позволяет вынести тяжелые расчеты в отдельный поток, не прерывая работу пользователя. Однако на практике возникают ситуации, когда фоновое задание «зависает», потребляет аномально много ресурсов и блокирует работу оперативных документов, например, Заказ поставщику. Проанализируем, почему это происходит и как с этим бороться.
Рассмотрим типовой сценарий: регламентное задание Автоматическое отражение документов в регламентированном учете выполняется бесконечно долго. При этом в консоли кластера серверов мы видим, что объем данных, полученных из информационной базы этим сеансом, исчисляется гигабайтами, а блокировки мешают пользователям проводить новые документы. Выясним причину такого поведения.
В КА 2.5 и ERP механизмы отражения работают через специальную очередь. Если в системе есть документ, который по какой-то причине не может быть отражен (например, из-за попытки изменения данных в закрытом периоде), фоновое задание может раз за разом пытаться его обработать, «спотыкаясь» о проверку даты запрета редактирования. Это создает бесконечный цикл обращений к базе данных.
Проанализируем пример из практики: программа пытается отразить документ Приобретение услуг и прочих активов в открытом периоде, но при этом система инициирует сторнирование или корректировку движений старого документа (например, Корректировка регистров за прошлый год). Если общая дата запрета редактирования установлена позже даты этой корректировки, фоновое задание не сможет завершить транзакцию и будет удерживать блокировки на таблицах регистров сведений и накопления.
Для эффективного решения проблемы нам необходимо точно определить, какое именно задание держит блокировку. Рассмотрим пошагово методы диагностики, выходящие за рамки стандартных инструментов:
TLOCK. Это самый надежный способ увидеть контекст исполнения кода на языке 1С в момент возникновения блокировки. В файле настроек logcfg.xml укажем следующие параметры:
<config xmlns="http://v8.1c.ru/7.4/config/log">
<log location="/var/log/1c/tlock" history="24">
<event>
<eq property="Name" value="TLOCK"/>
<gt property="Duration" value="5000000"/> <!-- Блокировки более 5 секунд -->
</event>
<property name="all"/>
</log>
</config>
Анализируя полученные логи, мы увидим стек вызовов, который привел к установке блокировки, и сможем понять, на каком объекте метаданных происходит конфликт (оперативно выяснить это также позволяет обработка Блокировка объекта).
Проанализируем техническую особенность работы платформы 8.3.27 в связке с RDP-сессиями. При резком обрыве связи RDP-сеанс завершается, но сеанс в 1С может перейти в состояние «спящего». Если в этот момент выполнялся серверный вызов, инициированный клиентским кодом (через обработчик ожидания), фоновое задание может стать неуправляемым. Такие процессы продолжают удерживать транзакции СУБД, что приводит к блокировке документа Заказ поставщику и других объектов.
В подобных случаях рекомендуется принудительно завершать такие сеансы через консоль администрирования кластера 1С или используя детализированный менеджер задач (процессов) 1С с поддержкой PowerShell, предварительно зафиксировав их влияние на нагрузку сервера.
Как показывает практика, многие труднообъяснимые ошибки, когда один пользователь может провести документ, а другой (с теми же правами) — нет, решаются полной очисткой кэша. Это связано с тем, что платформа может некорректно кэшировать метаданные или планы запросов. Посмотрим, как правильно выполнить очистку для всех пользователей:
%AppData%\1C\1cv8\%LocalAppData%\1C\1cv8\Agent 1C:Enterprise.В рассматриваемом нами случае именно массовая очистка кэша позволила устранить «глюки» с отражением в учете после того, как все логические причины были проверены.
Если регламентное задание по отражению в учете продолжает зависать, разберем состояние регистра сведений Очередь документов для отражения в регламентированном учете. Проанализируем наличие в нем старых записей. Если в очереди «висят» документы за прошлые годы, которые невозможно отразить из-за даты запрета, фоновое задание будет постоянно перечитывать их, увеличивая объем передаваемых данных (тот самый 1 Гб+ в консоли).
Рекомендация: Очистите очередь от заведомо ошибочных или старых записей. Это можно сделать либо программно, либо временно открыв период для исправления и повторного отражения «проблемных» документов (для КА 2 также может быть актуально исправление ошибки в закрытии месяца со статусом «Ожидает подтверждения отражения»).
Выясним, как настройки MS SQL Server могут помочь в данной ситуации. Одним из наиболее эффективных способов борьбы с блокировками между читающими и пишущими процессами является включение режима Read Committed Snapshot (RCSI).
Рассмотрим, как это работает: при включенном RCSI читающие запросы (например, фоновое задание по отражению в учете) не блокируются пишущими транзакциями (проведение заказа поставщику), так как получают версию данных на момент начала транзакции из tempdb. Это существенно повышает параллельность работы системы.
Для включения этого режима выполните следующий SQL-запрос (база должна быть в однопользовательском режиме):
ALTER DATABASE [ИмяВашейБазы] SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
ALTER DATABASE [ИмяВашейБазы] SET READ_COMMITTED_SNAPSHOT ON;
ALTER DATABASE [ИмяВашейБазы] SET MULTI_USER;
Подводя итог, можно сказать, что решение проблем с фоновыми заданиями требует комплексного подхода. Мы разобрали, что блокировка конкретного документа (например, Заказа поставщику) часто является лишь следствием зависания другого процесса, работающего с общими регистрами.
Основные шаги по локализации проблемы:
TLOCK.Помните, что платформа 8.3.27 и конфигурация КА 2.5 — это сложные системы, где поведение фоновых заданий напрямую зависит от чистоты данных в регистрах-очередях и корректности настроек серверного окружения.