Почему регламентные задания обмена РИБ не запускаются в клиент-серверных базах при времени 23:59:59 и как это исправить?

При администрировании распределенных информационных баз (РИБ) системные администраторы и программисты нередко сталкиваются с ситуацией, когда регламентный автоматический обмен данными внезапно перестает выполняться по расписанию. При этом ручной запуск процедуры отрабатывает штатно, а в журнале регистрации за период предполагаемого старта нет никаких записей об ошибках или попытках запуска сеанса. Проанализируем, почему возникает такое поведение в клиент-серверном режиме и как гарантировать стабильный запуск обменов.

Причины сбоя: механика планировщика кластера 1С

Рассмотрим внутренние механизмы платформы 1С:Предприятие 8, управляющие регламентными заданиями, чтобы понять природу проблемы:

1. Дискретность опроса планировщика менеджера кластера. Процесс rmngr проверяет расписания заданий циклически с определенным внутренним интервалом (квантом времени). Если в расписании указано жесткое граничное время 23:59:59, а менеджер кластера из-за параллельных задач доходит до проверки базы на доли секунды позже (в 00:00:00 или 00:00:01), наступают следующие календарные сутки. Кластер считает задание за прошедший день пропущенным и откладывает его до следующей расчетной даты по расписанию.
2. Конкуренция фоновых заданий в пуле процессов. При размещении 10–15 информационных баз на одном сервере назначение одинакового времени старта приводит к одновременному созданию сеансов фоновых заданий. Если рабочие процессы rphost в этот момент заняты параллельными операциями (например, регламентным обновлением индекса полнотекстового поиска), задачи становятся в очередь и не успевают стартовать в выделенную секунду текущих суток.
3. Влияние синхронизации системного времени. Корректировка времени на сервере операционной системы службой времени (NTP) в районе полуночи может вызывать мгновенный сдвиг таймера, что сбивает внутренний расчет момента старта в планировщике 1С.

Способ 1. Корректировка времени и интервалов расписания

Разберем основной и самый надежный способ решения проблемы — переход от критической секунды конца дня к безопасному временному интервалу.

1. Откроем настройки расписания регламентного задания обмена данными в каждой информационной базе.
2. Изменим время запуска: вместо 23:59:59 укажем начало суток 00:00:00 (или 00:05:00) для нужных дней недели. Если обмен должен происходить ночью после закрытия рабочего дня (например, со вторника по субботу), запуск в 00:00:00 вторника гарантированно подхватит накопленные за понедельник данные.
3. Зададим интервал доступности вместо единичной секунды. Например, укажем время начала 00:00:00, время окончания 00:30:00 и установим завершение после первого успешного выполнения задания.
4. Настроим свойства повтора: в параметрах регламентного задания укажем Количество повторов при аварийном завершении (2–3 попытки) и Интервал повтора (от 120 до 300 секунд), что позволит заданию стартовать повторно при временной недоступности ресурсов кластера.

Способ 2. Каскадный (ступенчатый) запуск фоновых заданий

Выясним, как снизить пиковую нагрузку на сервер при наличии большого количества информационных баз на одном экземпляре СУБД и кластере 1С.

1. Проанализируем список баз и разделим их на группы по приоритету и объему передаваемых данных.
2. Разнесем время старта регламентных заданий с шагом в 10–15 минут:
   1. База 1 — в 23:00:00;
   2. База 2 — в 23:15:00;
   3. База 3 — в 23:30:00;
   4. База 4 — в 23:45:00;
   5. База 5 — в 00:00:00 и далее.
3. Это исключит взаимные блокировки СУБД по дисковому вводу-выводу, сетевому каналу и предотвратит исчерпание пула потоков в процессах rphost.

Способ 3. Диагностика через технологический журнал кластера

Если регламентное задание не оставляет следов в журнале регистрации, разберем настройку технологического журнала (ТЖ) для локализации причины на уровне процессов платформы.

Создадим или дополним конфигурационный файл logcfg.xml в каталоге настроек платформы со следующим содержимым:

<config xmlns="http://v8.1c.ru/v8/tech-log">
    <log location="C:\LOGS\1C_Jobs" history="72">
        <event>
            <eq property="name" value="JOB"/>
        </event>
        <event>
            <eq property="name" value="SESN"/>
        </event>
        <event>
            <eq property="name" value="EXCP"/>
        </event>
        <property name="all"/>
    </log>
</config>

Событие JOB покажет регистрацию, постановку в очередь и исполнение фонового задания менеджером кластера, событие SESN зафиксирует факт открытия сеанса, а EXCP перехватит системные исключения кластера, если фоновому заданию не хватило лицензий, памяти или лимита рабочих процессов.

Способ 4. Использование внешнего планировщика операционной системы

В сценариях со строгой зависимостью цепочки обменов можно отказаться от встроенного планировщика 1С в пользу внешнего управления через Планировщик задач Windows или демон cron в Linux.

Посмотрим на пример пакетного вызова обмена через командную строку операционной системы:

"C:\Program Files\1cv8\8.3.XX.XXXX\bin\1cv8.exe" ENTERPRISE /S "Server1C\AccountingBase" /N "ExchangeUser" /P "SecurePass123" /C "ВыполнитьОбменДанными" /DisableStartupMessages

Также инициализацию обмена можно выполнять скриптом через COM-соединение V83.COMConnector, поочередно подключаясь к базам и вызывая процедуры менеджеров узлов обмена, что обеспечивает полный программный контроль над очередностью процедур.