Загадочное фоновое задание UpdateConfigurationLicense
Столкнулся с новым (для меня) поведением платформы.
У пользователя серверная 8.3.9.2033 1С:ЗарплатаИУправлениеПерсоналом 2.5.120.1.
1. Выполняем обновление конфигурации (в пакетном режиме).
2. Далее выполняем обновление базы данных (в пакетном режиме).
3. Сразу после пункта 2 пытаемся подключиться к базе (через COM) и получаем ошибку «разделенного доступа к базе данных, база данных заблокирована:, компьютер: server, пользователь: СкрытоеИмяПользователя, приложение: фоновое задание.».
И это при том что все имеющиеся перед обновлением фоновые задачи завершены, а запуск новых запрещён.
Исследуем журнал регистрации и обнаруживаем, что во время выполнения второго пункта платформа запускает некоторое системное фоновое задание в данных у которого написано «UpdateConfigurationLicense».
Я догадываюсь, что это платформа выполняет какие-то манипуляции для обновления лицензии, контроля и чего-то там ещё.
Но какого же чёрта она это делает через механизм регламентных заданий и при этом не считается с запретом их выполнения.
В модуле самой конфигурации поиск UpdateConfigurationLicense ничего не даёт, а значит это механизм на уровне платформы.
Если у кого есть доп. информация по этому механизму прошу поделиться, потому что почти не гуглится.
Меня главным образом волнует:
— это общее поведение платформы для всех конфигураций или нет
— эта особенность была всегда или появилась с какого-то релиза
— она похоже работает только для серверных?
— может какой-то ключик существует, чтобы платформа (при запуске с ключом /UpdateDBCfg) дожидалась таки окончания выполнения этого системного задания UpdateConfigurationLicense
Длительные операции на сервере
Область применения: управляемое приложение.
1. При разработке конфигураций следует избегать длительных вызовов из клиентского кода в серверный. Все длительные серверные вызовы, которые могут выполняться более 8 секунд в обычных сценариях работы пользователя, следует выполнять асинхронно, с помощью фонового задания.
К таким операциям относятся: формирование отчета, групповая обработка объектов, загрузка или выгрузка данных в другое приложение, заполнение больших табличных частей и т.п.
В противном случае такие вызовы могут привести к потере работоспособности приложения или затруднению работы с ним:
2.1. Общий подход к асинхронному выполнению длительных серверных операций с помощью фонового задания:
а для прочих мест – выводится блокирующая форма ( РежимОткрытияОкна = БлокироватьОкноВладельца ), на которой размещена декорация с анимированной картинкой и кнопка «Отмена» :
2.2. Асинхронное формирование отчета требуется только для тех отчетов, которые
Поведение таких отчетов должно быть максимально похожим на поведение отчетов на базе СКД, а именно:
Пример выполнения функции в фоновом задании при использовании в конфигурации Библиотеки стандартных подсистем. В модуле менеджера объекта размещена функция, которая выполняет поиск настроек и возвращает их:
Функция ОпределитьНастройкиУчетнойЗаписи(АдресЭлектроннойПочты, Пароль) Экспорт
.
Возврат Настройки;
КонецФункции
В форме объекта выполняется вызов этой функции в фоновом задании в три этапа:
1) запуск фонового задания на сервере,
2) подключение обработчика завершения фонового задания на клиенте,
3) обработка результата выполнения фонового задания.
// 2. Подключение обработчика завершения фонового задания.
ПараметрыОжидания = ДлительныеОперацииКлиент.ПараметрыОжидания(ЭтотОбъект);
Оповещение = Новый ОписаниеОповещения(«ПриЗавершенииПоискаНастроек», ЭтотОбъект);
ДлительныеОперацииКлиент.ОжидатьЗавершение(ДлительнаяОперация, Оповещение, ПараметрыОжидания);
КонецПроцедуры
// 3. Обработка результата выполнения фонового задания.
&НаКлиенте
Процедура ПриЗавершенииПоискаНастроек(Результат, ДополнительныеПараметры) Экспорт
Если Результат = Неопределено Тогда // Пользователь отменил задание.
Возврат;
КонецЕсли;
Если Результат.Статус = «Ошибка» Тогда
ВызватьИсключение Результат.КраткоеПредставлениеОшибки;
КонецЕсли;
Настройки = ПолучитьИзВременногоХранилища(Результат.АдресРезультата);
УдалитьИзВременногоХранилища(Результат.АдресРезультата);
УстановитьНастройкиУчетнойЗаписи(Настройки);
Методическая рекомендация (полезный совет)
3.1. При каждом выполнении фонового задания его результат помещается во временное хранилище на время жизни формы:
ПараметрыВыполнения = ДлительныеОперации.ПараметрыВыполненияФункции(УникальныйИдентификатор);
ДлительныеОперации.ВыполнитьФункцию(ПараметрыВыполнения, ПараметрФоновогоЗадания);
Если длительная операция выполняется пользователем многократно, пока эта форма открыта, то временные хранилища накапливаются, что вызывает рост потребления памяти. Поэтому для уменьшения расхода оперативной памяти в большинстве случаев рекомендуется очищать временное хранилище сразу после получения результата фонового задания:
Настройки = ПолучитьИзВременногоХранилища(Результат.АдресРезультата);
УдалитьИзВременногоХранилища(Результат.АдресРезультата); // Данные во временном хранилище больше не требуются.
Если же результат фонового задания требуется сохранять на протяжении нескольких серверных вызовов, то необходимо передавать фиксированный адрес заранее инициализированного временного хранилища:
Возврат ДлительныеОперации.ВыполнитьФункцию(ПараметрыВыполнения,
«Справочники.УчетныеЗаписиЭлектроннойПочты.ОпределитьНастройкиУчетнойЗаписи»,
АдресЭлектроннойПочты, Пароль);
КонецФункции
4. Если в конфигурации реализуются алгоритмы, инициирующие запуск фоновых заданий или запись данных информационной базы без участия пользователя (например, регулярное обновление информации в открытой форме), то в них следует проверять, что в текущем сеансе не установлен монопольный режим. В противном случае, следует блокировать попытки выполнения таких действий. Например:
Если МонопольныйРежим() Тогда
Возврат;
КонецЕсли;
5. В некоторых случаях возникает необходимость в выполнении длительных операций, требующих установки монопольного режима доступа к информационной базе. Например:
При этом необходимо сначала устанавливать монопольный режим, а затем выполнять запуск фонового задания, которое реализует саму длительную операцию. В этом случае фоновым заданием будет унаследован монопольный режим, ранее установленный из пользовательского сеанса (см. документацию к платформе).
На время выполнения этого фонового задания следует блокировать весь интерфейс приложения, открывая форму ожидания завершения операции в режиме РежимОткрытияОкна = БлокироватьВесьИнтерфейс. Блокировать интерфейс приложения требуется потому, что на время выполнения задания полноценная работа пользователя с приложением уже невозможна:
* Примечание: ошибки записи также возникают в тех случаях, когда объекты записываются программно, например, из обработчиков ожидания. В них также следует проверять монопольный режим согласно п.5.
Фоновое задание UpdateConfigurationLicense
(8) в момент выполнения этого задания в базу не попасть. Она блокируется на время выполнения этого задания.
Для себя я сейчас вот что уяснил:
— это задание запускается в конце (за секунду) до окончания выполнение обновление базы данных
— длится минуту
— блокирует на это время доступ к базе
— работает на серверных ОС
У нас самописка на БСП 2.2. Обработчики обновления в режиме предприятия используются БСПшные.
И тестовый деплой базы для автотестов выполняется автоматом ci-сервером как:
1) накатывается конфа целиком из храна на тестовую клиент-серверную базу
2) обновляется конфигурация ИБ тестовой базы
3) запускается тестовая база с параметром запуска для БСПшных обработчиков ОбновлениеИнформационнойБазы с запуском служебной обработки, которая дожидается окончания работы обработчиков обновления и закрывает базу
4) запускаются тесты на обновленной базе
И падает третий шаг, потому что обработчики обновления хотят монопольный режим, а в базе висит фоновое.
И да, как в (9) написано, фоновое инициируется из конфигуратор в конце второго шага.
(10) я для пользователя решил проблему таким образом:
— после 2 шага (обновление базы данных) делаю ожидание 120 секунд, затем перехожу к выполнению обработчиков обновления
Помогло. По его журналу это фоновое задание по лицензированию всегда 1 минуту выполняется и стартует в конце 2 этапа (по вашей хронологии).
Он мне сегодня отписался, что помогло. Теперь всё отрабатывает отлично.
(11) проверить не могу, но скорее всего этого задания в истории не будет, так как оно программно запускается платформой. Соотв. и места вызова в конфигурации не будет, так как его просто нет.
(3) удалось разобраться что это за фоновое задание такое?
У пользователя оно вызывается платформой для серверной базы даже если на сервере запрещен запуск регламентных заданий.
И в итоге это создаёт ошибку «разделенного доступа к базе данных, база данных заблокирована».
И к кому претензии предъявлять?
«Проблемы индейцев шерифа не волнуют» (с)
(5) 8.3.9.2033 1С:ЗарплатаИУправлениеПерсоналом 2.5.120.1.
Серверная. Я тоже у себя нигде такого найти не могу.
Напишу для истории.
Столкнулся сегодня тоже с этим заданием.
База серверная 8.3.10.2699. Задание обнаружилось в фоновых заданиях в узле распределенной базы.
Оно мне не мешалось, просто тестировал свои регламентные задания и в списке фоновых заданий обнаружил неизвестное задание.
Начал искать и пришел сюда.
Конфигурация полностью самописная, без всяких БСП и прочих библиотек, в ней таких заданий нету.
Получил ответ от 1С:
Отключить данное задание нельзя, оно создается при каждом обновлении конфигурации.
Это проверка лицензирования конфигурации.
Как правило, проверка лицензирования конфигураций выполняется для файловых или клиент-серверных (мини-бизнес) систем.
Данная проверка не отключается на уровне Предприятия, но возможно стоит проверить доступ конфигурации к интернету, что бы проверка завершила свою работу корректно.
Автоматическое обновление и резервное копирование 1С при помощи powershell
Суть рассматриваемого вопроса изложена в заголовке, повествование разобьем на три части. Отдельно внизу будут приведены тексты скриптов.
1) Предисловие
Вопрос необходимости резервного копирования в автоматическом режиме не подлежит сомнению ни у корифеев, ни у новичков. В статье рассмотрим резервное копирование средствами 1С (что имеет ряд преимуществ перед копированием средствами СУБД). При этом будут применены средства пакетного запуска платформы 1С, powershell и планировщик задач Windows.
Задачи обновления информационных давно автоматизированы, но только для типовых конфигураций, либо тех, что используют библиотеку стандартных подсистем. В моем случае мы работаем со старенькой Альфа-Авто редакции 4, которая распространяется на 12 серверов. Изменения вносятся примерно два раза в неделю, поэтому выгода от автоматизации налицо.
В обоих случаях мы имеем следующие исходные данные:
2) Резервное копирование
После прочтения указанных ссылок мы уже знаем, что надо сделать, чтобы запустить скрипт powershell, поэтому сразу перейду к делу.
Сделать резервную копию информационной базы в пакетном режиме очень просто, надо только «выгнать» всех пользователей. Делать мы это будем, подключившись COM-объектом к базе данных. Это в нашем примере делает функция ExitAll. В тело функции зашито, что она вызывается на том сервере, на котором, собственно, установлен кластер серверов 1С. Вызовите эту функция безо всяких параметров в своем скрипте на сервере — и ВСЕ пользователи из ВСЕХ баз кластера вылетят.
Приношу свои извинения человеку, чьим кодом я воспользовался при написании этой процедуры — авторство восстановить не удалось.
После этого следует вызвать функцию BackUpBase с параметром — имя информационной базы. У меня во всех ИБ есть служебный администратор с одинаковыми учетными данными, поэтому я их просто захардкодил. При необходимости можно их параметризовать, либо обойтись аутентификацией ОС.
Итоговый скрипт сохраняем в файл.
В планировщике задач создаем «Простую задачу», имя, разумеется, на ваше усмотрение.
У меня работает ежедневно, но и тут хозяин — барин. Запускать лучше всего ночью, когда никто не работает, например, в 3:00. Действие для задачи — «Запустить программу». Сама программа у нас «powershell.exe». А вот ее аргументы —
где ExitAllUsersAndBackup.ps1 — как раз наш сохраненный скрипт.
-ExecutionPolicy RemoteSigned — ключ, который разрешает выполнение пакетных скриптов powershell, если в системе они глобально не разрешены. Работает через раз (возможно, не хватает компетенции чтобы разобраться, но закономерности не нашёл). В случаях, когда не работает с этим ключом, приходится разрешать выполнение скриптов для всего сервера.
Для этого Win+R, powershell.exe,
и подтверждаем действие.
Время работы с данными скриптами — более трех месяцев. Перебои были, но связаны с отключением электричества и прочими внешними факторами.
3) Обновление конфигурации
После того, как все пользователи вышли (или выгнаны, как в предыдущем случае), можно обновлять конфигурацию. Наличие регламентных заданий может помешать обновлению, так как с момента отключения всех пользователей и открытия конфигуратора для загрузки конфигурации вполне может начать работу какое-то задание. Поэтому расписание следует обдумать.
Конфигурацию мы храним на ftp-сервере, на который помещаем ее вручную. Файл конфигурации называется GK.cf, в приведенном примере обновляется одна единственная конфигурация. Потенциально можно так же обновлять и несколько различных конфигураций.
На ftp рядом с GK.cf помещаем файл с названием flag.txt. Наличие этого файла сигнализирует о том, что обновляться надо. Можно проверять наличие самого фйла GK.cf, но мы используем флаг так же для других целей.
Скрипт работает следующим образом:
Надежность этого скрипта чуть меньше. Обновление проходит до конца на 100% в тех случаях, когда меняется структура метаданных. В других случаях бывает, как я предупреждал ранее, появление активного пользователя. В результате конфигурация загружена в базу, но конфигурация базы данных не обновлена (снова прошу прощения за подобную кривоватую терминологию перед людьми, не связанными с 1С). В остальном — полет нормальный.
Скрипт резервного копирования
Скрипт обновления конфигурации
Благодарю за внимание. Готов к конструктивной критике.
Архив метки: updateconfigurationlicense
Кроме замедлений операций, где поведение связано с конкретной операцией, или особенностями вводимы параметров у этой операции существуют ситуации когда страдают значительной группой пользователей или вообще все пользователи информационной системы.
Общесистемное замедление — когда любые операции испытываются трудности со скоростью выполнения.
Групповые замедления — когда коллективно замедления испытывает группа пользователей на любых операциях.
Укрупненно влиять массово могут следующие факторы:
1. Объективное замедление всей системы.
1.1 Сброс частоты процессора
1.2 Пропуск тактов процессора (например из-за перегрева)
1.3 Влияние виртуализации (умышленное или по ошибке). Пример влияния одной виртуалки на другую показан на видео с 7 минуты.
2. Нехватка мощностей сервера
2.1 Существенная или полная утилизация доступных ресурсов (процессор, диски, сеть и т.п.)
2.1.1 Кратковременная/пиковая
2.1.1.1 Загружен может быть не сервер целиком, а ядра, используемые конкретным серверным процессом 1С, например при выполнении фонового процесса по обновлению полнотекстового индекса или диск при достройке индексов для журнала регистрации в последних версиях платформы
2.1.1.2 Замедление при проседании скорости диска может быть связанно с особенностями кэша диска (например серия Samasung EVO использует технологию TurboWrite. Когда «кэш» TruboWrite забивается под завязку, то скорость записи резко падает.) или превышения ресурса перезаписи
2.1.2 Длительная
3. Логические ожидания
3.1 Ожидания внешних процессов
3.1.1 Ожидания опроса ключей 1С (как по архитектуре ключ проброшен с откликом больше 0 мс, так и по причине ошибок в коде). Пример тут.
3.1.2 Плохо написанный вызов из кода 1С синхронно внешнего процесса
3.1.3 Ошибки платформы
3.1.3.1 подвисания при переключении сеансов со старого рабочего процесса на новый
3.1.3.2 замедления как минимум в версии ПРОФ при освоении
80% доступной оперативной памяти
3.1.3.3 известны проблемы в 8.3.18 с асинхронными вызовами
3.1.3.4 известны случаи некорректной работы при динамических обновлениях
3.1.3.5 известны случаи некорректной работы при долго выполняющемся фоновом задании updateconfigurationlicense
3.2 Квотирование ресурсов (например dfss)
3.3 Внешний перехват сетевого трафика драйвером антивируса или проверка процесса антивирусом
3.4 для бесплатной версии ms sql server (в старых версии был регулятор на 5 активных соединений) или специального настроеннго в платной регулятора ресурсов.