Тормозит загрузка Битрикс24

К нам обратился клиент с проблемой, что у него портал на Битрикс24 с завидной регулярностью виснет минут на 10, то есть в это время Битрикс24 не грузится вообще, просто крутится бесконечная загрузка в браузере. При этом, если руками на сервере перезапустить MySQL сервер, то всё начинает работать.

Так как налицо явное зависание MySQL сервера, предположили, что проблема связана с какими-то большими запросами, которые подвешивают весь сервер. Для того, чтобы такие запросы выявить, надо включить медленные логи MySQL.

Для этого в файле /etc/my.cnf в разделе [mysqld] надо добавить следующие строки:

 slow_query_log = 1
 long_query_time = 30
 slow_query_log_file = /var/log/mysql/mysql-slow.log
 log-queries-not-using-indexes = 1 

После чего перезапустить сервер:

 systemctl restart mysqld 

После этого надо дождаться, когда произойдут зависания, после чего поискать эти зависания в логах, например, вот так:

 grep 'Query_time' /var/log/mysql/mysql-slow.log | cut -f 1 | awk '{print $3}'| sort -n 

Должно выдать в конце списка пункты с самым большим временем:

 10.399614 12.097516 13.312260 29.434928 31.648645 44.257068 52.776758 84.639710 133.691616 

Затем копируем любое значение и ищем в файле с помощью поиска, и находим, что это был за запрос.

 # User@Host: root[root] @ localhost [] Id: 1059409 # Schema: *** Last_errno: 1681 Killed: 0 # Query_time: 84.639710 Lock_time: 0.000000 Rows_sent: 403981 Rows_examined: 403981 Rows_affected: 0 Bytes_sent: 268904581 SET timestamp=1631441462; SELECT /*!40001 SQL_NO_CACHE */ * FROM `b_bp_tracking`; 

Оказалось, что это таблица, которая связана с модулем бизнес-процессов, для начала надо в настройках модуля уменьшить время хранения логов, для этого надо в настройках модулей выбрать этот модуль и поставить минимальное время.

Затем надо найти этого агента в списке агентов по адресу /bitrix/admin/agent_list.php, например, задав в поиске название модуля, в нашем случае это модуль bizproc.

После этого надо его отредактировать и задать там интервал поменьше, чтобы чаще запускался, в нашем случае для очистки логов бизнес-процессов.

После этого нужно вручную очистить эту таблицу, предварительно обязательно сделав дамп базы данных, так как всегда что-то может пойти не так. Для начала вы можете проверить, сколько там сейчас записей, в нашей случае это оказалось почти 2 миллиона.

 select count(*) FROM `b_bp_tracking`; +----------+ | count(*) | +----------+ | 1733426 | +----------+ 1 row in set (0,25 sec) 

Конечно, с таким количеством записей в таблице запрос select * будет выполняться очень долго, при этом остальные в этом время не смогут работать.

Чтобы очистить записи логов бизнес-процессов в таблице, надо выполнить следующую команду:

 delete from `b_bp_tracking`; 

После чего таблица будет очищена, и проблема должна будет пройти. Медленные логи рекомендуем не выключать, чтобы в случае чего, выявить следующее слабое звено и устранить его.

UPD. 14.09.2021: Для того, чтобы убедиться, что агент по очистке работает верно, надо проверить, нет ли в таблице данных, старше тех, что вы указали в настройках, в нашем случае это 1 сутки.

 select MODIFIED from `b_bp_tracking`;