Регламентные и фоновые задания в системе 1С:Предприятие 8 — это мощный инструмент для автоматизации рутинных операций. Однако при неправильной настройке они могут стать главным источником деградации производительности всей системы, вызывая загрузку процессора сервера приложений rphost до 100% и бесконечные блокировки в СУБД. Многие администраторы, пытаясь разгрузить сервер, начинают хаотично отключать регламентные задачи или переносить их на случайное время, что приводит к непредсказуемым ошибкам в работе пользователей.
В этой статье мы подробно разберем, как правильно подойти к оптимизации регламентных заданий на примере конфигурации 1С:Бухгалтерия предприятия 3.0, выясним причину «зависания» механизма отложенного обновления информационной базы, проанализируем влияние полнотекстового поиска на общую производительность СУБД и рассмотрим передовые архитектурные методы изоляции фоновых задач от интерактивной работы пользователей.
---
В современных конфигурациях 1С, построенных на базе Библиотеки стандартных подсистем (БСП), процесс обновления конфигурации разделен на два принципиальных этапа:
ОтложенноеОбновлениеИБ (Отложенное обновление ИБ).Проанализируем ситуацию, с которой часто сталкиваются администраторы: после обновления конфигурации регламентное задание отложенного обновления не стартует или зависает в состоянии выполнения, из-за чего процесс обновления считается незавершенным. Давайте выясним причины такого поведения системы.
Причина 1: Сбитое или некорректное расписание. По умолчанию регламентное задание ОтложенноеОбновлениеИБ в БСП отключено. Механизмы обновления активируют его программно по мере необходимости. Оно должно работать циклически (например, каждые 60 секунд), чтобы последовательно запускать пакеты обработчиков. Если в вашей базе расписание этого задания было кем-то принудительно изменено (например, настроен запуск один раз в сутки в 7:00 утра), то после обновления выполнится лишь первый шаг, после чего процесс остановится на целые сутки. Система будет находиться в полуобновленном состоянии, что может привести к критическим сбоям при записи документов.
Причина 2: Блокировка регламентных заданий в кластере. При обновлении баз или создании резервных копий администраторы часто устанавливают флаг «Блокировка регламентных заданий включена» в консоли администрирования кластера серверов 1С. Если после завершения монопольного этапа этот флаг забыли снять, отложенное обновление физически не сможет запуститься.
Причина 3: Параметры запуска базы. Если база данных была запущена с параметром командной строки /AllowExecuteScheduledJobs -Off (часто применяется для копий баз во избежание отправки реальных данных во внешние сервисы), выполнение любых регламентных заданий блокируется на уровне сеанса.
Причина 4: Аварийное завершение фонового обработчика. Если один из обработчиков обновления сталкивается с ошибкой данных (например, битая ссылка или незаполненный обязательный реквизит), он завершается аварийно. В этом случае БСП останавливает выполнение всего регламентного задания, чтобы не допустить дальнейшего искажения данных.
Рассмотрим по шагам, как диагностировать и решить проблему зависшего обновления:
ОтложенноеОбновлениеИБ. По умолчанию оно должно запускаться каждые 60 секунд. Верните стандартное расписание, если оно было изменено.
// Программный перезапуск отложенных обработчиков обновления БСП
ПараметрыОтбора = Новый Структура;
ОбновлениеИнформационнойБазы.ПерезапуститьОтложенноеОбновление(ПараметрыОтбора);
ЗаписатьЛогСобытия = Новый ЗаписьЖурналаРегистрации(
"ОбновлениеИБ",
УровеньЖурналаРегистрации.Информация,
,
,
"Выполнен принудительный перезапуск отложенного обновления ИБ"
);
Этот метод полностью сбрасывает зависшие статусы текущего пакета обработчиков, регистрирует невыполненные задания заново и инициирует их повторный запуск.
---
Регламентные задания ОбновлениеИндексаППД (Обновление индекса ППД) и СлияниеИндексаППД (Слияние индекса ППД) часто становятся первыми кандидатами на отключение со стороны неопытных администраторов. Существует опасное заблуждение: «Если у нас небольшая база и новые данные вносятся не каждую секунду, то обновлять индекс достаточно один раз в сутки ночью». Давайте проанализируем, почему такое решение гарантированно приведет к катастрофическому падению производительности.
Механизм полнотекстового поиска 1С используется платформой при поиске информации в динамических списках (например, при быстром поиске по строке в списках документов «Реализации», «Поступления», справочниках «Контрагенты» или «Номенклатура»). Процесс поиска работает следующим образом:
LIKE '%строка_поиска%' по всем текстовым полям индексируемых таблиц.Запуск запросов с конструкцией LIKE с ведущим символом процента заставляет СУБД игнорировать стандартные индексы SQL и выполнять полное сканирование таблиц (Table Scan / Clustered Index Scan). Если в базе работают десятки пользователей, выполняющих поиск документов, это мгновенно утилизирует все ресурсы процессора (CPU 100%) сервера СУБД и приводит к эскалации блокировок таблиц. Пользователи начинают жаловаться на «зависание» интерфейса при вводе любого символа в строку поиска.
Посмотрим на варианты решения этой проблемы:
Вариант А: Оптимальная настройка расписания (компромисс). Если вы не хотите нагружать сервер ежеминутным обновлением индекса, настройте регламентное задание ОбновлениеИндексаППД на запуск каждые 10–15 минут. Это обеспечит приемлемую актуальность поиска для сотрудников и предотвратит постоянное переключение платформы на тяжелые SQL-запросы. Задание СлияниеИндексаППД (которое оптимизирует структуру самого индекса, устраняя фрагментацию) запускайте один раз в сутки в ночное время (например, в 3:00).
Вариант Б: Полное отключение ППД. Если ваши пользователи работают исключительно со строгими отборами (например, ищут контрагентов только по ИНН, а номенклатуру по точному артикулу без использования глобальной строки поиска), вы можете полностью отключить полнотекстовый поиск. Важно: простое отключение регламентного задания в списке не поможет! Вам необходимо отключить этот функционал на уровне платформы:
ОбновлениеИндексаППД и СлияниеИндексаППД можно окончательно отключить в консоли регламентных заданий — они больше никогда не побеспокоят ваш сервер.Оптимизация на современных платформах (8.3.25 и выше): В новых версиях платформы 1С существенно оптимизировано потребление памяти при работе с индексами ППД. Чтобы эти изменения вступили в силу, мы рекомендуем после обновления платформы выполнить полную очистку индекса через административную панель, а затем запустить его полное перестроение заново.
---
Если ваша база данных работает под управлением клиент-серверного варианта (SQL), а количество одновременно работающих пользователей превышает 30-50 человек, то простое перераспределение регламентных заданий по времени суток перестает приносить желаемый эффект. Тяжелые задания, такие как расчет себестоимости, слияние индекса или закрытие месяца, все равно будут пересекаться со временем работы пользователей, создавая помехи.
В этом случае мы рекомендуем применить архитектурное решение — разделение рабочих процессов rphost по функциональному признаку с помощью механизмов Требований назначения функциональности (ТНФ). Данный механизм позволяет жестко указать системе, на каких именно рабочих процессах или серверах кластера должны выполняться регламентные задания, а на каких — обслуживаться только сеансы пользователей.
Давайте рассмотрим по шагам процесс настройки ТНФ в консоли администрирования кластера серверов 1С:
Таблица правил для выделенного сервера регламентных заданий:
Клиентское соединение с ИБНазначатьBackgroundJob.ScheduledJob (указывает, что данный сервер будет обрабатывать регламентные задания).Клиентское соединение с ИБНазначатьBackgroundJob.CommonModule (фоновые задания, запускаемые программно из общего модуля).Любой объект требованияНе назначатьНа основном «пользовательском» сервере настройте зеркальные правила: установите способ Не назначать для объектов BackgroundJob.ScheduledJob и BackgroundJob.CommonModule. Таким образом, тяжелые регламентные фоновые процессы будут изолированы в рамках отдельного процесса rphost на выделенных вычислительных ресурсах и не окажут никакого влияния на отзывчивость интерфейса ваших пользователей.
---
Давайте проанализируем настройки конкретных заданий, упомянутых автором темы, и найдем в них логические нестыковки, влияющие на бизнес-логику.
Загрузка курсов валют: Автор установил время загрузки на 5:10 утра. Давайте выясним, почему это не совсем корректно. Центральный Банк Российской Федерации публикует официальные курсы валют на следующий день во второй половине текущего дня (обычно в период с 15:00 до 16:00 по московскому времени). Если ваше регламентное задание выполняется в 5:10 утра, оно загружает курсы, которые были установлены еще вчера.
Если в вашей организации ведется активная внешнеэкономическая деятельность и документы в валюте должны выписываться оперативно, целесообразно перенести выполнение этого задания на 16:30 – 17:00. В таком случае к концу рабочего дня в базе уже будут актуальные курсы на завтрашний день, и утренний запуск системы пользователями пройдет без задержек.
1СПАРК Риски: Это полезный аналитический сервис, однако его регламентные задания отправляют внешние веб-запросы к серверам правообладателя. Рассмотрим рекомендации по их оптимизации:
Придерживаясь этих простых, но проверенных временем правил, мы сможем добиться идеального баланса производительности системы 1С, обеспечив пользователям мгновенный отклик интерфейса, а руководству — актуальные и своевременно обновленные данные.