Регламентное задание висит в статусе «Выполняется»: как найти виновника и снять его

Регламентное задание 1С зависает почти всегда по одной из четырёх причин: ждёт чужую блокировку, ждёт ответа внешнего сервера без таймаута, крутит неудачный код или его рабочий процесс завис вместе с ним. Первое, что нужно сделать, — открыть консоль кластера, найти сеанс фонового задания и посмотреть, чем он занят прямо сейчас.

Частое заблуждение — «перезагружу сервер, и всё пройдёт». Пройдёт до следующего запуска. Если причина в блокировке или в HTTP-запросе без таймаута, задание повиснет снова, а вы потеряете данные для диагностики. Сначала смотрим, потом снимаем.

Всё сказанное относится к платформе 8.3 в клиент-серверном варианте. Отличия файловой базы — в отдельном подразделе.

С чего начать: как подтвердить, что задание действительно зависло

Долгое задание и зависшее — разные вещи. Закрытие месяца или загрузка курсов за год может честно идти 40 минут. Зависшее задание не продвигается: нет новых записей в журнале регистрации, не растёт счётчик обработанных объектов, сеанс не потребляет процессор.

Где посмотреть состояние в типовых конфигурациях на БСП (БП 3.0, ЗУП 3.1, УТ 11):

• 📂 Администрирование → Обслуживание → Регламентные операции → Регламентные и фоновые задания;
• 📊 в списке видно состояние, время начала и время окончания последнего запуска;
• ⏱ если «Выполняется» стоит часами при обычной длительности в минуты — это наш случай.

Ещё один признак: платформа не запускает новый экземпляр того же регламентного задания, пока не завершился предыдущий. Поэтому одно зависание выглядит как «задание перестало работать вовсе» — расписание есть, а запусков нет.

Файловая база — отдельная история

В файловом варианте регламентные задания выполняет один из клиентских сеансов. Нет открытых сеансов — нет и выполнения, и это не зависание. Для выделенного «исполнителя» заданий используют параметр запуска /AllowExecuteScheduledJobs -Force, а чтобы конкретный клиент задания не брал — /AllowExecuteScheduledJobs -Off.

Анализ активных сеансов и таблицы блокировок в консоли кластера

Откройте консоль администрирования серверов 1С, раскройте кластер, затем Информационные базы → <ваша база> → Сеансы. Сеанс регламентного задания отображается с приложением «Фоновое задание».

Что смотреть в карточке и в колонках списка сеансов:

1. 🔎 Время вызова (текущее) — сколько длится текущий серверный вызов. Растёт без конца — сеанс занят одним вызовом.
2. 🔒 Признак блокировки — консоль показывает, каким сеансом заблокирован текущий: отдельно по блокировкам СУБД и по управляемым блокировкам. Если там номер другого сеанса — задание не висит, оно ждёт.
3. 🧠 Процессорное время текущего вызова. Растёт — код крутится. Стоит на месте — ожидание (блокировки, сети, диска).
4. 📦 Объём данных и память вызова — подскажут, не грузит ли задание в память огромную выборку.

Узел Блокировки в той же базе показывает список установленных блокировок и сеансы-владельцы. По нему удобно найти «корень» цепочки: сеанс, который держит блокировку и сам никого не ждёт. Нередко это пользователь, который открыл документ, начал проводку и ушёл на обед с открытым модальным окном ошибки.

Если нужно копнуть глубже — на стороне СУБД

Когда консоль показывает ожидание СУБД, смотрим сам сервер базы данных:

-- MS SQL Server: кто кого блокирует
SELECT session_id, blocking_session_id, wait_type, wait_time, status
FROM sys.dm_exec_requests
WHERE blocking_session_id <> 0;

-- PostgreSQL: сеансы и номера блокирующих их процессов
SELECT pid, pg_blocking_pids(pid) AS blocked_by, state, wait_event_type, now() - query_start AS duration
FROM pg_stat_activity
WHERE cardinality(pg_blocking_pids(pid)) > 0;

Номер соединения СУБД есть в свойствах сеанса 1С в консоли, так что связать одно с другим можно напрямую.

Конфликты транзакций и управляемые блокировки

Регламентное задание в управляемом режиме блокировок ждёт освобождения ресурса ограниченное время, после чего падает с ошибкой вида Конфликт блокировок при выполнении транзакции: Превышено максимальное время ожидания предоставления блокировки. Такой запуск не висит — он завершается с ошибкой, и это видно в журнале.

Настоящее «вечное» ожидание обычно возникает в трёх ситуациях:

• 🐢 Длинная транзакция внутри задания. Задание открывает одну транзакцию и в ней обрабатывает 50 000 документов. Пока она идёт, оно держит блокировки и мешает пользователям, а пользователи — ему.
• 🔁 Две копии логики одновременно. Пользователь вручную запустил ту же обработку, что делает задание. Обе пишут в один регистр.
• 🗄 Блокировки уровня СУБД. Эскалация блокировок на MS SQL, когда построчные блокировки превращаются в табличную. Её видно в запросе к sys.dm_exec_requests выше.

Что помогает:

1. Дробить обработку на порции по 500–1000 объектов, каждую в своей транзакции.
2. Ставить управляемую блокировку БлокировкаДанных только на нужный диапазон, а не на весь регистр.
3. Разносить по времени тяжёлые задания и пиковую работу пользователей. Перепроведение партий в 10:00 по Москве — гарантированный конфликт.

HTTP-запросы и внешние подключения без таймаута

Это главный «тихий» виновник. Задание обращается к внешнему сервису — банку, сайту, маркетплейсу, оператору ЭДО — а тот принял соединение и молчит. Процессор не грузится, блокировок нет, вызов длится часами.

Причина в коде: объект HTTPСоединение создают без таймаута. Шестой параметр конструктора — таймаут в секундах, значение по умолчанию 0 означает «ждать бесконечно».

// Плохо: ожидание ответа без ограничения
Соединение = Новый HTTPСоединение("api.example.ru", 443, , , , , Новый ЗащищенноеСоединениеOpenSSL);

// Хорошо: не дольше 60 секунд
Соединение = Новый HTTPСоединение("api.example.ru", 443, , , , 60, Новый ЗащищенноеСоединениеOpenSSL);

Та же логика касается FTPСоединение, web-сервисов через WS-ссылки и COM-соединений с другими базами. Для доработок ставьте таймаут всегда. Для типовых модулей таймауты обычно заданы, и здесь стоит проверить сеть: прокси, межсетевой экран, DNS на сервере 1С.

Проверка сети с сервера, где работает рабочий процесс (не с вашего компьютера):

nslookup api.example.ru
curl -v --max-time 30 https://api.example.ru/

Перенесённая копия базы

Типовые конфигурации на БСП умеют определять, что база скопирована или перемещена. В этом случае работа с внешними ресурсами блокируется, и часть заданий не выполняется. Это не зависание, но со стороны похоже. Программа показывает запрос «база перемещена или это копия?» администратору при входе — ответьте на него осознанно.

Ошибки в коде обработчика регламентного задания

Если сеанс стабильно ест процессор и время вызова растёт, проблема внутри кода. Типовые сценарии:

• ♾ Бесконечный цикл. Условие выхода зависит от данных, которые в цикле не меняются. Пример: «пока есть необработанные записи» — а запись после ошибки так и остаётся необработанной.
• 🧮 Огромная выборка в память. Запрос без отбора по периоду выгружает в таблицу значений миллион строк. Память рабочего процесса растёт, начинается подкачка, всё замедляется в разы.
• 💬 Интерактивные вызовы на сервере. Попытка показать вопрос или предупреждение в фоне заканчивается ошибкой, а не ожиданием. Но обработчик, который ловит исключение и уходит в повтор без паузы и счётчика, крутится вечно.
• 🔂 Повтор без ограничения. «Не получилось — попробуем ещё раз» без счётчика попыток.

Найти место зависания помогает технологический журнал. Файл logcfg.xml кладут в каталог conf платформы на сервере; события CALL, EXCP, TLOCK, TTIMEOUT, TDEADLOCK покажут длительные вызовы, исключения и ожидания блокировок. Для поиска медленных запросов добавляют событие DBMSSQL или DBPOSTGRS.

Для доработанных заданий отладка на сервере удобнее всего: включите серверную отладку, подключитесь к фоновому заданию и поставьте точку останова в обработчике. Делать это лучше на копии базы.

Влияние версии платформы и конфигурации

Зависания бывают связаны не с кодом, а с окружением:

Отложенное обновление стоит выделить. После установки нового релиза БП или ЗУП фоновая обработка данных может идти несколько часов на большой базе. Прерывать её не нужно — дождитесь окончания, а пользователей предупредите о возможном замедлении.

Как снять зависшее задание и перезапустить его

Действуйте от мягкого к жёсткому. Каждый следующий шаг — только если не сработал предыдущий.

Если нужно, чтобы задание не запускалось, пока вы разбираетесь, в свойствах информационной базы в консоли кластера есть флажок «Блокировка регламентных заданий включена». Он останавливает запуск всех заданий базы. Точечно — снимите флажок «Использование» у конкретного задания в списке регламентных.

После снятия зависания запустите задание вручную кнопкой выполнения в той же форме и проследите, что оно завершилось. Только потом возвращайте расписание.

Профилактика зависаний и настройка мониторинга

Зависание лучше заметить через 15 минут, а не через три дня, когда бухгалтер увидит неполученные выписки.

Что настроить один раз:

• 📈 Журнал регистрации. Включите уровень регистрации «Ошибки» как минимум. Фильтр по событиям фоновых заданий покажет, когда был последний успешный запуск.
• ⏰ Контроль по времени. Простой внешний скрипт раз в 15 минут запрашивает список сеансов через rac session list и сигналит, если сеанс фонового задания живёт дольше порога. Параметры отбора смотрите в справке rac help session.
• 🧱 Порции и транзакции. В своих доработках — порционная обработка и короткие транзакции.
• 🌐 Таймауты. Каждое внешнее соединение с явным таймаутом и ограниченным числом повторов.
• 🗓 Расписание. Тяжёлые задания — ночью, причём не одновременно с резервным копированием и обслуживанием индексов СУБД.
• 🔄 Регламент СУБД. Обновление статистики и перестроение индексов: устаревшая статистика превращает быстрый запрос задания в многочасовой.

Частые вопросы