Мониторинг нагрузки на 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%.