Перевод агентов на cron 1С-Битрикс

Перевод агентов на cron 1С-Битрикс

На загруженном сайте агенты Битрикса — это не просто «фоновые задачи». Это PHP-код, который выполняется синхронно во время обработки пользовательского запроса. Если в момент хита наступило время запустить несколько агентов — пользователь ждёт, пока они отработают. На высоконагруженных проектах это одна из причин «случайных» медленных страниц.

Перевод агентов на cron — это перенос их выполнения из обработки HTTP-запросов в отдельный процесс, который запускается по расписанию независимо от трафика.

Проблема с агентами «на хитах»

Стандартный механизм агентов в Битриксе: таблица b_agent проверяется при каждом хите. Код проверки находится в /bitrix/modules/main/include/prolog_before.php — то, что вы видите в профайлере как CAgent::CheckAgents().

Последствия для производительности:

• Агент CSearch::ReIndexAll() (переиндексация поиска) может работать 5–30 секунд — и все это время один PHP-процесс занят не обслуживанием клиента.
• Агент 1С-выгрузки создаёт пиковую нагрузку в момент выполнения.
• Несколько агентов, попавших в один хит — суммируют время.

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

Два режима работы агентов

В Битриксе в настройках главного модуля (/bitrix/admin/settings.php?lang=ru&mid=main) есть параметр «Агенты» с двумя вариантами:

«Агенты работают через хиты» — стандартный режим. Агенты выполняются при HTTP-запросах.

«Агенты работают через cron» — режим, при котором агенты НЕ запускаются на хитах. Вместо этого для их запуска используется cron-задача, вызывающая /bitrix/modules/main/tools/cron_events.php.

Это глобальный переключатель для всех агентов на сайте. Нельзя перевести «только некоторые агенты» через этот интерфейс.

Как перевести агентов на cron

Шаг 1. Настройка cron. До переключения режима нужно убедиться, что cron-задача настроена и работает. Иначе после переключения агенты перестанут выполняться вообще.

* * * * * /usr/bin/php -f /var/www/site/bitrix/modules/main/tools/cron_events.php >> /var/log/bitrix_cron.log 2>&1

Проверяем, что скрипт выполняется без ошибок: смотрим лог, убеждаемся, что NEXT_EXEC агентов обновляется.

Шаг 2. Переключение режима. В /bitrix/admin/settings.php для модуля main — параметр «Агенты используют cron» — включаем. Сохраняем.

Шаг 3. Проверка. После переключения:

• Открываем несколько страниц сайта. В профайлере не должно быть CAgent::CheckAgents() с ненулевым временем выполнения.
• Ждём несколько минут. В /bitrix/admin/agent_list.php NEXT_EXEC агентов должны обновляться.
• Проверяем, что критичные агенты (отправка уведомлений, обмен с 1С) выполняются в срок.

Кронтаб для Битрикс-виртуальной машины

Битрикс VM (виртуальная машина) поставляется с preconf-файлом crontab. Путь к скриптам в стандартной VM:

*/5 * * * * /usr/bin/php -f /home/bitrix/www/bitrix/modules/main/tools/cron_events.php > /dev/null 2>&1

В BitrixVM агенты по умолчанию работают через cron с частотой раз в 5 минут. Если нужна частота раз в минуту — меняем /5 на пустое значение для первого поля.

Тонкости и подводные камни

Агенты, которые не стоит переводить на cron. Некоторые агенты предполагают контекст сессии пользователя или сайта. В режиме cron они выполняются без HTTP-контекста, что иногда вызывает ошибки. Проверяем каждый критичный агент отдельно.

Временная зона. cron по умолчанию использует системную временную зону. Убедитесь, что она совпадает с настройками временной зоны в Битриксе. Расхождение на час вызывает путаницу при анализе логов.

Права на выполнение. Скрипт cron_events.php запускается от системного пользователя (обычно www-data или bitrix). Этот пользователь должен иметь права на чтение файлов сайта и запись в /bitrix/cache/.

Нагрузка от cron. Если cron_events.php запускается каждую минуту, а агентов много — проверяем, не накапливаются ли параллельные процессы. Добавляем блокировочный файл:

* * * * * /usr/bin/flock -n /tmp/bitrix_cron.lock /usr/bin/php -f /var/www/site/bitrix/modules/main/tools/cron_events.php > /dev/null 2>&1

flock -n предотвращает параллельный запуск, если предыдущий экземпляр ещё не завершился.

Кейс: снижение времени ответа страниц каталога

Клиент — крупный онлайн-магазин стройматериалов. Жалобы: «иногда страницы открываются по 5–10 секунд, но это не всегда и не стабильно». Профайлер показал: в 10% запросов CAgent::CheckAgents() добавляет 3–8 секунд — это агент переиндексации поиска CSearchIndex::ReIndexElement() и агент обработки очереди уведомлений.

Эти агенты были тяжёлыми: поиск переиндексировал пачку товаров при каждом вызове, занимая несколько секунд. При попадании в пользовательский хит — задержка ощущалась как «тормоза».

Решение: перевод всех агентов на cron. После переключения:

• CAgent::CheckAgents() исчез из профайлера.
• 99-й перцентиль времени ответа снизился с 8,2 секунды до 0,9 секунды.
• Агенты переиндексации стали работать раз в минуту через cron — незаметно для пользователей.

Сроки

Перевод агентов на cron — 4–8 часов: настройка crontab, проверка выполнения агентов в новом режиме, тестирование критичных функций (уведомления, выгрузки, индексация). С комплексной диагностикой и оптимизацией медленных агентов — 1–3 рабочих дня.

Запрос «почему агент не запускается в нужное время» — один из самых частых при диагностике Битрикс-проектов. Проверяешь настройки — агент активен, период задан корректно. Но выполняется нерегулярно: иногда раз в 5 минут, иногда раз в час. Причина почти всегда одна: агенты работают в режиме «на хитах», а трафик на сайте неравномерный.

Перевод агентов на cron — не разовая операция. Это изменение архитектуры выполнения фоновых задач на проекте.

В чём проблема режима «на хитах»

Когда агенты работают на хитах, каждый HTTP-запрос к сайту проверяет таблицу b_agent:

SELECT * FROM b_agent WHERE ACTIVE='Y' AND NEXT_EXEC <= NOW()

Если такие агенты есть — они запускаются в рамках этого же PHP-процесса, обслуживающего HTTP-запрос. Это создаёт сразу три проблемы:

Непредсказуемость времени выполнения. Агент с периодом 300 секунд (5 минут) в реальности запускается «когда придёт следующий посетитель после истечения периода». В рабочее время — примерно вовремя. В 4 часа ночи — через несколько часов.

Замедление страниц. Агент выполняется в рамках HTTP-запроса. Тяжёлый агент (например, синхронизация с 1С или отправка пакета писем) увеличивает время ответа страницы для конкретного пользователя, который «попал» на выполнение агента.

Ограничение по времени выполнения. max_execution_time PHP — обычно 30–60 секунд. Если агент не укладывается, он прерывается, оставляя работу незавершённой. Следующий запуск — когда придёт следующий посетитель.

Перевод на cron: полный алгоритм

Шаг 1. Проверка текущего состояния.

В административной панели: «Настройки → Настройки модулей → Главный модуль». Параметр «Использование агентов» — если стоит «В режиме хитов», переводим.

Шаг 2. Настройка crontab.

Подключаемся к серверу по SSH. Открываем crontab:

crontab -e -u bitrix

Добавляем строки:

# Агенты Битрикс — каждую минуту
* * * * * /usr/bin/php -f /home/bitrix/www/bitrix/modules/main/tools/agent_exec.php > /dev/null 2>&1

# Очередь почтовых событий — каждые 5 минут
*/5 * * * * /usr/bin/php -f /home/bitrix/www/bitrix/modules/main/tools/event_exec.php > /dev/null 2>&1

Путь к php уточняем через which php. На BitrixEnv — обычно /usr/bin/php, иногда /usr/local/bin/php7.4 или аналог.

Шаг 3. Переключение режима в Битриксе.

После того как cron настроен и проверен (убедились, что agent_exec.php запускается без ошибок) — переключаем режим в настройках. «Использование агентов» → «Через cron». Сохраняем.

С этого момента Битрикс перестаёт запускать агенты на хитах — только cron.

Шаг 4. Проверка выполнения.

Проверяем b_agent через несколько минут:

SELECT NAME, LAST_EXEC, NEXT_EXEC, PERIOD 
FROM b_agent 
WHERE ACTIVE='Y' 
ORDER BY LAST_EXEC DESC 
LIMIT 20;

LAST_EXEC должен обновляться. Если не обновляется — cron не работает. Проверяем системный лог cron (/var/log/cron) и вывод ошибок PHP.

Частые проблемы при переводе

Неправильный путь к PHP. agent_exec.php вызывается с нужным интерпретатором. Если путь не тот — скрипт просто не запускается. Проверяем:

/usr/bin/php -f /home/bitrix/www/bitrix/modules/main/tools/agent_exec.php

Должен выполниться без ошибок.

Права доступа. Скрипт должен выполняться от имени пользователя, который владеет файлами сайта. Если cron от root, а файлы Битрикса принадлежат bitrix — могут возникать ошибки записи кеша.

Множественные запуски одного агента. Если агент долгий (дольше 60 секунд), а cron запускает его каждую минуту — могут возникнуть параллельные экземпляры. Решение: защита от параллельного запуска через файл-блокировку внутри агента или увеличение интервала cron для конкретного агента.

Агенты в режиме хитов после переключения. Убеждаемся, что нет кешированных настроек. После сохранения опции — очищаем кеш платформы.

Мониторинг и алерты

Для продакшн-проектов рекомендуем добавить мониторинг выполнения агентов. Простой вариант: скрипт, который запускается раз в 10 минут и проверяет, что LAST_EXEC критичных агентов не старше порогового значения. Если агент не выполнялся дольше PERIOD * 3 — отправляем алерт в Telegram или по email.

Кейс: нерабочая ночная синхронизация с 1С

Клиент — интернет-магазин бытовой техники. Агент синхронизации остатков с 1С настроен с периодом 3600 секунд (раз в час). На практике выполнялся нерегулярно: иногда раз в 2–3 часа, иногда пропускал несколько итераций. В ночное время остатки не обновлялись до утра.

Диагностика: агенты работали «на хитах». Ночью трафик падал до 1–2 хитов в час — агент «ждал» посетителя.

Решение: перевели агенты на cron с запуском каждую минуту. Агент синхронизации стал выполняться строго по расписанию. Побочный эффект: ночное время стало «окном» для тяжёлых задач без влияния на пользователей.

Дополнительно обнаружили: агент синхронизации иногда выполнялся дольше 60 секунд (ограничение max_execution_time). После перевода на cron добавили set_time_limit(0) в начало скрипта агента — теперь он гарантированно завершает цикл.

Сроки

Перевод агентов на cron — 4–8 часов работы: диагностика текущего режима, настройка crontab, тестирование, мониторинг первых выполнений. Для сложных окружений с несколькими серверами или специфическими агентами — 1–2 рабочих дня.