Оптимізація агентів 1С-Бітрікс: діагностика та налаштування

На одному проекті з каталогом 12 000 товарів агенти пошуку та синхронізації 1С запускалися кожні 30 секунд через hitAgent. Кожен хіт додавав 700 мс до часу відповіді, а раз на 2 хвилини сторінка віддавалася 3 секунди через блокування. У таблиці b_agent накопичилося 400 записів з NEXT_EXEC на тиждень назад. Така ситуація типова для навантажених сайтів на Бітрікс: фонова черга агентів деградує поступово, але в результаті призводить до просідань часу відгуку та зростання навантаження на сервер. Якщо нічого не робити, бізнес втрачає конверсію та відвідувачів через повільні сторінки.

За 5 років роботи ми оптимізували агентів на 50+ проектах — від інтернет-магазинів з 100 000 товарів до корпоративних порталів Бітрікс24. Методика прибирає ці проблеми. Переводимо агентів на cron, чистимо чергу, оптимізуємо важкі завдання та налаштовуємо моніторинг. Результат — стабільний час відгуку без просідань. Інвестиції окупаються за 2–3 місяці. Згідно з офіційним керівництвом Бітрікс, переведення на cron — єдиний спосіб повністю усунути вплив агентів на користувацькі запити. На практиці cron знижує latency в середньому в 3 рази порівняно з hitAgent.

Діагностика поточного стану

Перше, що робимо — дивимося реальну картину в таблиці агентів:

SELECT NAME, ACTIVE, NEXT_EXEC, LAST_EXEC, TIMESTAMPDIFF(MINUTE, LAST_EXEC, NOW()) AS minutes_since_last FROM b_agent WHERE ACTIVE = 'Y' ORDER BY NEXT_EXEC ASC; 

Агенти з NEXT_EXEC у минулому на кілька годин або днів — це завислі завдання. Вони постійно намагаються запуститися, займають слот виконання та блокують решту агентів у черзі. Так, на одному проекті ми виявили 1200 завислих записів — після чищення час відповіді впав з 2.5 с до 0.8 с.

Друге — дивимося на час виконання важких агентів. Якщо агент пошуку (CSearchIndex::IndexAgent) виконується 45 секунд, а налаштований на запуск щохвилини — він ніколи не завершується коректно та запускається повторно до закінчення попереднього екземпляра. Це призводить до нескінченного циклу та 100% навантаження CPU.

Третє — профілюємо вплив агентів на час відповіді сторінок. Вмикаємо Бітрікс-панель налагодження або логуємо час через \Bitrix\Main\Diag\Debug::startTimeLabel / stopTimeLabel в init.php. Типова картина: 30–50 хітів на хвилину втрачають до 500 мс на виконанні агентів.

Як оптимізація агентів впливає на швидкість сайту?

Після переведення на cron та чищення черги час відгуку сторінок стає стабільним — без періодичних просідань. Навантаження на БД знижується на 20–40% у пікові моменти. Фонові завдання виконуються передбачувано і не залежать від кількості відвідувачів. Детальніше про механізм агентів можна прочитати в офіційній документації та на Wikipedia про cron.

Чи не панацея переведення на cron?

Cron вирішує проблему з блокуванням користувацьких запитів, але не виправляє неефективні агенти самі по собі. Якщо агент виконується 30 секунд і робить це кожні 2 хвилини, він просто перевантажує сервер вже поза веб-хітами. Важно:

• проаналізувати кожен важкий агент;
• розбити тривалі завдання на пакети;
• налаштувати пріоритети та моніторинг.

Ось таблиця типових важких агентів та їх оптимізація:

Переведення агентів на cron: покрокова інструкція

1. У файлі /bitrix/.settings.php або через адміністративний інтерфейс (Налаштування → Продуктивність) вкажіть:

   'agents' => [ 'value' => [ 'pull_agent_manager' => 'cron', ], ], 

2. У crontab додайте:

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

   Після переведення на cron агенти більше не виконуються в контексті веб-запитів. Час відповіді сторінок вирівнюється, зникають характерні «провали» на графіку latency кожні N секунд. Важливий нюанс: агент пошуку CSearchIndex::IndexAgent при роботі через cron може конкурувати з PHP-FPM за CPU. Виносимо його в окремий cron-скрипт з nice -n 10 та обмеженням за часом через timeout.

   Оптимізація черги та пріоритетів

   Після переведення на cron розбираємо накопичений борг:

   • Чищення завислих агентів. Агенти з NEXT_EXEC старше доби і без успішного LAST_EXEC за останні 48 годин — кандидати на деактивацію або перестворення. Для кожного уточнюємо: чи живий модуль, чи існує функція, чи є винятки в логах.
   • Оптимізація інтервалів. CSearchIndex::IndexAgent з інтервалом 30 секунд при реальному часі виконання 20 секунд — розклад на катастрофу. Перераховуємо інтервали виходячи з реального часу роботи + буфер 50%.
   • Рознесення важких агентів. Якщо кілька важких агентів (синхронізація з 1С, відправка email-розсилок, перерахунок цін) налаштовані на запуск одночасно — розносимо їх старт через NEXT_EXEC з інтервалом 5–10 хвилин.
   • Моніторинг виконання. Додаємо логування в кастомні агенти:

   function MyHeavyAgent(): string { $start = microtime(true); // ... логіка ... $elapsed = microtime(true) - $start; if ($elapsed > 10) { \Bitrix\Main\Diag\Debug::writeToFile( "MyHeavyAgent took {$elapsed}s", '', '/bitrix/logs/agent_performance.log' ); } return 'MyHeavyAgent();'; } 

   Налаштування моніторингу агентів

   Додаємо в Zabbix/Prometheus метрику кількості завислих агентів:

   SELECT COUNT(*) as stuck_agents FROM b_agent WHERE ACTIVE = 'Y' AND NEXT_EXEC < DATE_SUB(NOW(), INTERVAL 1 HOUR); 

   Якщо значення > 0 протягом більше 30 хвилин — алерт в Telegram/Slack. Це ранній індикатор проблем з cron або перевантаження сервера. Наприклад, на одному проекті алерт спрацював при 50 завислих агентах — після аналізу з'ясувалося, що cron не запускався через помилку в crontab.

   Що входить в роботу

   • Аудит поточного стану зі звітом по кожному агенту (кількість, час виконання, інтервал).
   • Переведення на cron з індивідуальним розкладом.
   • Оптимізація важких агентів (кешування, пакетна обробка).
   • Налаштування моніторингу (Zabbix/Prometheus, алерти в Telegram).
   • Інструкція з подальшого обслуговування та рекомендації.
   • Гарантія 90 днів на результат.

   Результат і гарантія

   Переведення на cron та оптимізація черги агентів прибирають періодичні просідання часу відповіді, знижують навантаження на БД у пікові моменти на 20–40%, забезпечують передбачуване виконання фонових завдань без впливу на користувацькі запити. Вартість послуги розраховується індивідуально — отримайте консультацію, ми безкоштовно оцінимо поточний стан ваших агентів і запропонуємо план оптимізації. Замовте аудит вже сьогодні.