Как определить, какое фоновое задание зависло в 1С и найти его причину?

← На главную

В процессе эксплуатации 1С:ERP Управление предприятием системные администраторы часто сталкиваются с ситуацией, когда в консоли администрирования серверов 1С наблюдается активность фоновых заданий от имени обычных пользователей. Эти задания могут потреблять значительные ресурсы или просто «висеть» часами, не завершаясь. Разберем подробно, как идентифицировать эти процессы и понять, что именно они выполняют.

Метод 1: Сопоставление через номер сеанса в консоли

Самый быстрый способ сопоставить «безликое» фоновое задание из консоли с конкретным действием в системе — это использование номера сеанса. Рассмотрим этот процесс пошагово:

Откроем консоль администрирования серверов 1С (MMC).
Перейдем в раздел Сеансы нужной информационной базы.
Найдем строку, где в колонке «Приложение» указано Фоновое задание, а в колонке «Пользователь» — имя сотрудника (например, Дмитрий).
Зафиксируем значение в колонке Номер сеанса.
Теперь перейдем в саму программу 1С:ERP под правами администратора. Разберем, где искать соответствие: откроем меню НСИ и администрирование — Обслуживание — Фоновые задания.
В открывшемся списке воспользуемся настройкой списка и выведем колонку Сеанс. Найдя нужный номер сеанса, мы увидим наименование задания. Это может быть «Формирование отчета», «Длительная операция» или конкретное регламентное задание.

Проанализируем ситуацию: если в колонке «Наименование» указано Длительная операция, это верный признак того, что пользователь запустил какой-то отчет или обработку на СКД (Системе компоновки данных). В управляемых формах такие операции всегда выносятся в фоновый поток, чтобы интерфейс оставался отзывчивым.

Метод 2: Программный поиск идентификатора задания

Если стандартный интерфейс не дает полной картины, мы можем воспользоваться программным доступом к менеджеру фоновых заданий. Рассмотрим пример кода, который поможет вывести список всех активных заданий с их метаданными. Это особенно полезно, когда нужно программно связать GUID задания из консоли с его внутренним именем:


Выборка = ФоновыеЗадания.ПолучитьФоновыеЗадания(Новый Структура("Состояние", СостояниеФоновогоЗадания.Активно));
Для Каждого Задание Из Выборка Цикл
    Сообщить("Имя: " + Задание.ИмяМетода + " | Начало: " + Задание.Начало + " | Идентификатор: " + Задание.Идентификатор);
КонецЦикла;

Используя объект ФоновыеЗадания, мы можем получить полную структуру параметров, с которыми было запущено задание. Часто именно в параметрах передается имя отчета, который в данный момент формируется.

Метод 3: Использование Технологического журнала (ТЖ)

Выясним причину зависания с помощью самого мощного инструмента — Технологического журнала. Если задание «висит», нам нужно понять, что оно делает: выполняет бесконечный цикл в коде или ждет ответа от СУБД. Настроим файл logcfg.xml для сбора событий CALL и SDBL только для конкретного процесса.

Пример настройки для отслеживания деятельности фонового задания:


<config xmlns="http://v8.1c.ru/v8/tech-log">
  <log location="C:\LOGS\BackgroundTasks" history="2">
    <event>
      <eq property="Name" value="SDBL"/>
    </event>
    <event>
      <eq property="Name" value="CALL"/>
    </event>
    <property name="all"/>
  </log>
</config>

Разберем, что нам дадут эти логи:

Событие SDBL покажет все запросы к базе данных. Если мы видим один и тот же тяжелый SQL-запрос, который повторяется или длится долго, значит, причина в неоптимальном коде запроса в СКД.
Событие CALL зафиксирует вызовы серверных методов. Посмотрев на стек вызовов, мы поймем, в какой именно процедуре общего модуля «застрял» процесс.

Метод 4: Анализ через SQL Server Management Studio

В ситуациях, когда консоль 1С не позволяет оперативно завершить задание, проанализируем ситуацию на уровне СУБД. Рассмотрим, как связать сеанс 1С с процессом на SQL-сервере:

В консоли администрирования 1С найдем наше задание и посмотрим колонку Номер соединения.
Откроем SQL Server Management Studio (SSMS) и выполним системную процедуру sp_who2.
Найдем строку, где значение в колонке SPID совпадает с номером соединения из 1С.
Выполним команду для получения текста текущего запроса:

DBCC INPUTBUFFER (номер_SPID);

Это позволит нам увидеть «сырой» SQL-текст. Если мы видим обращения к огромным таблицам оборотов или регистров без использования индексов, значит, отчет был настроен пользователем некорректно (например, выбран слишком большой период без фильтрации по организации).

Типичные причины «зависания» в ERP 2.4

Посмотрим на наиболее частые проблемы, специфичные для конфигураций на базе БСП:

1. Ожидание блокировок. Фоновое задание может стоять в очереди на изменение данных в таблице, которая заблокирована другим длительным процессом (например, закрытием месяца). В консоли такое задание будет «активным», но нагрузка на процессор будет нулевой.

2. Бесконечные циклы в коде. Если при формировании отчета или выполнении обработки код попадает в рекурсию или бесконечный цикл Для или Пока, процесс rphost будет потреблять 100% одного ядра процессора.

3. Утечки памяти при работе с СКД. В версии ERP 2.4 при формировании крайне объемных отчетов (например, ведомость по товарам за несколько лет по всем складам) может произойти переполнение памяти выделенной под рабочий процесс. Система начнет использовать файл подкачки, что визуально выглядит как полное замирание процесса.

Резюме: Чтобы эффективно бороться с зависшими заданиями, начните с сопоставления номера сеанса в Журнале регистрации или обработке Фоновые задания. Если это не дало ответа — используйте Технологический журнал для анализа серверных вызовов CALL. Это позволит точно определить проблемный участок кода или неоптимальный запрос.