Моніторинг навантаження на CPU сервера 1С-Бітрікс
CPU-навантаження на Бітрікс-сервері зростає поступово, а падіння продуктивності помічають тоді, коли load average вже 10–20 при 4 ядрах і запити починають таймаутитися. На той момент діагностувати причину складніше — потрібні дані про попереднє навантаження. Правильно побудований моніторинг фіксує аномалії в момент їх виникнення.
Джерела CPU-навантаження на Бітрікс
Навантаження на CPU в PHP-застосунку розподіляється між кількома процесами:
- php-fpm — виконання PHP-коду: генерація сторінок, обробка форм, крон
- mysqld / mariadb — SQL-запити: сортування, JOIN без індексів, COUNT(*)
- nginx — обробка статики, SSL offload, gzip
- opcache invalidation — при частих деплоях PHP перекомпільовує файли
Важливо розрізняти: якщо CPU на 90% зайнятий mysqld, проблема не в PHP. top, htop, pidstat покажуть розподіл.
Інструменти моніторингу
Швидка діагностика в реальному часі:
# CPU по процесах, оновлення кожні 2 с
htop -d 20
# Навантаження по ядрах (mpstat з sysstat)
mpstat -P ALL 5
# Що робить конкретний процес php-fpm
strace -p [PID] -e trace=network,file -T 2>&1 | head -50
Статус PHP-FPM:
# Якщо ввімкнено pm.status_path = /php-fpm-status
curl -s http://127.0.0.1/php-fpm-status?full | grep -E "status|active|idle|requests"
Дивимося на active processes — якщо постійно дорівнює max_children, воркерів не вистачає і запити стають у чергу. Це не високий CPU, але симптом схожий: сайт гальмує.
Prometheus + Grafana — постійний моніторинг:
Метрики від node_exporter:
# CPU utilization по ядрах (виключаємо idle)
100 - (avg by(cpu)(rate(node_cpu_seconds_total{mode="iowait"}[5m])) * 100)
# Сумарне навантаження
100 - (avg(rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)
# load average / кількість ядер
node_load1 / count(count(node_cpu_seconds_total{mode="idle"}) by (cpu))
Алерт при load average / cores > 2 протягом 10 хвилин:
- alert: HighCPULoad
expr: (node_load1 / count(count(node_cpu_seconds_total) by (cpu))) > 2
for: 10m
labels:
severity: warning
Cron-завдання Бітрікс як джерело навантаження
Бітрікс використовує cron_events (таблиця b_agent) — агенти запускаються через псевдо-крон при кожному запиті сторінки або через реальний cron. Агенти, що працюють довго або часто, споживають CPU:
-- Знаходимо важкі агенти
SELECT NAME, MODULE_ID, LAST_EXEC, NEXT_EXEC,
TIMEDIFF(NEXT_EXEC, LAST_EXEC) AS period
FROM b_agent
WHERE ACTIVE = 'Y'
ORDER BY LAST_EXEC DESC
LIMIT 20;
Агенти типу CSearch::IndexAjax() або CCatalogImport::ImportByAgent() при великих каталогах можуть займати кілька секунд CPU на кожен запуск. Їх переносять на реальний cron з обмеженням за часом:
# /etc/cron.d/bitrix
*/5 * * * * www-data /usr/bin/php -f /var/www/bitrix/bitrix/modules/main/tools/cron_events.php > /dev/null 2>&1
Кейс: пікове навантаження опівдні
Інтернет-магазин: щодня з 12:00 до 13:00 CPU досягав 95–100%, сайт відповідав із затримками 10–30 с. Решту часу — навантаження 20–30%. Через atop (пише історію за замовчуванням) знайшли: саме в цей проміжок запускався агент оновлення пошукового індексу (CSearch::IndexAjax), причому він був налаштований на PERIOD = 3600 секунд і запускався 12 разів протягом години (12 паралельних запитів на різних сторінках ініціювали його). Після переведення агента на реальний cron з обмеженням nice -n 19 навантаження в пік знизилося до 45%.