1с системное фоновое задание что это
Обновлено: 06.07.2024
Файл "ЛР4_1С_83_тонкий_и_WEB-клиент" внутри архива находится в папке "Методические указания по выполнению лабораторных работ 1,2,3,4". Документ из архива "Методические указания по выполнению лабораторных работ 1,2,3,4", который расположен в категории "книги и методические указания". Всё это находится в предмете "управление в корпоративных информационных систем" из одиннадцатого семестра, которые можно найти в файловом архиве МГТУ им. Н.Э.Баумана. Не смотря на прямую связь этого архива с МГТУ им. Н.Э.Баумана, его также можно найти и в других разделах. Архив можно найти в разделе "книги и методические указания", в предмете "управление в корпоративных информационных систем" в общих файлах.
Онлайн просмотр документа "ЛР4_1С_83_тонкий_и_WEB-клиент"
Текст 4 страницы из документа "ЛР4_1С_83_тонкий_и_WEB-клиент"
// в кластере 1541 центрального сервера TestSrv
Системное фоновое задание
Представляет собой соединение рабочего процесса кластера с информационной базой. Это соединение предназначено для выполнения фонового обновления конфигурации базы данных.
Соединение фонового задания существует до тех пор, пока выполняется фоновая реструктуризация.
Подробнее о фоновом обновлении конфигурации базы данных см. книгу «1С:Предприятие 8.3. Руководство разработчика».
2.1.4.2. Виды сеансов
Возможны следующие виды сеансов:
Описание сеансов в общем соответствует описанию соответствующего соединения. Описание сеанса веб-клиента приведено ниже.
Веб-клиент
Является представлением в кластере серверов экземпляра веб-клиента. Этот сеанс предназначен для модификации данных информационной базы и выполнения другой функциональности, предоставляемой конфигурацией информационной базы. Обращение веб-клиента к серверу выполняется через соединение Модуль расширения веб-сервера.
Сеанс Веб-клиент создается в результате интерактивного запуска веб-клиента и существует до тех пор, пока не будет завершен сеанс интерактивной работы с информационной базой (закрыто последнее окно веб-браузера).
1.4.3. Внешнее управление сеансами
При эксплуатации клиент-серверных систем возникает задача управления возможностью создания сеансов с информационными базами:
● Ограничить количество одновременно работающих пользователей с одной информационной базой.
● Обеспечить некоторый гарантированный запас лицензий при работе с информационной базой, например, при наличии 100 лицензий обеспечить гарантированную возможность доступа к информационной базе двух пользователей с фиксированными именами.
● Другие аналогичные задачи.
Для реализации этих задач предоставляется механизм внешнего управления сеансами. Для работы механизма необходимо наличие специализированного Web-сервиса, который занимается разрешением или запрещением создания сеанса.
Предполагается следующая схема работы механизма:
● При попытке начать сеанс, кластер серверов информирует Web-сервис о необходимости создания сеанса и передает в Web-сервис набор параметров, позволяющих определить все характеристики создаваемого сеанса (имя информационной базы, имя пользователя, кластер серверов и т. д.).
● Web-сервис принимает решение о разрешении или запрещении создания сеанса и возвращает управление кластеру серверов. При необходимости, Web-сервис должен вести учет созданных сеансов в необходимых разрезах.
● При завершении сеанса, кластер серверов также информирует Web-сервис о том, что сеанс завершается.
Таким образом, система внешнего управления сеансами точно знает, какое количество сеансов сейчас создано в «подшефных» информационных базах и может принимать необходимые решения.
Описание Web-сервиса, который используется в механизме внешнего управления сеансами, и пример реализации см. здесь.
1.5. Отказоустойчивый кластер
Отказоустойчивый кластер обеспечивает бесперебойную работу пользователей в следующих случаях:
● перезапуск рабочих процессов и менеджеров кластера (как плановый, так и аварийный);
● выход из строя сервера, входящего в состав кластера.
Механизмы, которые обеспечивают бесперебойную работу, описаны далее в этом разделе.
1.5.1. Транзакционность сеансовых данных
В процессе работы системы сеанс сохраняется при различных сбоях, и возможно восстановление работы после переустановки соединения. Однако существуют ситуации, при которых сеанс завершается системой и предлагается выполнить перезапуск клиентского приложения:
● в процессе вызова сервера, после фиксации первой за этот вызов транзакции, аварийно завершился рабочий процесс;
● при возврате управления клиенту произошла ошибка передачи данных.
1.5.2. Повтор последнего вызова
Если в процессе вызова сервера произошла ошибка передачи данных, то это может означать, что:
● произошел обрыв канала связи,
● произошло аварийное завершение рабочего процесса сервера.
Если клиентское приложение вызвало сервер вне транзакции и ошибка передачи данных получена клиентом до фиксации первой за вызов сервера транзакции, то клиент автоматически выполняет процедуру установки соединения с сервером и повторяет тот же самый вызов. После этого его работа продолжается.
Если ошибка передачи данных получена клиентом после фиксации первой за вызов сервера транзакции, то сеанс этого клиента завершается и для продолжения работы требуется перезапуск клиентского приложения.
1.5.3. Повтор интерактивного действия
Если клиентское приложение вызвало сервер в транзакции (в обычном режиме работы, а не в режиме управляемого приложения), то ошибка передачи данных считается восстановимой ошибкой и приводит к аварийному завершению интерактивного действия, но не к аварийному завершению клиентского приложения.
Важно, что целостность данных приложения в этом случае не гарантируется платформой, если интерактивное действие состоит более чем из одной транзакции или меняет состояние данных приложения, кроме данных, имеющих логику кеширования.
1.5.4. Уровень отказоустойчивости
Уровень отказоустойчивости определяет максимальное количество рабочих серверов, входящих в состав кластера, одновременный выход из строя которых не приведет к аварийному завершению сеансов подключенных пользователей. Надо понимать, что «выход из строя» подразумевает ситуации, подобные следующим: отключение питания компьютера, разрыв сетевого кабеля, проблемы с операционной системой, не позволяющие запустить процесс и т. д.
Таким образом, если в кластер серверов входит только один рабочий сервер, то максимальный уровень отказоустойчивости будет 0,т. к. выход из строя единственного рабочего сервера приведет к аварийному завершению всех подключенных пользователей. Если в кластер входит 4 рабочих сервера, то уровень отказоустойчивости может изменяться от 0 до 3. При этом 0 означает, что фатальным считается выход из строя любого рабочего сервера, а значение 3 означает, что кластер сохранит работоспособность даже в том случае, если выдут из строя 3 из 4 рабочих серверов.
Следует понимать, что увеличение уровня отказоустойчивости выполняется ценой некоторого падения производительности кластера, т. к. кластер будет тратить некоторые ресурсы на синхронизацию данных между рабочими серверами.
Уровень отказоустойчивости связан с количеством центральных серверов в кластере. Количество центральных серверов определяет возможность создания новых соединений. Если, например, в кластер входит два центральных сервера при общем количестве 3 рабочих сервера, то пользователи смогу подключаться к информационным базам в случае аварийного завершения одного центрального сервера. При этом остается два работающих рабочих сервера: один центральный и один рабочий. Если в кластере будет только один центральный сервер, то аварийное завершение этого сервера приведет к тому, что кластер станет недоступен пользователям, несмотря на то, что в нем сохранили работоспособность еще 2 рабочих сервера.
Если в кластере присутствует 3 рабочих сервера (из них один центральный) и установлен уровень отказоустойчивости равный 1, то могут наблюдаться различные ситуации. Рассмотрим их.
Выход из строя одного рабочего сервера
Аварийно завершается работа обычного рабочего сервера. Это соответствует уровню отказоустойчивости, кластер продолжает обслуживать пользователей. При этом подключение новых пользователей также возможно,т. к. сохраняет работоспособность центральный сервер.
Рис. 7. Аварийное завершение одного рабочего сервера
Выход из строя центрального сервера
Аварийно завершается работа центрального сервера. Это соответствует уровню отказоустойчивости, но кластер прекращает работу, т. к. завершил работу центральный сервер кластера.
Рис. 8. Аварийное завершение центрального сервера
Выход из строя двух рабочих серверов
Аварийно завершают работу два рабочих сервера, при этом центральный сервер сохраняет работоспособность. При этом превышен уровень отказоустойчивости, как следствие, будут завершены сеансы пользователей, которые обслуживались завершившимися рабочими серверами. Пользователи, которых обслуживает центральный сервер – сохранят работоспособность. При этом будет возможно подключение новых пользователей.
Рис. 9. Аварийное завершение двух рабочих серверов
Таким образом, можно вывести следующую формулу, связывающую количество центральных серверов в кластере и уровень отказоустойчивости:Количество центральных серверов = Уровень отказоустойчивости+1. При этом надо понимать, что буквальное следование этой формуле приведет к некоторому снижению производительности кластера, т. к. на синхронизацию реестра кластера будет тратиться некоторая часть мощности системы. При определении количества центральных серверов и уровня отказоустойчивости следует соблюдать баланс между отказоустойчивостью и приемлемым уровнем производительности кластера серверов, учитывая при этом характеристики оборудования компьютеров, входящих в состав кластера.
1.6. Масштабируемость кластера серверов
Масштабируемость кластера серверов обеспечивается несколькими способами:
● Наращиванием вычислительных мощностей компьютера, на котором развернут единственный рабочий сервер кластера.
● Возможностью включения в состав кластера серверов одного или нескольких новых рабочих серверов.
Все необходимые действия по обеспечению масштабируемости кластер серверов выполняет автоматически. Администратор кластер может влиять на действия кластера серверов с помощью изменения свойств рабочего сервера.
В список рабочих серверов кластера можно добавлять новые сервера и менять свойства существующих (см. здесь). Измененные значения свойств действуют только на новые соединения и сеансы. Удаление рабочего сервера следует проводить особым образом, чтобы не допустить аварийного отключения пользователей, которых обслуживает удаляемый сервер. Подробнее порядок удаления рабочего сервера см. здесь. Невозможно удаление последнего рабочего сервера в кластере с установленным признаком Центральный сервер. При создании кластера по умолчанию, рабочий сервер того компьютера, на котором создается кластер серверов, автоматически включается в список рабочих серверов и для этого рабочего сервера устанавливается флажок Центральный сервер.
Во время работы кластер серверов автоматически распределяет нагрузку между рабочими серверами таким образом, чтобы обеспечить минимальное время обслуживания клиентских приложений. Сервисы кластера (см. здесь) равномерно распределяются по рабочим серверам по типам сервисов, информационным базам и сеансам.
Представим, что нужно периодически запрашивать какой-то большой объем данных из внешней системы, но повлиять на скорость ответа внешнего сервиса/системы мы не можем, а очень хочется получать данные быстро. При этом открыть несколько параллельных сеансов внешняя система не запрещает. Тогда на помощь приходят они ФоновыеЗадания 1С в серверной базе (в файловой базе выигрыша в скорости не происходит).
Увеличение скорости происходит не линейно и максимально мне удавалось достичь ускорения за счет параллельности максимум в 3-5 раз от скорости в 1 сеансе. Это происходит из-за того, что тратятся ресурсы и время на создание параллельных сеансов, а потом на ожидание и сборку результатов.
Чтобы достичь максимального эффекта для конкретной задачи приходится опытным путем в песочнице определять:
- когда выгодно включать работу через ФоновыеЗадания, а когда можно и через 1 сеанс подождать ответа
- какое количество одновременных сеансов/обращений можно использовать для конкретной таблицы/сервиса .
В 1С теоретически можно создать сколь угодно много фоновых заданий, нО. внешняя система либо может не выдержать такой нагрузки, либо просто забанит нас. Потому рекомендую программно ставить ограничение в 1С не более 10-30 одновременных потоков.
Алгоритм действий:
Объекты метаданных которые понадобятся для решения:
- Общий модуль: Серверный, не глобальный, без использования повторных вызовов, можно, если надо Привилегированный.
- Встроенная или внешняя Обработка, откуда делается вызов общего модуля
- любой РегистрСведений, для примера я взял регистр из УТ 11.4 «ВременныеИдентификаторыЗапросов». Регистр сведений используется как буфер для записи промежуточных результатов фоновыми заданиями и последующей сборки из него.
В общем модуле нам достаточно 1 экспортной процедуры, куда передается на вход сформированный ранее в обработке текст запроса и идентификатор фонового задания для записи промежуточного результата работы процедуры в РегистрСведений с этим же идентификатором.
Вспомогательные процедуры/функции и другие выполняющие собственно саму работу процедуры для настоящей статьи не существенны и могут меняться в зависимости от задачи. Имеются в приложенном файле конфигурации.
В обработке запуска фоновых заданий получаем из внешней системы или придумываем свой уникальный идентификатор, по которому будем бить задачи на порции. В примере для ADS берем выборку ключевого поля из нужной таблицы и потом разбиваем полученный результат на структуру, содержащую массивы порционных ключей таблицы.
Если установили ограничение на максимальное количество одновременных фоновых заданий, то в цикле запуска фоновых заданий останавливаемся при достижении лимита, ждем завершения ранее созданных заданий, собираем промежуточные результаты и только потом двигаемся дальше.
Модуль объекта обработки ВыполнитьЗадачиПараллельно() и СобратьОтветыФоновыхЗаданийВызов фоновых заданий выполняется в цикле через метод ФоновыеЗадания.Выполнить(), который выполнит сделанную ранее в общем модуле экспортную процедуру. Фоновому заданию передается: ИмяОбщегоМодуля.ИмяЭкспортнойПроцедуры, массив параметров и идентификатор фонового задания, по которому потом будем собирать данные из РегистраСведений.
Метод ФоновыеЗадания.Выполнить() ЗапуститьДлительныеВычисленияНаСервереНа выходе получаем результирующие данные из параллельных фоновых заданий.
В заключение
Все примеры и листинги сделаны как эмуляция заполнения массивов и таблиц значений, а если прописать настоящий адрес, ключевое поле и имя таблицы и выключить эмуляцию, то работает с Advantage Database Server (далее – ADS), СУБД понимающей стандартный язык запросов T-SQL через Com объекты ADODB. Алгоритм можно использовать в любых похожих ситуациях с любыми СУБД, внешними службами, когда требуется ускорить/распарралелить вычисления.
В прилагаемом к статье файле конфигурация с 3 объектами для работы с ФоновымиЗаданиями 1С, включая все необходимые вспомогательные и служебные процедуры, функции, чтобы не зависеть от БСП и типа, версии конфигурации. Легко добавить в любую конфигурацию, если есть возможность изменения или как расширение и затем быстро подкорректировать под свою задачу. Формы Регистра и Обработки управляемые. Версия Платформы требуется не ниже 8.3.13, конфигурация любая.
При очередной реорганизации инфраструктуры на казалось бы ровном месте вдруг наблюдается к концу рабочего дня просто чудовищная нагрузка на сервере 1С, на котором развернута пара десятков типовых бухгалтерских баз. Сервер 1С просто останавливается. Наблюдаются падения rphost-ов. Виновником оказалось фоновое задание. Задание выполняет загрузку данных из торговой системы. Порции небольшие, в каждой выгрузке 1-4 документа. В бухгалтерские базы данные попадают практически в реальном режиме. Поэтому настроено задание на частый запуск. И хоть самих данных для загрузки может и не оказаться, но задание все-равно ведь стартует. Бухгалтера в конце рабочего дня закрывают свои сессии, а фоновые задания работают.
На рабочем сервере в Performance Monitor сняты показания счетчика %Processor Time, см. на картинке.
Интервалы 1 и 3 соответствуют времени когда в каждой базе открыта пользовательская сессия, интервал 2 — работает только фоновое задание.
Да вот и объяснение:
Все обновления новостей
каждый день; каждые 300 секунд, завершать через 600 секунд
Все обновления 1СПАРК Риски
каждый день; каждые 3600 секунд
Все обновления 1СПАРК Риски (Область данных)
каждый день; каждые 43200 секунд
Извлечение текста файлов для поиска
каждый день; каждые 85 секунд
Обновление данных онлайн-сервисов регламентированной отчетности
каждый день; каждые 3600 секунд
Обновление задач бухгалтера
каждый день; с 2:22:00 один раз в день
Обновление индекса ППД
каждый день; с 8:00:00 каждые 60 секунд
Обновление проверок контролирующими органами
каждый день; с 0:55:15 один раз в день
Отложенное обновление ИБ
каждый день; каждые 60 секунд, повторять после завершения через 60 секунд
Отправка электронных документов
один день; один раз в день
Получение электронных документов
один день; один раз в день
каждый 7-й день; один раз в день
Проверка контрагентов на подключение к 1С-ЭДО
каждый 7-й день; один раз в день
Проверка кэша состояний ФНС
каждый день; с 2:25:05 один раз в день
Проверка новых электронных документов
каждый день; каждые 1800 секунд
Слияние индекса ППД
каждый день; с 1:00:00 один раз в день
Установка периода рассчитанных итогов
каждый день, 5-го числа месяца; с 1:00:00 один раз в день
Большей частью задание выполняется только один раз в день. Такое тяжелое задание как «Слияние индекса ППД» выполняется ночью. Вряд ли они могут явиться источником проблем в текущей работе пользователя. Но есть задания, которые стартуют довольно часто, в рабочее время, вот такие легкие задания и могут явиться источником проблем. Выделены синим цветом. Значит необходимо побеспокоится о том чтобы либо эти задания не «частили» когда нет активных пользовательских сеансов, либо следует активировать в такой базе пользовательский сеанс.
В падении производительности сервера 1С виноваты не сами задания, они выполняют полезную работу, и должны выполнять. Но задания нельзя оставлять «наедине» с базой. В противном случае может быть плохо серверу.
У себя нашли выход с использованием дополнительной базы, выполняющей роль диспетчера. В этой базе создали регламентные задания, свое для каждой рабочей базы. Задание выполняет простую работу - проверяет имеются ли данные для загрузки, если да, по COM вызывается задание на загрузку в соответствующей рабочей базе. Теперь нагрузка на сервер 1С просто никакая, значения %Processor Time в среднем 15-20. Исчезли падения rphost-ов. Но жизнь идет. К сожалению, пришлось отказаться через некоторое время от этого решения, поскольку во время загрузки решили выполнять дополнительные расчеты в бухгалтерской базе, вызовом соответствующего кода самой базы. Но не все по COM, как оказалось, бухгалтерия позволяет сделать. Пока держим активными сеансы в базах.
Вряд ли можно согласиться с утверждением, что это просто такая особенность платформы. Уж больно неприлично выглядит деградация сервера 1С при получении сеансовых данных на фоне того с какой легкостью эти данные отдает сервер СУБД.
Хотя наверное действительно особенность, неприятная. Впрочем, как не называй, учитывать следует.
Все проверялось на такой конфигурации:
Платформа 1С:Предприятие 8.3 (8.3.12.1529).
Конфигурация Бухгалтерия предприятия КОРП, редакция 3.0 (3.0.65.80).
СУБД - Microsoft SQL Server Management Studio 12.0.5589.7.
Сервер 1С и сервер СУБД на разных машинах.
Конфигурации похожи - Intel(R) Xeon(R) CPU E5-4650v2 2,4 GHz, RAM - 32 GB.
Регламентные задания позволяют выполнять определенные действия по расписанию. Для выполнения используются фоновые задания.
Регламентные задания хранятся в базе данных. В конфигурации есть объект метаданных Регламентные задания, где можно создать новое задание, указать метод для выполнения, расписание и т.п. Если установить в свойствах флаг Предопределенное, то при сохранении конфигурации базы данных регламентное задание будет записано в базу данных. Если флаг не установлен, то записать задание в базу нужно вручную.
Для примера создадим простое регламентное задание и установим у него флаг Предопределенное, а также Использование. Использование означает, что регламентное задание будет выполняться согласно его расписанию.
В свойстве Наименование можно указать произвольное наименование регламентного задания. Свойство Ключ аналогично такому же свойству фоновых заданий. Нельзя запустить несколько фоновых заданий с одним ключом и связанных с одним регламентным заданием.
В свойстве Имя метода нужно выбрать не глобальный серверный общий модуль, в котором будет создана процедура для выполнения. Можно выбрать уже существующую процедуру или функцию из общего модуля. Если выбрана функция, то результат выполнения будет проигнорирован.
Если сейчас сохранить конфигурацию базы данных, то регламентное задание не будет выполняться, потому что для него не настроено Расписание.
Расписание регламентных заданий
Для настройки расписания нужно нажать на гиперссылку Открыть рядом со свойством Расписание. Будет открыто окно настройки расписания:
Для примера настроим чтобы регламентное задание выполнялось каждые 5 минут. Для этого на закладке Общее укажем, что нужно повторять задание каждый день:
Нажмем ОК, сохраним конфигурацию базы данных. Теперь каждые 5 минут будет запускаться фоновое задание и выполнять код из процедуры, которая указана в свойстве Имя метода.
Расписание тоже сохраняется в таблице регламентных заданий. Если сейчас изменить расписание в конфигураторе и сохранить конфигурацию базы данных, то все равно будет использоваться старое расписание. Чтобы применилось новое расписание, его нужно установить в пользовательском режиме. Или снять флаг Предопределенное и сохранить конфигурацию базы данных. В этот момент запись об этом регламентном задании будет удалена из таблицы. А потом настроить в конфигураторе новое расписание и снова поставить флаг Предопределенное. Регламентное задание будет записано в таблицу с новым расписанием.
Для программного открытия окна настройки расписания регламентного задания в пользовательском режиме можно воспользоваться следующим кодом:
ДиалогРасп = Новый ДиалогРасписанияРегламентногоЗадания ( Расп ) ; ОбратныйВызов = Новый ОписаниеОповещения ( "ЗаписатьРасписание" , ЭтотОбъект ) ; РеглЗад = РегламентныеЗадания . НайтиПредопределенное ( "РегламентноеЗадание1" ) ; Процедура ЗаписатьРасписание ( Расп , ДопПараметры ) Экспорт РеглЗад = РегламентныеЗадания . НайтиПредопределенное ( "РегламентноеЗадание1" ) ;В результате будет открыто окно для настройки расписания, результат настройки будет записан в таблицу регламентных заданий.
Расписание можно создать программно:
РеглЗад = РегламентныеЗадания . НайтиПредопределенное ( "РегламентноеЗадание1" ) ;Теперь регламентное задание будет выполняться каждую минуту.
Рассмотрим некоторые настройки расписания:
Те же самые примеры, но программно:
НовоеРасп . ВремяНачала = Новый Дата ( 1 , 1 , 1 , 1 , 0 , 0 ) ; НовоеРасп . ВремяНачала = Новый Дата ( 1 , 1 , 1 , 1 , 0 , 0 ) ; НовоеРасп . ВремяНачала = Новый Дата ( 1 , 1 , 1 , 1 , 0 , 0 ) ; Расп 1 . ВремяНачала = Новый Дата ( 1 , 1 , 1 , 13 , 0 , 0 ) ; Расп 2 . ВремяНачала = Новый Дата ( 1 , 1 , 1 , 18 , 0 , 0 ) ; //каждый день, в 13:00 и в 18:00, но только с 1 по 10 мая 2021 года Расп 1 . ВремяНачала = Новый Дата ( 1 , 1 , 1 , 13 , 0 , 0 ) ; Расп 2 . ВремяНачала = Новый Дата ( 1 , 1 , 1 , 18 , 0 , 0 ) ;Планировщик регламентных заданий
В клиент-серверном варианте регламентные задания выполняются планировщиком заданий, который находится в менеджере кластера. Планировщик заданий подбирает наименее загруженный рабочий процесс сервера 1С и запускает на нем фоновое задание. После выполнения рабочий процесс уведомляет планировщик о результате выполнения.
В файловом варианте регламентные задания выполняются на клиентском приложении. Причем только на одном. Это будет самое первое запущенное клиентское приложение. Если его закрыть, то регламентные задания начнут выполняться на другом клиентском приложении. Если больше нет запущенных клиентских приложений, то регламентные задания не будут выполняться. Если расписание регламентного задания было настроено на час ночи, а в этом время не был запущен ни один сеанс, то такое задание не будет выполнено. Обработка регламентных заданий выполняется один раз в 60 секунд. Если при запуске регламентного задания на этом клиентском сеансе уже выполняются какие-нибудь фоновые задания, то регламентное задание будет выполнено только после завершения всех текущих фоновых заданий.
До версии платформы 8.3.3.641 в файловом варианте не было автоматического выполнения регламентных заданий. Нужно было программно вызывать метод ВыполнитьОбработкуЗаданий. Обычно для этого запускался отдельный сеанс и в нем через обработчик ожидания вызывался данный метод.
Программная работа с регламентными заданиями
Если создать регламентное задание в конфигураторе, настроить у него расписание, но не установить флаг Предопределенное, то оно не будет выполняться. Потому что не было записано в таблицу регламентных заданий. В этом случае можно записать его туда вручную:
Читайте также: