Как перевести агенты 1С-Битрикс на cron: почта, каталог и фоновые задачи

Реклама пошла, а первый утренний посетитель ждёт страницу 8 секунд: в профайлере висит CAgent::CheckAgents. Почта с ночной выгрузки не ушла - после полуночи не было ни одного хита. По запросу "агенты битрикс cron" половина статей ведёт в Bitrix24. Ниже - как перевести фоновые задачи CMS "1С-Битрикс: Управление сайтом" на cron: проверить очередь, выбрать режим, настроить cron_events.php и crontab.

Агенты CMS - внутренние "будильники" Битрикс: по расписанию шлют почту, обновляют поиск, гоняют обмен. По умолчанию стартуют при каждом заходе на сайт. Перенос на cron убирает задержки с фронта и работает ночью без посетителей. Официально два режима: полный (все агенты только cron) и частичный (периодические на cron). Одной строки в crontab без отключения хитов мало.

Bitrix24 - облачная CRM, не наш продукт. Статья про коробочную CMS на хостинге или VMBitrix. Типичная история: подрядчик добавил в crontab root-ом строку с cron_events.php, но не отключил агенты на хитах и не прописал BX_CRONTAB_SUPPORT. В админке "всё зелёное", а 47 агентов копятся - первый дневной хит снова тянет реиндекс поиска.

Cron - таймер Linux, который запускает PHP-скрипт каждую минуту, даже когда сайт никто не открывает. Агент (CAgent) - PHP-задача в таблице b_agent: у неё есть LAST_EXEC (когда последний раз отработал) и NEXT_EXEC (когда ждёт следующий запуск). CAgent::CheckAgents - метод ядра, который в начале каждой страницы смотрит очередь; при большом хвосте он и даёт скачки TTFB.

Поймите, почему агенты на хитах тормозят сайт и ломают почту

На каждом обращении ядро вызывает CAgent::CheckAgents. Накопились реиндекс, выгрузка каталога, письма - первый дневной посетитель ждёт 3-8 секунд. Официальный порог "тяжёлого" агента - больше 10 секунд. Ночью без хитов b_event и обмен могут не стартовать: форма показывает "отправлено", письмо ждёт утра. На практике после переноса на cron p99 времени ответа часто падает с 8+ секунд до менее секунды, потому что CheckAgents уходит с фронта.

Делайте: переводите магазины и каталоги на cron до рекламы. Не делайте: не путайте CAgent CMS с AI-агентами облачной CRM. Если очередь больше 40 агентов - напишите нам, разберём профайлер до переноса.

Проверьте очередь агентов в админке и "Проверке системы"

Откройте /bitrix/admin/agent_list.php. Смотрите LAST_EXEC, NEXT_EXEC и периодичность. NEXT_EXEC в прошлом без обновления LAST_EXEC - агенты на хитах или cron не работает. "Проверка системы" (/bitrix/admin/site_checker.php) покажет режим cron. Для почты сверьте b_event - разбор в гайде по настройке почты.

1. Отсортируйте agent_list по NEXT_EXEC - просроченные сверху.
2. Отметьте агенты search, mail, catalog - они чаще дают лаги.
3. Запустите site_checker, найдите блок про агенты.
4. Типичная ошибка: crontab есть, а LAST_EXEC не меняется - хиты не отключены.
5. Подождите 2-3 интервала cron без открытия сайта и обновите список.

Делайте: скрин agent_list до и после. Не делайте: не удаляйте агенты модулей без бэкапа.

Выберите режим переноса: полный или только периодические

Режим A - все агенты только cron: agents_use_crontab=N, check_agents=N, свой /bitrix/php_interface/cron_events.php. Режим B - периодические на cron (agents_use_crontab=Y), штатный /bitrix/modules/main/tools/cron_events.php; непериодические остаются на хитах.

Итоговый вердикт: для бизнес-сайта с формами берите режим A. Режим B - если очередь маленькая. Модуль "Агенты на кроне" упрощает переключение на shared, но не заменяет CEvent в cron_events.php. Перед обновлением ядра сохраните dbconn.php и cron_events.php.

Настройте dbconn.php и cron_events.php

В dbconn.php добавьте BX_CRONTAB_SUPPORT. Для режима A создайте cron_events.php по официальному уроку:

<?php
$_SERVER['DOCUMENT_ROOT'] = realpath(dirname(__FILE__). '/../..');
define('NO_KEEP_STATISTIC', true);
define('NOT_CHECK_PERMISSIONS', true);
define('BX_CRONTAB', true);
require($_SERVER['DOCUMENT_ROOT']. '/bitrix/modules/main/include/prolog_before.php');
set_time_limit(0);
@ignore_user_abort(true);
CAgent::CheckAgents;
CEvent::CheckEvents;
define('BX_CRONTAB_SUPPORT', true);
COption::SetOptionString('main', 'mail_event_bulk', '50');
require($_SERVER['DOCUMENT_ROOT']. '/bitrix/modules/main/include/epilog_after.php');

mail_event_bulk (сколько писем отправить за один проход) поднимите до 20-100 при большой очереди b_event - иначе письма снова "висят" до хита. set_time_limit(0) обязателен: без него PHP обрежет длинный агент на 30 секундах. Если в dbconn.php стоит CACHED_b_event=false для отладки почты - не забудьте вернуть кэш после теста. На тяжёлых проектах в конец файла добавляют вызов backup.php (связка с автоматическим бэкапом) или модуль Sender для рассылок.

Делайте: для режима B указывайте штатный tools/cron_events.php. Не делайте: не запускайте два cron параллельно - второй старт заблокируется, пока первый не завершится.

Пропишите crontab на BitrixVM и shared-хостинге

Cron от пользователя bitrix, не root - иначе ломаются права на /upload. На VMBitrix: меню pool 8→3, /etc/cron.d/bx_* или /bitrix/crontab/crontab.cfg.

*/1 * * * * /usr/bin/php -f /home/bitrix/www/bitrix/php_interface/cron_events.php

Для режима B путь к tools/cron_events.php. */1 - стандарт для почты и каталога; */5 допустим на слабом тарифе, но ночная почта может запаздывать. На shared строку добавляют в панели - у Beget раздел "Cron" с командой php -f и полным путём к файлу.

Если BitrixEnv уже прописал задачу в /etc/cron.d/bx_dbName, не дублируйте - закомментируйте лишнее после проверки agent_list. Часто ломается связка CLI PHP и FPM: версии или расширения не совпадают, агент падает только из cron, а на хитах "работает". Проверка: sudo -u bitrix crontab -l и хвост /var/log/cron после ожидания одного интервала.

Делайте: смотрите NEXT_EXEC без открытия сайта. Не делайте: интервал cron не короче времени тяжёлого агента.

Пройдите чек-лист после настройки

1. site_checker: "агенты через cron".
2. agent_list: LAST_EXEC обновляется без визитов 10-15 минут.
3. Тестовое письмо уходит за 1-2 минуты.
4. Нет RUNNING=Y дольше интервала cron в b_agent.
5. Профайлер без CheckAgents с ненулевым временем.
6. Регламент - в поддержке сайта на Битрикс.
7. Сверьте NEXT_EXEC у search/mail-агентов - они первыми сигналят о сбое cron.

Если после рекламы снова растёт очередь - модуль добавил новых агентов или cron отвалился после обновления ядра. Раз в месяц сверяйте agent_list с регламентом поддержки: просроченные NEXT_EXEC - сигнал, что cron или права на сервере сломались.

Примеры после переноса - в портфолио. Сложный каталог или обмен 1С - обсудим задачу.

Автор: Максим Мольков, разработчик 1С-Битрикс.
Источники: dev.1c-bitrix.ru LESSON_ID=2943..

Частые вопросы