Мониторинг PHP-FPM на Битриксе ловит 502 до жалобы клиента

Показываем, как по статусу пула PHP-FPM на Битриксе поймать насыщение раньше 502 и зачем считать лимит воркеров от памяти сервера.

В пик акции или утренней рассылки сайт на Битриксе начинает отдавать 502 и 504, а CPU и MySQL ещё «зелёные». Пул PHP-FPM уже стоит в очереди или теряет воркеров по OOM — и команда узнаёт об этом из чата клиента, а не из алерта. Ранний сигнал пула важнее спокойного процессора: смотреть нужно listen queue и max children reached до волны HTTP-ошибок.

Как выглядит падение до жалобы клиента

Схема: от тормозов ответа до полной очереди FPM до жалобы клиента

Типичная картина: TTFB растёт до 8–12 секунд при занятых воркерах, затем на акции появляются сотни 504 в час. При этом дефолт панелей pm.max_children = 5 на выделенном VPS часто остаётся «как поставили» и хватает только в тишине. CPU может быть ниже 30%: узкое место — не железо целиком, а потолок пула и медленные запросы.

По телеметрии Reflex (выбор PHP/Laravel-продакшена, янв–апр 2026, N=4312, отчёт May 2026) связка OOM PHP-FPM и Nginx 502 даёт около 36% классифицированных инцидентов; отдельно OOM — 19.4%, 502 — 16.8%, исчерпание пула (pm.max_children) — 4.2%. В 72% случаев после OOM FPM следовал 502 в пределах 90 секунд. Без автоалертов 63% инцидентов впервые ловили уже как P1 — жалобы или ручные проверки. Эти доли — про выборку отчёта, не гарантия на любой магазин Битрикс.

Почему 502 и 504 — разные истории

Сравнение причин 502 и 504 в связке Nginx и PHP-FPM

Цепочка простая: Nginx → FastCGI-сокет или TCP → listen queue FPM → воркер. Потолок параллелизма задаёт pm.max_children, длина backlog — listen.backlog (в материалах часто порядка 511).

504 Gateway Timeout — запрос уже у воркера, но не уложился в fastcgi_read_timeout: медленный SQL/API или зависший процесс.
502 Bad Gateway — Nginx не подключился к FPM или получил отказ: переполненная очередь, падение FPM, битый сокет, OOM-kill воркера.

В error log Nginx паттерн connect() … failed (11: Resource temporarily unavailable) обычно значит полную listen queue (errno 11 / EAGAIN) — насыщение, а не «молчаливый краш». Другие подсказки: errno 2 — нет socket-файла; errno 13 — права на socket; upstream prematurely closed — воркер умер mid-request (segfault/OOM); upstream timed out — таймаут чтения.

Что смотреть на /fpm-status раньше HTTP-ошибок

Схема метрик /fpm-status для алерта раньше HTTP-ошибок

Статус пула включается директивой pm.status_path (часто /fpm-status или /status). Веб-сервер отдаёт путь напрямую в FastCGI, минуя скрипты приложения; доступ — только localhost или доверенные IP: в статусе есть URI запросов и сведения о ресурсах. Форматы: текст по умолчанию; query json, html, xml, openmetrics; детализация процессов — full. OpenMetrics — с PHP 8.1.0. Значения per-pool и сбрасываются при перезапуске FPM. Статус одного пула (www.conf) не показывает соседний пул агентов или импорта.

Поля для алерта до пользовательского падения:

listen queue — запросы в backlog, ждущие свободный процесс;
max listen queue / listen queue len — пик и допустимый размер очереди;
idle processes / active processes / total processes;
max active processes;
max children reached — сколько раз упирались в pm.max_children (≧1 уже сигнал);
slow requests — попадания в request_slowlog_timeout;
memory peak — пик памяти менеджера с момента старта FPM.

На Unix-сокетах backlog в status иногда расходится с реальностью — при сомнении сверяйте Recv-Q (ss) и error log Nginx.

Как автоматизировать алерт до волны 502

Практический poll: curl -s http://127.0.0.1/fpm-status?json и разбор полей через jq. В Nginx для endpoint — allow 127.0.0.1; deny all (плюс внутренняя сеть при необходимости).

Ранние условия, согласованные практикой 2026:

listen queue > 0 в пиковые окна или устойчиво на нескольких poll’ах;
idle processes == 0 при active ≈ max_children;
рост max children reached — дельта, не только абсолют с момента старта;
дельта slow requests за интервал (счётчик монотонный — алертить по приросту);
недоступность самого /fpm-status — отдельный warning (FPM или сокет умер);
корреляция с хостом: OOM в dmesg/kern.log часто через секунды даёт каскад 502.

Бюджет RAM вместо слепого роста max_children

RSS одного PHP-FPM-процесса Битрикса в разборах — ориентир примерно 50–120 MB (с модулями sale/catalog/iblock чаще ближе к 80–100+ MB). Считать по ps/RSS, не по memory_limit в php.ini.

Формула порядка: pm.max_children ≈ (RAM_total − RAM_OS − RAM_DB − запас) / RSS_одного_воркера, с запасом 10–15% памяти. Ориентиры из гайдов (железо и RSS решают): VPS 2 ГБ — часто 10–15 children; 4 ГБ — около 25–35 (в одном кейсе ~37–38 при ~68 MB/процесс); 8 ГБ — 30–50+ при учёте MySQL/OS. Слепой рост children без бюджета RAM превращает очередь в OOM-каскад.

Для переменной нагрузки Битрикса чаще pm = dynamic; ondemand даёт лишний cold-start; static — при стабильном трафике и жёстком контроле RAM. pm.max_requests 500–1000 — recycle воркеров против утечек и фрагментации. Отдельные пулы: фронт / агенты / импорт 1С — чтобы длинный импорт не съедал children пользовательского пула. Включайте request_slowlog_timeout (в гайдах 2–5 с) и slowlog: иначе рост children маскирует медленные скрипты. Увеличивать только fastcgi_read_timeout «от 504» без правки пула — очередь и память раздуваются дальше. После правки пула предпочтителен systemctl reload phpX.Y-fpm (graceful), не полный restart — restart рвёт in-flight и даёт новые 502.

Свежий контекст стека (авг 2026): гайды под Битрикс описывают Ubuntu 22.04/24.04 + Nginx + PHP 8.3-FPM, dynamic-пул и расчёт children от RAM; в разборах ответа снова советуют status page и slowlog при высоком TTFB и спокойном CPU.

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

Чем 502 отличается от 504 в связке Nginx и PHP-FPM?

504 значит, что запрос уже попал к воркеру FPM, но не уложился в fastcgi_read_timeout. 502 — Nginx не смог нормально достучаться до FPM: очередь переполнена, служба упала, сокет битый или воркер убит OOM.

Какие поля /fpm-status алертить раньше жалоб пользователей?

Раньше HTTP-ошибок смотрят listen queue > 0, нулевые idle при active у потолка, дельту max children reached и прирост slow requests; отдельно — недоступность самого status endpoint.

Почему нельзя просто поднять pm.max_children «с запасом»?

Без бюджета RAM лишние воркеры упираются в память: RSS процесса Битрикса часто десятки–сотни мегабайт, и слепой рост children превращает очередь в OOM, а за ним — каскад 502.

Reload или restart PHP-FPM после правки пула?

Предпочтительен graceful systemctl reload phpX.Y-fpm: полный restart обрывает текущие запросы и сам может породить новые 502.

Как BX Pulse помогает раньше эскалации от клиента

BX Pulse следит за доступностью и техническим состоянием проектов на 1С-Битрикс и помогает замечать сбои до обращения клиента. Для сценария с пулом PHP-FPM имеет смысл держать внешнюю проверку ответа сайта и уведомления при 5xx — в паре с внутренним poll /fpm-status на сервере. Добавьте первый сайт и настройте уведомления.