[uga.labnbook.fr] Serveur ralenti par des requêtes SQL hors application web
Hier le 27/03/2024, 100% du CPU était utilisé par des requêtes SQL qui n'ont pas été arrêtées par le serveur.
Ces requêtes étaient externent à l'application web LabNbook.
Réaction du 27/03/2024
J'ai utilisé la commande SQL suivante pour trouver les requêtes lentes
show processlist;
+------+------+-----------+------+---------+------+----------+------------------+----------+
| Id | User | Host | db | Command | Time | State | Info | Progress |
+------+------+-----------+------+---------+------+----------+------------------+----------+
| 2018 | root | localhost | NULL | Query | 0 | starting | show processlist | 0.000 |
+------+------+-----------+------+---------+------+----------+------------------+----------+
1 row in set (0.000 sec)
Dans l'exemple ci-dessus pas de requête lente, mais si il en avait une on peut la tuer avec kill <id>
en remplaçant <id>
par le contenu de la première colonne pour la ligne voulue
Analyse à froid du 28/03/2024
MariaDB [(none)]> select @@max_statement_time;
+----------------------+
| @@max_statement_time |
+----------------------+
| 0.000000 |
+----------------------+
1 row in set (0.000 sec)
La variable max_statement_time
n'était pas définie par défaut elle vaut 0 donc pas de timeout.
J'ai modifié /etc/mysql/mariadb.conf.d/50-server.cnf
puis relancé mariadb systemctl restart mariadb
pour obtenir :
MariaDB [(none)]> select @@max_statement_time;
+----------------------+
| @@max_statement_time |
+----------------------+
| 60.000000 |
+----------------------+
1 row in set (0.000 sec)
Je ne sais pas pourquoi avant il y avait un timeout (d'après @renaudos et @dhamc ) et plus maintenant, je soupçonne un changement de comportement par défaut sur Mariadb avec une mise à jour de l'OS.
TODO
-
Confirmer que la modification est effective
@renaudos peux-tu relancer une requête longue et voir si elle tien plus de 60 secondes ? Au besoin on peut killer la query cf plus haut