Ситуация, когда в клиент-серверном варианте «1С:Предприятие» внезапно прекращается выполнение всех фоновых заданий, является критической для бизнеса. Особенно часто это проявляется при выполнении регламентных операций, таких как рассылка отчетов, закрытие месяца или синхронизация данных. В версии платформы 8.3.15.1830 пользователи столкнулись с проблемой: одно зависшее задание по рассылке почты может парализовать всю очередь планировщика. Рассмотрим детально, почему это происходит и как не только «вылечить» сервер сейчас, но и предотвратить проблему в будущем.
Если работа предприятия встала, первым делом необходимо восстановить работоспособность планировщика. Разберем по шагам, как это сделать правильно, начиная от самых мягких методов и заканчивая принудительной очисткой на уровне операционной системы.
Шаг 1: Использование консоли администрирования серверов 1С
Проанализируем список активных сеансов. В консоли администрирования перейдем в ветку «Сеансы». Нам нужно найти те, у которых в колонке «Вид клиента» указано «Фоновое задание». Если вы видите задания, которые длятся аномально долго (например, рассылка отчета идет несколько часов), попробуйте удалить этот сеанс. Однако, как показывает практика работы с версией 8.3.15, консоль не всегда может разорвать соединение, если поток внутри процесса rphost «мертво» заблокирован.
Шаг 2: Завершение процессов на уровне ОС
Если удаление сеанса в консоли не помогает, выясним, какой именно рабочий процесс rphost занят выполнением этого задания. В консоли 1С можно посмотреть номер процесса (PID). Откроем «Диспетчер задач» или «Resource Monitor» на сервере приложений и принудительно завершим этот процесс. Важно помнить: при завершении rphost могут пострадать другие пользователи, чьи сеансы обслуживались этим же процессом. Поэтому в идеале стоит настроить кластер так, чтобы количество сеансов на один процесс было минимальным.
Шаг 3: Перезапуск службы агента
В самых тяжелых случаях, когда планировщик (менеджер кластера rmngr) перестает назначать новые задания, поможет только полный перезапуск службы 1C:Enterprise 8.3 Server Agent. После этого очередь заданий будет инициализирована заново.
Почему одно задание «вешает» все остальные? Разберем механизм работы планировщика. За запуск фоновых заданий отвечает процесс rmngr. Он отслеживает таблицу ConfigCases и регламентные задания в базе данных. Когда наступает время запуска, менеджер ищет свободный «слот» в рабочих процессах rphost.
В платформе 8.3.15.1830 существует известная проблема: если процесс rphost потребил слишком много памяти или столкнулся с внутренней ошибкой при работе с объектом ИнтернетПочта, он может перестать отвечать менеджеру кластера. При этом менеджер считает, что задание все еще выполняется, и не высвобождает ресурсы. Если лимит фоновых заданий на сервер исчерпан (параметр Количество фоновых заданий на один процесс), новые задания просто не будут ставиться в очередь.
Рассмотрим специфику задания по рассылке отчетов. Чаще всего зависание происходит на этапе взаимодействия с SMTP-сервером. Посмотрим на типичный код, который может вызвать проблему, если не установлены таймауты:
Почта = Новый ИнтернетПочта;
Профиль = Новый ИнтернетПочтовыйПрофиль;
// Настройки профиля...
Попробовать
Почта.Подключиться(Профиль);
Почта.Послать(Сообщение);
Почта.Отключиться();
Исключение
ЗаписьЖурналаРегистрации("Ошибка почты", УровеньЖурналаРегистрации.Ошибка, , , КраткоеПредставлениеОшибки(ИнформацияОбОшибке()));
КонецПопытки;
Проблема заключается в том, что в некоторых сборках 8.3.15 метод Подключиться() или Послать() мог уходить в бесконечное ожидание, если почтовый сервер (например, из-за настроек SSL/TLS) не закрывал соединение корректно. Поскольку это происходит на уровне системных библиотек, 1С не может прервать выполнение этого участка кода самостоятельно. Для решения этой проблемы в более современных версиях конфигураций используется установка таймаута в самом объекте:
Почта = Новый ИнтернетПочта;
// Установка таймаута в секундах обязательна для фоновых заданий
Почта.Таймаут = 60;
Выясним еще одну причину: почему задания висят в статусе «Выполняется», но ничего не делают. Проанализируем состояние процессов на стороне SQL Server. Если фоновое задание формирует тяжелый отчет, оно может запрашивать данные из таблиц, которые в этот момент заблокированы другим процессом (например, обновлением полнотекстового поиска или пересчетом итогов).
В консоли SQL Server Management Studio (SSMS) выполним запрос для поиска блокировок:
SELECT
r.session_id,
r.status,
r.blocking_session_id,
r.wait_type,
t.text AS [QueryText]
FROM sys.dm_exec_requests r
CROSS APPLY sys.dm_exec_sql_text(r.sql_handle) t
WHERE r.blocking_session_id <> 0;
Если мы видим, что фоновое задание (процесс 1С) находится в состоянии SUSPENDED и у него указан blocking_session_id, значит, проблема не в платформе 1С, а в оптимизации запросов или конфликтах блокировок в базе данных.
Чтобы исключить повторение ситуации, когда из-за одного отчета встает вся работа, выполним следующие настройки:
8.3.15.1830 имеет ряд задокументированных ошибок, связанных с утечками памяти в rphost. Рекомендуется переход на стабильные ветки, такие как 8.3.21 или выше, где механизмы управления сеансами переработаны.Критический объем памяти процессов. При достижении этого порога сервер будет автоматически перезапускать проблемный rphost, не дожидаясь его полного зависания.snccntxt (в папке данных сервера 1С) остаются битые файлы состояний. При плановом обслуживании сервера рекомендуется очищать содержимое папок reg_1541 (за исключением файлов конфигурации кластера), чтобы планировщик начинал работу с «чистого листа».Подводя итог, можно сказать, что зависание всех заданий в версии 8.3.15 — это чаще всего комбинация недоработок платформы и отсутствия таймаутов во внешних вызовах (почта, веб-сервисы). Регулярный мониторинг состояния рабочих процессов и своевременное обновление платформы являются лучшими способами защиты от подобных инцидентов.