Как несколько SQL-запросов положили Битрикс24, хотя сервер по мониторингу выглядел абсолютно здоровым

Последние пару месяцев мы активно ковыряем коробочный Битрикс24 и постепенно приходим к одной и той же мысли. Мониторинг сервера и мониторинг самого Битрикса - это вообще разные вещи.

Причем это стало понятно не в теории, а на вполне конкретном кейсе.

Началось все довольно банально. Пользователи начали жаловаться, что портал периодически тормозит. Не постоянно, а именно периодически. У кого-то карточка CRM открывается секунд 10, у кого-то бизнес-процесс зависает, кто-то вообще получает ошибки. При этом через 15 минут все снова работает нормально. Первая мысль стандартная - не хватает ресурсов.Заходим на сервер, открываем мониторинг, смотрим графики и... CPU не упирается, память есть, диск живой - ЧЯДНТ??!1

С точки зрения классического мониторинга сервер чувствовал себя прекрасно.

И вот это, наверное, самое неприятное состояние для администратора. Пользователи говорят, что все тормозит, пока зашли - графики говорят, что все хорошо.

Мы начали копать глубже. Сначала думали на очередную интеграцию. Потом на бизнес-процессы. Потом на какие-нибудь фоновые агенты Битрикса. Кто работает с коробкой давно, тот знает эту игру - сначала подозреваешь вообще всех.

В какой-то момент стало понятно, что смотреть только на Linux уже бессмысленно. Сервер нам ничего нового не расскажет. Нужно смотреть, что происходит внутри самого Битрикса именно в момент деградации.

С этого момента, собственно, и началась история той самой диагностики Битрикс24, которая потом появилась в Pinguva: отдельный раздел диагностики Битрикс24, который собирает историю нагрузки, активность REST, тяжелые SQL-группы, инциденты и позволяет посмотреть, что происходило до, во время и после всплеска нагрузки.

Мы начали собирать статистику по REST, смотреть активность MySQL, количество одновременно выполняемых запросов, тяжелые SQL-группы, блокировки и прочие вещи, которые обычно живут где-то отдельно от обычного мониторинга.

Оказалось, что проблема вообще не связана с нехваткой процессора или памяти. Более того, если смотреть только на сервер, ее можно искать неделями.

В момент жалоб пользователей возникал всплеск определенных групп SQL-запросов. Не один тяжелый запрос, который сразу бросается в глаза, а именно группа похожих запросов, которые одновременно начинали выполнять одну и ту же работу. Каждый из них сам по себе выглядел относительно безобидно. Но когда таких запросов становилось много, MySQL начинал тратить на них огромное количество времени.

Самое забавное, что сервер при этом продолжал выглядеть здоровым.

Именно после этого кейса мы окончательно пришли к мысли, что для коробочного Битрикс24 недостаточно знать загрузку CPU, объем памяти и свободное место на диске.

Когда заказчик говорит "Битрикс тормозит", ему абсолютно все равно, сколько процентов показывает top. Ему нужно понять, что именно произошло в момент проблемы. И желательно не через неделю после инцидента, а сразу.

Потому что фраза "сервер работает нормально" на практике очень часто означает только одно - искать нужно в другом месте.