Группы похожих SQL валят Битрикс24 без 502 при зелёном сервере

Утром в чате клиента снова скрины: карточка CRM открывается около 10 секунд, бизнес-процесс «висит», иногда сыплются ошибки — через примерно 15 минут всё само проходит. Админ смотрит CPU, RAM и диск: всё зелёное, явного 502 нет. Докупить воркер PHP-FPM или «ещё немного памяти» эту картину не объясняет.

Часто фраза «сервер работает нормально» означает другое место расследования. Внутри портала в момент жалобы — всплеск групп похожих SQL, а не один тяжёлый SELECT и не Bad Gateway на nginx.

Как выглядит инцидент при «здоровом» железе

Типичный сценарий из разбора кейса на vc.ru (июнь 2026): тормоза периодические, не постоянные. Linux-мониторинг в момент жалоб не упирается в CPU, память свободна, диск живой — классический «всё в порядке, а пользователи правы».

Ложный круг подозрений обычно такой: интеграции → бизнес-процессы → фоновые агенты. Каждый слой может быть причастен, но корневая картина в том кейсе другая. MySQL тратит огромное время на пачку однотипных запросов, которые одновременно делают одну и ту же работу. По отдельности каждый запрос выглядит относительно безобидным; вместе они валят UX портала без обязательного 502.

Заказчику не важны проценты в top. Важно, что произошло в момент проблемы — желательно сразу, а не через неделю по обрывкам логов.

Почему валит именно «группа», а не один монстр в slow log

Механизм «роя похожих» хорошо стыкуется с типичными паттернами на объёме CRM. Один тяжёлый SELECT в slow log — удобная мишень, но портал чаще душит пачка однотипной работы.

• N+1 в UI списка: десятки сделок тянут сотни дополнительных запросов к контактам, компаниям, пользовательским полям.
• Повторяющийся шаблон одного и того же запроса много раз на хит — часто отсутствие кеша или поэлементная выборка свойств.
• Обработчик на каждое обновление сделки × массовое действие = взрыв однотипных запросов.
• ORM без префикса «=» уходит в LIKE вместо точного равенства — на десятках тысяч записей разница кратная даже на индексированном поле.
• Пользовательские поля сделок (таблицы вроде b_uts_crm_deal / b_utm_crm_deal): индексы на UF Битрикс сам не создаёт; фильтр по такому полю на объёме легко превращает список в минуты ожидания.

На практике сигнал «группа» — не единственная строка с максимальным временем, а всплеск набора похожих запросов. Ориентиры из практики отладки Битрикс: больше 100–150 запросов на хит; один шаблон 10+ раз; SQL занимает больше 30–50% времени страницы, а при больше 70% — копать именно запросы.

С чего начать диагностику в коробочном Битрикс24

Мониторинг сервера ≠ мониторинг Битрикса. Нужны сигналы внутри портала в окне жалоб — иначе снова увидите зелёный top и красных пользователей.

Штатный Perfmon (документация 1С-Битрикс):

• Настройки → Настройки продукта → Настройки модулей → Монитор производительности: включить «Вести журнал SQL запросов».
• Опционально: «Сохранять стек вызова для SQL запросов»; «Записывать только медленные SQL запросы» + порог времени.
• Смотреть страницу Настройки → Производительность → SQL запросы (видна только при включённом журнале): фильтр по хиту / компоненту, колонки времени, модуля, текста; меню «План исполнения» (EXPLAIN).
• Сортировка по времени — путь к ТОПу медленных за период сбора.

Ограничение окна: без режима «только медленные» монитор живёт до 1 часа; с этим режимом — до 1 недели. Данные есть лишь за интервал, когда монитор был включён. Постфактум «что было три дня назад» штатным Perfmon не восстановить, если журнал тогда не писали.

Параллельно MySQL: slow_query_log=1, long_query_time=1, и полезно log_queries_not_using_indexes=1 — ловит «быстрые» full scan до пробки на объёме. На практике первые 3–4 запроса в slow log часто дают львиную долю проблемы. В EXPLAIN плохо type=ALL, Using filesort / Using temporary; смотреть key и rows.

Панель отладки на странице (debug в .settings.php / $DBDebug): кандидаты — запросы больше 0.01 с или больше 50 мс при повторе шаблона. Если SQL больше 70% времени страницы — копать запросы; большое PHP при малом SQL — код компонентов.

Воспроизведите жалобу пока журнал включён. Собирайте вместе активность REST, MySQL, число одновременных запросов, тяжёлые SQL-группы и блокировки — не только live top.

Что чинить раньше, чем покупать железо

«Купить сервер помощнее» часто мимо. На ~50 тысяч сделок список на 8–15 секунд и зависающий фильтр по UF лечатся индексами, правкой ORM и сокращением N+1, а не гигабайтами RAM. После индекса на поле фильтра список в кейсах с объёмом падал с десятков секунд до долей секунды.

Практический порядок:

1. Поймать всплеск похожих запросов (Perfmon SQL + slow log) в момент деградации.
2. EXPLAIN / индексы UF / убрать LIKE там, где нужен «=» / сократить select * с лишними JOIN к UF.
3. Срезать N+1 и обработчики на массовых действиях; REST — batch вместо сотен одиночных вызовов.
4. Смежные узкие места не путать с SQL-группами: очередь агентов (хиты → cron), file-кеш → Redis/Memcached, тяжёлые интеграции в очереди. Отдельно: зелёный CPU бывает и при file lock сессий — другие инструменты проверки.
5. innodb_buffer_pool_size: дефолт 128 МБ на машине с несколькими ГБ RAM часто гоняет чтение с диска; цель hit rate buffer pool больше 99% — после разбора запросов, не вместо него.

Дифференциальный диагноз: даже на мощном железе коробочный Битрикс24 может отдавать задержки и 502 из‑за чатов / Push & Pull. Это другая ветка, не замена разбору SQL-групп.

Почему «включу Perfmon на будущее» может не спасти

Штатный монитор — окно сбора, не круглосуточная история инцидентов. Без заранее включённого журнала в момент всплеска вы снова увидите зелёный top и красных пользователей. Нужна история до / во время / после, а не только «сайт открывается» как критерий здоровья.

Свежий контекст канала мониторинга Битрикс: аптайм ≠ здоровье портала; нужны сигналы внутри продукта и инциденты до жалобы клиента. В чек-листах скорости по Битрикс отдельно выделяют разбор медленных SQL и монитор производительности — оценка панели меньше 30 без плана ускорения уже повод не разгонять нагрузку рекламой.

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

Почему портал тормозит, а CPU и RAM зелёные и 502 нет?

В кейсе vc.ru (июнь 2026) деградация шла от всплеска групп похожих SQL: MySQL тратил много времени на пачку однотипной работы, при этом классический серверный мониторинг выглядел нормально; отдельного 502 в описании не было — страдал UX и логика портала.

С чего начать диагностику в коробочном Битрикс24?

Включите монитор производительности и журнал SQL («Вести журнал SQL запросов», при необходимости только медленные + стек), смотрите Настройки → Производительность → SQL запросы и план исполнения; параллельно включите MySQL slow_query_log с log_queries_not_using_indexes и воспроизведите жалобу в окне сбора.

Как отличить один тяжёлый запрос от группы похожих?

Ищите всплеск набора похожих запросов, выполняющих одну работу одновременно, а не единственную строку с максимальным временем; на практике это повторяющийся шаблон 10+ раз, N+1 на хит или больше 100–150 запросов на страницу.

Почему одного Perfmon «на будущее» может не хватить?

Без режима «только медленные» монитор живёт до одного часа, с режимом — до одной недели, но данные есть лишь за период включения; без журнала в момент всплеска постфактум из Perfmon не восстановить, а кейс подчёркивает нужду видеть историю до, во время и после, а не только live top.

Имеет ли смысл сразу масштабировать железо?

Сначала slow log, EXPLAIN, индексы UF, правки ORM и обработчиков; иначе на более дорогой машине останется та же логика запросов. Аудит узкого места (CPU, диск, агенты, код) идёт раньше покупки RAM.

Как заметить раньше

BX Pulse следит за доступностью и техническим состоянием проектов на 1С-Битрикс и коробочных порталов Битрикс24 и помогает замечать сбои до обращения клиента. Для сценария «зелёный сервер, красные пользователи» важны сигналы внутри продукта и история вокруг момента деградации — не только ответ HTTP с главной. Добавьте первый сайт и настройте уведомления.