Переведення агентів на 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С) виконуються вчасно.

Crontab для Бітрікс-віртуальної машини

Бітрікс VM (віртуальна машина) постачається з попередньо налаштованим файлом 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 для конкретного агента.

Агенти в режимі хітів після переключення. Переконуємося, що немає кешованих налаштувань. Після збереження опції — очищаємо кеш платформи.

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

Для production-проєктів рекомендуємо додати моніторинг виконання агентів. Простий варіант: скрипт, який запускається раз на 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 робочих дні.