К нам обратился клиент с проблемой, что у него портал на Битрикс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`;
