Requêtes MariaDB "bloquées"

Bare Metal and VPS
1

Hello,

J'ai besoin de conseil/aide pour le serveur d'un client.

Le serveur est un scale a4, un raid1 pour / et un autre raid1 pour /home.

256Go de RAM, 48 coeurs/96 threads, bref, une belle bestiole.

En temps normal, ce serveur ronronne... Il tourne parfaitement bien... Un load average <5, <128Go de ram utilisée, les disques sont zen, en moyenne entre 10 et 20 connexions sql simultanées.

On est sur 600 à 700 requêtes seconde (sur le sgbd), 80% de SELECT, bref, rien d'insurmontable pour ce serveur.

Mais, environ, 1x / semaine, ce serveur décide de me casser les c...lles...

Sur le SGBD les requêtes restent "bloquées", généralement sur "Statistics".

Impossible de kill ces requêtes, le kill xx ne fait rien du tout, malgré innodb_lock_wait_timeout = 50 / wait_timeout = 300 / interactive_timeout = 300 les requêtes ne sont pas kill par le système, et il est même impossible d'arrêter le serveur sql... Tout ce que je vais avoir dans les logs à l'arrêt c'est : [Warning] /usr/sbin/mariadbd: Thread 660021 (xxx) did not exit...

Je dois kill le process (mariadb), le relancer... Là évidemment j'ai des tas de tables qui sont marquées crashed, je dois lancer des check/repairs sur tout ce beau monde...

Puis, une fois relancé, tout fonctionne à nouveau à merveille pendant plusieurs jours avant de recommencer...

Je n'ai strictement rien dans les logs, ni alerte sur la ram, le cpu, le raid, les disques... Les logs sql sont particulièrement muets également...

Il n'y a pas d'activité particulièrement élevée avant le blocage, ça se met à partir en live d'un coup...

L'open file limit est ok et n'est pas responsable du problème non plus.

Je suis franchement à bout d'idée... En dehors du bug tout est clean, pendant le bug je n'ai pas bcp de tps pour faire des tests car le client râle vu que ses sites sont down...

J'ai éventuellement dans l'idée de passer en rescue pour tester la RAM, mais je doute qu'il y ait un problème à ce niveau, et ça implique à nouveau un downtime, même si je dois pouvoir tester une partie de la RAM en prod...

@le_sbraz une idée de ce qui pourrait provoquer ces bugs ?

Quelqu'un d'autre ?

2

Hello Sich,
À part regarder des retours d'autres utilisateurs en cherchant l'erreur exacte du Thread did not exit, je ne sais pas trop quoi te conseiller. As-tu essayé de lancer https://github.com/major/MySQLTuner-perl pour voir s'il te donnait des informations utiles ?

3

Salut,

Merci pour ton retour.

MySQLtuner ne me donne rien de pertinent non plus, j'ai fait le tour des précos, tout est optimisé comme il faut.

Je n'ai jamais rencontré ça, c'est assez rageant... Surtout que j'ai des serveurs bien + "chargés" que ça, sur du matériel - performant.

Là pour le moment, j'ai baissé la taille du buffer pool, me disant que peut-être, il y a un problème avec le cache... Je n'y crois pas trop, mais bon, au point où j'en suis...

Je vais finir par installer une version + récente de mariadb depuis les repos mariadb en lieu et place des repos debian... Mais je n'ai aucun problème sur mes autres deb12...

Je me disais que vous aviez peut-être des retours d'expérience côté ovh...

Et non, google ne m'aide pas + que ça sur le thread did not exit...

bah, bientôt le week-end, restons positif :)

4

Salut,

En demandant directement chez https://mariadb.com/kb/en/reporting-bugs/ ?

5

Là j'ai encore fait pas mal de modif, j'ai repassé une couche de check/analyse/optimise/alter sur toutes les tables...
Ce matin j'ai eu le bug et avec toutes les modifs faites + tôt j'ai eu un nouveau log (youpie) :

2025-03-14 5:24:33 0 [ERROR] [FATAL] InnoDB: innodb_fatal_semaphore_wait_threshold was exceeded for dict_sys.latch. Please refer to https://mariadb.com/kb/en/how-to-produce-a-full-stack-trace-for-mysqld/
250314 5:24:33 [ERROR] mysqld got signal 6 ;
Sorry, we probably made a mistake, and this is a bug.

J'ai fait quelques ajustements à la configuration par rapport à ça... On va voir si ça replante...

Vu qu'il faut parfois jusqu'à 1 semaine pouvoir le problème arriver je n'ai rien d'autre à faire que d'attendre.

Là les options qui se présentent encore à moi c'est la montée de version via les repos officiels, sinon comme tu le proposes le rapport de bug... Mais sans logs complet c'est compliqué de faire un rapport de bugs... Surtout que je n'arrive pas à le reproduire non plus...

On va bien voir, en dehors de ces "bugs" le serveur tourne vraiment super bien, c'est rageant...

6

Hello à tous,

Je donne un état des lieux sur ces problèmes qui sont désormais résolus.

J'ai isolé plusieurs bdds, très volumineuses, bcp de requêtes, codées avec les pieds pour certaines (mal indexés, champ mal construits, etc), sur des instances autonomes. Même serveur physique, mais plusieurs instances mariadb via des services systemd. Ainsi, chacune de ces bdds un peu encombrante se retrouve sur sa propre instance mariadb, avec une configuration adaptée à chaque bdd.

J'ai également pas mal bidouillé la config mariadb pour profiter au maximum de la puissance délirante du serveur (96 core, 256Gb de RAM).

Depuis j'ai réussi à stabiliser la situation, depuis 2 semaines, pas un seul bug/plantage ni rien. Tout fonctionne à merveille.

Je n'ai pas vraiment réussi à identifier une raison en particulier pour ces "bugs".

Je pense que d'isoler certaines bdd sur des instances dédiées à du aider, c'est clairement depuis ce moment que je n'ai plus de problème.

Merci à ceux qui ont essayé de me donner des pistes.

7

> Même serveur physique, mais plusieurs instances mariadb via des services systemd

Systemd permet de démarrer plusieurs MariaDB sur un host ?

8

Yep, super pratique !

En gros, j'ai une config commune qui est appelée, puis j'adapte la config à chaque instance sur certains paramètres. Je précise le dossier de data pour chaque instance, et voilà... J'ai une instance, sur un autre port, avec ses propres données...

Avec un exec_start custom du genre :

ExecStart=/usr/sbin/mysqld --defaults-file=/etc/mysql_multi/annuaire6r/my.cnf

Dans la config, j'appelle ma config commune au début du my.cnf :

!include /etc/mysql_multi/commun/global.cnf

Et je peux restart mon instance avec

systemctl restart mariadb@annuaire6r.service

N'hésites pas à demander à chatgpt au sujet de l'instanciation de services systemd.

'fin c'est vraiment pratique qd tu as besoin d'isoler une bdd, de lui appliquer des paramètres précis, etc...

Je n'ai pas creusé, mais on doit pouvoir faire la même chose avec apache / nginx, avec une instance / IP par exemple...

9

Rhôôôô.
Merci beaucoup je connaissais pas.