Многие специалисты столкнулись с серьезной проблемой после перехода на платформу 1С версии 8.3.22.1709 и последующие релизы. Основной симптом — аномально долгий запуск любых фоновых заданий. Это выражается в том, что отчеты (например, Оборотно-сальдовая ведомость), которые в обычном режиме формируются за 1-2 секунды, в фоновом режиме требуют более минуты. В этой статье мы подробно разберем причины такого поведения системы и рассмотрим эффективные методы решения проблемы.
Рассмотрим ситуацию, описанную пользователями: при выполнении кода формирования отчета в клиент-серверном варианте система использует механизм ДлительныеОперации.ЗапуститьВыполнениеВФоне. Проанализируем замеры времени: само формирование данных занимает секунды, но ожидание старта фонового задания растягивается на 60-70 секунд. Это создает критическую нагрузку на систему, так как регламентные задания (например, обмен данными в 1С:Розница) не успевают завершиться до начала следующего сеанса по расписанию, вызывая «зависание» процессов rphost.
Для проверки того, что проблема кроется именно в механизме фоновых заданий, мы можем временно модифицировать код формирования отчета, заставив его работать в основном потоке (не в фоне):
// Вместо запуска в фоне:
// РезультатВыполнения = ДлительныеОперации.ЗапуститьВыполнениеВФоне(...);
// Используем прямой вызов сервера:
АдресХранилища = ПоместитьВоВременноеХранилище(Неопределено, УникальныйИдентификатор);
БухгалтерскиеОтчетыВызовСервера.СформироватьОтчет(ПараметрыОтчета, АдресХранилища);
Если после такой правки отчет начинает «летать», значит, корень проблемы — в работе JobService (сервиса заданий) или в процессе инициализации нового сеанса фонового задания.
Одной из наиболее частых причин «тормозов» является использование выделенного сервера лицензирования. Разберем механизм: при запуске каждого фового задания платформа выполняет опрос лицензий. Если на основном сервере 1С установлена новая версия платформы (например, 8.3.22), а на сервере лицензирования осталась старая, то при каждом обращении возникают таймауты. Платформа тратит время на попытки связаться со «старым» сервисом по новым протоколам.
Что необходимо сделать: убедимся, что на всех серверах кластера и на выделенном сервере лицензирования установлена абсолютно идентичная версия платформы 1С. После обновления сервера лицензирования обязательно выполните его перезагрузку.
Платформа 1С, начиная с релизов конца 2022 года, стала более чувствительна к сетевому окружению. Проанализируем влияние файла nethasp.ini. По умолчанию система может пытаться искать ключи защиты по всей сети с помощью широковещательных запросов (broadcast), что на современных ОС вызывает задержки.
Рассмотрим рекомендации по правке nethasp.ini на сервере 1С:
NH_USE_BROADCAST = Disabled.NH_SERVER_ADDR = 127.0.0.1 (если локально) или IP вашего сервера.NH_SERVER_NAME = ИмяСервера.Дополнительно выясним влияние протокола IPv6. Часто задержка в 20–40 секунд вызвана тем, что платформа сначала пытается достучаться до сервисов по IPv6, и только после таймаута переходит на IPv4. Мы рекомендуем принудительно отключить IPv6 в настройках сетевого адаптера сервера или привязать хосты в файле hosts к адресу 127.0.0.1.
Сервис заданий JobService может пытаться инициировать процессы для информационных баз, которые были удалены некорректно (например, физически через СУБД, но остались в списке кластера). В логах технологического журнала это выглядит как ошибки с DBName=NULL.
Проанализируем шаги по очистке кеша сервера:
srvinfo (путь по умолчанию: C:\Program Files\1cv8\srvinfo).*.lst, если в них прописаны пути к базам. Однако более надежный метод — удалить папку srvinfo целиком (предварительно сохранив список баз и журналы регистрации) и пересоздать кластер «на чистую» после запуска службы.Выясним причину задержек через настройку рабочих процессов. В новых версиях платформы менеджер кластера rmngr более агрессивно распределяет нагрузку. Посмотрим на параметры рабочего сервера в консоли администрирования:
rphost.Если вышеперечисленные методы не помогают, проанализируем опыт сообщества по выбору версии платформы. На текущий момент выявлено, что наиболее стабильной в плане отсутствия «тормозов» фоновых заданий является ветка 8.3.20 (например, 8.3.20.2184). Если же конфигурация требует более свежую платформу (например, последние релизы БП 3.0 или ЗУП 3.1), рекомендуется использовать версию не ниже 8.3.23.1739 или 8.3.25.1394, где многие ошибки диспетчеризации были исправлены.
Важный совет: Если у вас в одном кластере работают конфигурации с разным режимом совместимости (например, современная ERP и старая УТ 10.3), попробуйте разнести их на разные серверы 1С (на разные порты) с разными версиями платформы. Это поможет избежать конфликтов в работе rmngr.
Разберем еще один «секретный» способ ускорения. В каталоге bin/conf сервера 1С создадим (или отредактируем) файл conf.cfg. Добавление параметра IgnoreNetworkCheck=1 заставляет платформу пропускать некоторые проверки сетевых интерфейсов при каждом обращении, что в ряде случаев сокращает время инициализации сеанса на 1-2 секунды, что в сумме дает ощутимый эффект при массовом запуске фоновых заданий.
Рассмотрим пример содержимого conf.cfg:
ConfLocation=C:\Program Files\1cv8\conf
IgnoreNetworkCheck=1
Подводя итог, можно сказать, что «тормоза» фоновых заданий на 8.3.22 — это комплексная проблема, связанная с сетевыми таймаутами, лицензированием и чистотой реестра кластера. Начните с синхронизации версий сервера лицензирования и настройки IPv4/nethasp.ini. В большинстве случаев именно эти действия возвращают скорость формирования отчетов к привычным 1-2 секундам.