Почему фоновые задания при загрузке конфигурации запускаются по очереди, а не параллельно?

Программист 1С v8.3 (Управляемые формы) IT и автоматизация бизнеса
← На главную

В практике администрирования и автоматизации обновлений 1С программисты часто сталкиваются с ситуацией, когда сервер, обладающий внушительными ресурсами, внезапно начинает «тормозить» выполнение однотипных фоновых заданий. Рассмотрим классический сценарий: мы запускаем 10 фоновых заданий, каждое из которых должно выполнить загрузку конфигурации (/LoadCfg) в разные информационные базы или выполнить иные регламентные действия через запуск конфигуратора в пакетном режиме. Однако в диспетчере задач вместо ожидаемых 10 процессов 1cv8.exe мы видим всего 1-3, а остальные задания как будто замирают в очереди. При этом другие команды, например /ResetMasterNode, в тех же условиях отрабатывают мгновенно и параллельно.

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

Анализ исходного кода и метода вызова

Для начала проанализируем код, который часто используется для подобных задач. Автор вопроса применяет объект WScript.Shell. Рассмотрим этот пример:


WshShell = Новый COMObject("WScript.Shell");
// Команда запуска конфигуратора с ожиданием завершения
WshShell.Run("""C:\Program Files\1cv8\8.3.15.1985\bin\1cv8.exe"" CONFIG /S "+ИмяСервера+"\"+ИмяИБ+" /N"+ИмяПользователя+" /P"+ПарольПользователя+" /DisableStartupMessages /LoadCfg """+ФайлОбновления+""" /UC123 /out "+ИмяФайла + " -NoTruncate", 0, Истина);

Здесь важно обратить внимание на последний параметр метода RunИстина (WaitOnReturn). Этот параметр заставляет текущий поток фонового задания 1С ожидать, пока вызванный процесс 1cv8.exe не завершит свою работу. Хотя само по себе это не запрещает запуск других фоновых заданий, это создает цепочку ожидания, которая становится критичной при возникновении любых системных блокировок.

Разберем причины ограничения параллельности

Почему же /ResetMasterNode работает быстро, а /LoadCfg выстраивается в очередь? Выделим несколько ключевых факторов.

1. Эксклюзивный доступ и блокировки СУБД

Операция /LoadCfg является «тяжелой» с точки зрения работы с данными. В отличие от простых команд, загрузка конфигурации требует монопольного доступа к таблицам метаданных. Если фоновые задания (даже с уникальными ключами) пытаются одновременно обратиться к ресурсам, которые сервер 1С считает общими, или если несколько заданий по ошибке нацелены на одну и ту же базу, система выстроит их в очередь на уровне блокировок базы данных или самого менеджера кластера.

2. Потребление лицензий

Каждый запуск 1cv8.exe в режиме Конфигуратора потребляет одну клиентскую лицензию. Если вы запускаете 10 заданий, вам необходимо иметь 10 свободных лицензий сверх тех, что уже заняты пользователями и рабочими процессами. При использовании /LoadCfg процесс находится в памяти значительно дольше, удерживая лицензию. Команда /ResetMasterNode выполняется почти мгновенно, лицензия быстро освобождается и передается следующему процессу, что создает иллюзию параллельности, хотя на самом деле это может быть очень быстрая последовательная обработка.

3. Лимиты Desktop Heap в Сессии 0

Сервер 1С работает как служба Windows в так называемой «Сессии 0». У этой сессии есть жесткое ограничение на объем памяти, выделяемой под объекты графического интерфейса (даже если они не отображаются) — Desktop Heap. Запуск каждого экземпляра 1cv8.exe отнимает часть этого ресурса. Конфигуратор при загрузке метаданных инициализирует гораздо больше объектов, чем при выполнении простых сервисных команд. Когда лимит Desktop Heap исчерпан, новые процессы просто не могут стартовать, пока не закроются старые.

Переход от COM к встроенным методам 1С

Проанализируем рекомендации экспертов. Одной из первых стоит задача отказаться от использования внешних COM-объектов, таких как WScript.Shell, в пользу встроенных механизмов платформы. Это снижает накладные расходы на маршалинг объектов и делает код более «чистым» для сервера приложений.

Вместо WshShell.Run рекомендуется использовать метод ЗапуститьПриложение. Рассмотрим, как переписать процедуру:


ПараметрыЗапуска = "CONFIG /S """ + ИмяСервера + "\" + ИмяИБ + """ /N """ + ИмяПользователя + """ /P """ + ПарольПользователя + """ /LoadCfg """ + ФайлОбновления + """ /UC123 /out """ + ИмяФайла + """ -NoTruncate";
ПутьКЗапуску = "C:\Program Files\1cv8\8.3.15.1985\bin\1cv8.exe";

// Используем ЗапуститьПриложение вместо COM
ЗапуститьПриложение(ПутьКЗапуску + " " + ПараметрыЗапуска, , Истина);

Многие ошибочно полагают, что ЗапуститьПриложение работает только на клиенте. На самом деле, этот метод отлично выполняется на стороне сервера, начиная с версии 8.2, и является более предпочтительным, чем КомандаСистемы, так как позволяет лучше контролировать процесс запуска.

Настройка рабочего сервера

Если программные методы не помогают, стоит заглянуть в настройки кластера 1С. Выясним причины, скрытые в параметрах рабочего сервера:

Практические рекомендации по решению

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

  1. Проверка монопольного режима: Убедитесь, что в момент запуска /LoadCfg в информационной базе нет активных сеансов, либо используйте параметр /UC с кодом разрешения, который прописан в параметрах блокировки базы.
  2. Разделение ресурсов: Если вы загружаете одну и ту же конфигурацию в 10 разных баз, попробуйте разложить файл конфигурации (.cf) в разные временные папки. Иногда ограничение может возникать на уровне файловой системы при попытке совместного чтения одного файла несколькими процессами.
  3. Использование параметра /AllowExecuteScheduledJobs: Добавьте в строку запуска конфигуратора параметр /AllowExecuteScheduledJobs -Off. Это предотвратит попытки конфигуратора запускать внутренние регламентные задания самой базы, что сэкономит ресурсы и уменьшит количество конфликтов.
  4. Мониторинг лицензий: Запустите консоль администрирования и во время старта фоновых заданий отследите раздел «Лицензии». Если вы увидите, что количество свободных лицензий упало до нуля — причина найдена.
  5. Диагностика через Журнал регистрации: Проанализируйте события в журнале регистрации каждой базы. Если там фиксируются ошибки «Конфигурация базы данных заблокирована», значит проблема в попытке одновременной записи метаданных.

Таким образом, мы выяснили, что ограничение параллельности чаще всего связано не с «глюком» платформы, а с защитными механизмами Windows (Desktop Heap), блокировками СУБД или нехваткой лицензий. Переход на ЗапуститьПриложение и тщательный контроль параметров серверного кластера позволяют успешно решать задачи массового автоматического обновления баз.

← На главную