Регламентные задания 1С: тихий убийца производительности рабочего дня

Если база стабильно тормозит в одно и то же время — почти наверняка виноваты регламентные задания. Их обычно десятки, включены они годами, половина досталась в наследство от внедренца, а расписания никто не пересматривал. Разберём, как провести инвентаризацию за полчаса, какие задания реально нужны и как построить расписание, при котором пользователи перестанут замечать ночную жизнь системы.

Регламентное задание — это код, который выполняется на сервере без участия пользователя. Обмены, пересчёты, индексация поиска, отправка почты, проверка контрагентов.

Проблема в трёх свойствах.

Во-первых, задания невидимы. Пользователь не знает, что в момент, когда он проводит документ, в фоне идёт пересчёт себестоимости за квартал — он видит только, что документ проводится восемь секунд вместо двух.

Во-вторых, они накапливаются. Каждое внедрение, каждая интеграция, каждая новая подсистема добавляет свои задания. Через три года их сорок, и никто не помнит назначения половины.

В-третьих, у них дефолтные расписания. Разработчик подсистемы поставил «каждые 60 секунд» или «ежедневно в 3:00», потому что надо было что-то поставить. Эти значения переезжают к вам вместе с конфигурацией и живут годами.

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

Цифра, которая обычно закрывает дискуссию.

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

Переставить эту треть на ночь стоит несколько часов работы и ноль рублей.

Начинаем с полного списка. Он доступен в консоли администрирования кластера или из самой конфигурации в разделе администрирования.

Выгружаем в таблицу и по каждому заданию отвечаем на четыре вопроса:

1. Что оно делает? Если ответа нет — это первый кандидат на отключение.
2. Кому нужен результат? Конкретный человек или процесс, а не «системе».
3. Как часто нужен результат на самом деле? Не как настроено, а как нужно.
4. Сколько оно выполняется и когда?

Четвёртый вопрос требует данных. Их даёт журнал регистрации с отбором по событию выполнения фоновых заданий, либо запрос к таблице заданий.

Типичный результат инвентаризации у клиента, к которому мы приходим впервые: из 34 заданий 11 отключаются сразу как ненужные, у 9 меняется расписание, 3 оказываются падающими уже несколько месяцев, и только про остальные можно сказать, что они работают как задумано.

Отдельная категория — задания, оставшиеся от отключённых подсистем. Интеграцию с сайтом отключили два года назад, а задание выгрузки продолжает каждые пять минут стучаться в несуществующий адрес и ждать таймаута.

Список того, что мы почти всегда трогаем в типовых конфигурациях.

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

Вопрос, который надо задать бухгалтерии: пользуется ли кто-нибудь полнотекстовым поиском? В половине компаний ответ — нет, люди ищут через отборы в списках. Тогда индексацию можно отключить целиком и вернуть заметную долю ресурсов сервера.

Принцип простой: ночь делится на непересекающиеся окна, а в рабочее время остаётся только то, без чего нельзя.

Шаблон, от которого мы отталкиваемся для офиса с рабочим днём с 9 до 19:

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

Второе правило — оставлять зазоры. Если задание по плану идёт сорок минут, окно под него делайте час. Иначе редкий длинный прогон наедет на следующее окно, и вы получите ту самую цепочку, которую разбирали в статье про блокировки.

Третье — то, что должно работать в течение дня, должно быть лёгким. Обмен с розницей раз в 15 минут — нормально, если он передаёт дельту за 15 минут. Ненормально, если он каждый раз пересчитывает остатки по всей номенклатуре.

У информационной базы есть свойство «Блокировка регламентных заданий». Оно выключает выполнение всех заданий разом.

Три сценария, где оно необходимо.

Тестовая копия. Развернули копию боевой базы — блокируйте задания немедленно, до первого запуска. Иначе тестовая база начнёт слать письма реальным контрагентам, выгружать документы в боевой обмен и опрашивать внешние сервисы от вашего имени. Это не гипотетический риск: мы разбирали случай, когда тестовая копия базы бухгалтерии двое суток дублировала выгрузку платёжных поручений в банк-клиент.

Обновление конфигурации. На время окна работ задания лучше выключить, чтобы они не мешали и не падали на изменяющейся структуре.

Разбор аварии. Когда непонятно, что происходит, отключение заданий — быстрый способ отсечь целый класс гипотез.

Ставится галка в свойствах базы в консоли кластера. Действует немедленно.

Важно не забыть снять. Мы добавили в чек-лист восстановления отдельный пункт: «проверить, не заблокированы ли регламентные задания» — после случая, когда у клиента месяц не выполнялись обмены, потому что при разборе давней аварии кто-то поставил галку и забыл.

Здесь кроется неочевидная сложность.

Упавшее задание оставляет запись об ошибке — его легко поймать. А вот задание, которое просто перестало запускаться, не оставляет ничего. Ни ошибки, ни предупреждения. Тишина.

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

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

-- псевдо-логика: для каждого ключевого задания
-- сравнить время последнего успешного завершения с ожидаемым интервалом
-- и поднять тревогу, если разрыв превысил два интервала

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

Порог «два интервала» выбран из практики: одиночный пропуск бывает по естественным причинам, два подряд — уже сигнал.

Список того, что мы держим под таким наблюдением у клиентов: обмены с внешними системами, выгрузки в банк, загрузка выписки, пересчёты, от которых зависит отчётность. То есть всё, чьё молчание обнаружится не сразу, а по расхождению данных.

Компания-импортёр, 29 рабочих мест, УТ на MS SQL, база 54 ГБ.

Жалоба звучала мягко: «по утрам программа немного задумывается». Мягкость формулировки — сама по себе плохой знак, потому что означает, что люди привыкли и перестали писать заявки.

Замеры показали картину жёстче, чем жалоба. С 09:02 до 09:11 каждый будний день APDEX по проведению документов падал с 0,93 до 0,18. Девять минут, в течение которых сорок человек фактически не работали.

Инвентаризация заданий дала список из 27 штук. Три из них имели расписание «ежедневно, 09:00»: загрузка курсов валют, проверка контрагентов по всей базе и загрузка прайс-листов поставщиков.

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

Разнесли: курсы валют на 08:30, прайс-листы на 20:00, проверку контрагентов на 04:00. Работы на пятнадцать минут.

Провал в замерах исчез полностью — индекс в утренние часы выровнялся на 0,91–0,94. Никаких изменений в железе, коде или настройках СУБД не потребовалось.

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

• Составлен полный список заданий с ответом на вопрос «зачем оно» по каждому.
• Задания от отключённых подсистем и интеграций выключены.
• Полнотекстовый поиск: проверено, пользуется ли им кто-то; если нет — индексация отключена.
• Ночь разбита на непересекающиеся окна: обмены, пересчёты, бэкап, обслуживание индексов, индексация поиска.
• Между окнами оставлены зазоры на случай долгого прогона.
• В рабочее время работают только лёгкие задания, передающие дельту, а не пересчитывающие всё.
• Настроены ограничения на число повторных запусков упавших заданий.
• На тестовых копиях блокировка регламентных заданий включается до первого запуска.
• Мониторинг проверяет факт выполнения ключевых заданий, а не только наличие ошибок.
• Список заданий и их расписания записаны в документацию по клиенту.

Полная инвентаризация с наведением порядка занимает у нас от двух до четырёх часов на незнакомой базе. Это, пожалуй, самое выгодное вложение времени из всего, что можно сделать для производительности учётной системы без покупки железа и правки кода.

Можно ли отключить полнотекстовый поиск в 1С?

Да, если им реально не пользуются — а в половине компаний это так, потому что люди ищут через отборы в списках. Отключение индексации возвращает заметную долю ресурсов сервера, особенно при интенсивном вводе документов.

Почему база тормозит каждый день в одно и то же время?

Почти всегда из-за совпадения нескольких регламентных заданий с пиком пользовательской активности. Проверьте расписания: типовая картина — три-четыре задания с дефолтным временем 09:00 или 03:00, наложенные друг на друга.

Обязательно ли блокировать задания в тестовой копии базы?

Обязательно, и до первого запуска. Иначе копия начнёт отправлять письма реальным контрагентам, выгружать документы в боевые обмены и обращаться к внешним сервисам от имени компании.

Как заметить, что задание перестало выполняться?

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