Многие администраторы и разработчики систем на базе «1С:Предприятие 8.3» сталкиваются с ситуацией, когда журнал регистрации (ЖР) буквально переполняется записями о событии «Фоновое задание. Отмена». Особенно часто это проявляется в конфигурациях с интенсивным использованием управляемых форм, таких как Управление торговлей 11, ERP или Комплексная автоматизация. Ситуация пугает тем, что проблема затрагивает абсолютно всех пользователей и возникает в самых востребованных формах: списках заказов, справочниках партнеров или журналах закупок. Проанализируем, почему это происходит, стоит ли паниковать и как оптимизировать работу системы.
Выясним основную причину. Начиная с версии платформы 8.3.10, разработчики 1С существенно переработали механизмы работы динамических списков для повышения отзывчивости интерфейса. Рассмотрим по шагам, что происходит в системе, когда пользователь открывает форму списка, например Справочник.Партнеры.Форма.ФормаСписка:
Таким образом, мы видим не ошибку в коде или данных, а штатную работу механизма асинхронного считывания данных. Это «вариант нормы», обеспечивающий комфортную работу пользователя за счет динамического управления нагрузкой на сервер.
Разберем, почему в сообщении автора упоминаются именно ЗаказКлиента, Партнеры и ДокументыЗакупки. Эти объекты в конфигурации Управление торговлей 11 являются наиболее сложными с точки зрения структуры данных. Проанализируем факторы, влияющие на длительность выполнения запроса в динамическом списке:
Сложные запросы и соединения (JOIN). Динамические списки в крупных конфигурациях редко обращаются к одной таблице. Обычно запрос содержит множество соединений с регистрами сведений (например, для получения актуальных цен, остатков или контактной информации). Чем сложнее запрос, тем дольше он выполняется в фоновом задании и тем выше вероятность, что пользователь успеет изменить условие поиска до завершения задачи, спровоцировав её отмену.
Ограничение доступа на уровне записей (RLS). Если в базе включены механизмы RLS, к каждому запросу динамического списка платформа автоматически добавляет сложные условия проверки прав. Это кратно увеличивает время выполнения задания на стороне SQL-сервера. В результате «окно», в котором задание может быть отменено, расширяется.
Настройка «Фоновое считывание данных». В свойствах динамического списка (объект ДинамическийСписок) существует флаг ФоновоеСчитываниеДанных. Когда он включен, платформа стремится максимально использовать фоновые процессы. В типовых решениях для высоконагруженных списков этот режим включен по умолчанию для обеспечения плавности прокрутки и поиска.
Рассмотрим технические нюансы версии платформы 8.3.13. В данной ветке механизмы логирования были достаточно избыточными. Платформа фиксировала каждое прерывание фонового процесса с высоким приоритетом. В более поздних релизах (начиная с 8.3.15 и выше) разработчики оптимизировали ЖР, чтобы штатные отмены не так сильно «мозолили глаза» администраторам, группируя их или снижая уровень значимости события.
Важнейшим аспектом является работа полнотекстового поиска (ПП). Если механизм ПП настроен некорректно, система может вести себя следующим образом:
LIKE).LIKE '%Текст%' по многомиллионной таблице — крайне ресурсоемкая операция, которая не использует индексы базы данных.Несмотря на то что данные записи являются штатной ситуацией, их избыток может мешать анализу реальных проблем или приводить к неоправданному росту файлов журнала регистрации (.lgd или .lgp). Разберем шаги по оптимизации:
Проверим работу регламентных заданий. Перейдем в раздел Обслуживание — Полнотекстовый поиск. Убедимся, что статус индекса — «Актуален». Если индекс не обновлялся давно, необходимо запустить регламентное задание ОбновлениеИндексаПолнотекстовогоПоиска. Актуальный индекс позволяет платформе мгновенно получать результаты поиска, и фоновые задания будут завершаться успешно быстрее, чем пользователь успеет их отменить.
Если конкретная форма (например, СписокДокументыЗакупки) работает слишком медленно и генерирует сотни записей об отменах, проанализируем её запрос. В ряде случаев помогает отключение полнотекстового поиска для конкретного элемента, если он там не критичен. Для этого в свойствах списка можно изменить режим поиска. Однако это крайняя мера, так как она может замедлить работу пользователей. В качестве альтернативы можно использовать решение для гибкого и быстрого поиска в списках.
Если система позволяет, проанализируем возможность перехода на «Производительный режим» RLS (доступно в последних версиях УТ 11 и ERP). Это значительно упрощает SQL-запросы, ускоряет работу динамических списков и, как следствие, уменьшает количество прерванных фоновых процессов.
Если вы уверены, что система работает стабильно, а записи об отменах — лишь «белый шум», настроим фильтрацию ЖР. В самой платформе (через конфигуратор или в режиме предприятия) можно установить отбор, исключающий события по фоновым заданиям при просмотре. Если же стоит задача уменьшить объем самого файла ЖР, можно программно настроить уровень логирования. Рассмотрим пример логики, которую можно применить (условно):
// Пример настройки уровня регистрации событий (мета-код)
УстановитьУровеньЖурналаРегистрации(УровеньЖурналаРегистрации.Предупреждение);
// Это позволит не записывать информационные сообщения об отменах заданий
Подводя итог, можно утверждать: появление записей «Фоновое задание. Отмена» в динамических списках Справочник.Партнеры или Документ.ЗаказКлиента не является признаком критической неисправности. Это следствие работы асинхронной архитектуры 1С, которая отменяет старые запросы в угоду новым.
Для минимизации количества таких записей рекомендуем:
8.3.22 или выше), где логирование более сбалансировано.Таким образом, мы обеспечим стабильную работу системы и чистый журнал регистрации, пригодный для оперативного мониторинга действительно важных событий. Для удобного аудита событий и поиска нештатных ситуаций подойдёт обработка для анализа записей журнала регистрации.