Проблема зависания фоновых и регламентных заданий — одна из наиболее неприятных ситуаций для системного администратора и разработчика 1С. Особенно остро эта проблема проявилась в версиях платформы 8.3.15.1830 и 8.3.15.1778. В этой ситуации новые задания перестают запускаться, а старые «висят» в статусе выполнения бесконечно долго, блокируя важные бизнес-процессы: от рассылки отчетов до расчета заработной платы. Проанализируем причины этого поведения и разберем пошаговый алгоритм восстановления работоспособности системы.
В архитектуре 1С:Предприятия планировщик заданий работает по определенным правилам. Если одно из заданий (например, «Рассылка отчетов» или «Обновление индекса ППД») входит в бесконечный цикл или ожидает ответа от внешнего ресурса (SMTP-сервера, веб-сервиса), оно может захватить поток управления. Рассмотрим критическую особенность: пока выполнение фонового задания не завершится (успешно или с ошибкой), в некоторых случаях менеджер кластера не может инициировать запуск следующих заданий из очереди. Это создает эффект «пробки», который мы и наблюдаем.
Первым делом проанализируем состояние сеансов. Для этого откроем стандартную консоль администрирования кластера серверов 1С. Разберем наши действия:
Если штатные средства не справляются, рассмотрим использование более мощного инструмента — Инструментария разработчика (ИР). Это набор обработок, которые работают в толстом клиенте и позволяют более гибко управлять объектами системы. Найдем в нем «Консоль заданий».
Разберем преимущество этого метода: в ИР можно увидеть не только текущие сеансы, но и детальное состояние регламентных заданий. Мы можем попробовать отключить использование конкретного задания или изменить его расписание прямо «на лету». Если мы столкнулись с предопределенным заданием (например, загрузка курсов валют), которое невозможно удалить, через ИР его можно просто деактивировать, сняв признак использования.
В некоторых случаях помогает полная программная очистка всех фоновых заданий. Рассмотрим пример кода, который можно запустить во внешней обработке для принудительной отмены всех активных процессов:
ВыборкаЗаданий = ФоновыеЗадания.ПолучитьФоновыеЗадания(Новый Структура("Состояние", СостояниеФоновогоЗадания.Активно));
Для Каждого Задание Из ВыборкаЗаданий Цикл
Попытка
Задание.Отменить();
Сообщить("Задание " + Задание.Метаданные.Имя + " отменено.");
Исключение
Сообщить("Не удалось отменить задание: " + ОписаниеОшибки());
КонецПопытки;
КонецЦикла;
Этот метод позволяет «разгрузить» менеджер заданий, если консоль администрирования не дает нужного результата.
Если задания продолжают зависать сразу после запуска, проанализируем состояние серверного кэша. В платформе 8.3.15 часто случаются сбои в папке snaccfg, где хранятся конфигурационные данные кластера. Посмотрим, как правильно выполнить глубокую очистку:
srvinfo (обычно это C:\Program Files\1cv8\srvinfo).reg_1541).snaccfg и временные файлы, но не трогайте файлы с расширением .lst, так как в них хранится список баз и пользователей кластера.rmngr (менеджер кластера) пересоздать планировщик заданий с «чистого листа».Иногда корень проблемы лежит глубже уровня 1С — в блокировках таблиц на уровне СУБД. Проанализируем ситуацию в MS SQL Management Studio. Если фоновое задание пытается обновить индекс полнотекстового поиска (ППД) или выполнить тяжелую рассылку отчетов, оно может заблокировать таблицу _JobSchedule.
Используем системный монитор Activity Monitor или выполним запрос для поиска заблокированных процессов. Если мы видим процесс в состоянии suspended с типом ожидания LCK_M_X, значит, транзакция 1С ожидает освобождения ресурсов SQL. В этом случае поможет только «убийство» процесса (Kill) на стороне SQL-сервера или перезапуск рабочего процесса rphost, который инициировал эту транзакцию.
Как показывает практика, задание «Обновление индекса ППД» является частой причиной «зависания» всей очереди. Если файлы индекса повреждены, задание будет пытаться их обработать бесконечно. Рассмотрим алгоритм решения:
Мы проанализировали основные причины зависания фоновых заданий на платформе 8.3.15. Подведем итог нашим действиям. В большинстве случаев помогает принудительное завершение сеанса через консоль или остановка процессов rphost. Однако для стабильной работы рекомендуем:
rphost, чтобы при зависании одного процесса остальные продолжали работать.